From liach at openjdk.org Thu May 1 00:06:06 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 00:06:06 GMT Subject: RFR: 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor Message-ID: As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types. In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported. These behaviors are already covered by the tests added in JDK-8350704 #23788. Testing: reflect/annotation/Class, running tier 1+2 ------------- Commit messages: - 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor Changes: https://git.openjdk.org/jdk/pull/24978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356022 Stats: 88 lines in 4 files changed: 39 ins; 30 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24978/head:pull/24978 PR: https://git.openjdk.org/jdk/pull/24978 From jpai at openjdk.org Thu May 1 01:17:49 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 1 May 2025 01:17:49 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v7] In-Reply-To: References: <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com> <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com> Message-ID: On Wed, 30 Apr 2025 19:18:57 GMT, Lance Andersen wrote: > I think throwing the SkippedException is the right way to go long term but I assume this shows as a reported failure in Mach5 and in the case of assumeTrue it does not result in a failure being reported? That is correct, use of assumeTrue will skip the test (which is what we want) but it will be classified as aborted instead of skipped. Throwing jtreg.SkippedException however fails that test which isn't a good thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2069736818 From duke at openjdk.org Thu May 1 02:05:01 2025 From: duke at openjdk.org (ExE Boss) Date: Thu, 1 May 2025 02:05:01 GMT Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v9] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 17:45:04 GMT, Ioi Lam wrote: >> This PR contains 2 parts >> >> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5) >> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation. >> >> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s used by `ReferencedKeyMap` (which is used by `MethodType::internTable`): >> >> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`. >> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. >> >> `ReferencedKeyMap::prepareForAOTCache()` avoids the above problem. It goes over all entries in the table: >> >> - If an entry has not yet been collected, we make sure it will never be collected. >> - If an entry has been collected, we remove it from the table >> >> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects. >> >> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache. >> >> In the future, we may relax the implementation to allow for other use cases. > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - @AlanBateman comments > - @xmas92 comments Changes requested by ExE-Boss at github.com (no known OpenJDK username). src/java.base/share/classes/java/lang/ref/Reference.java line 314: > 312: } > 313: > 314: private static void runtimeSetup() { The?comment was?added in?the?wrong?spot: Suggestion: static { runtimeSetup(); } // Called from JVM when loading an AOT cache private static void runtimeSetup() { ------------- PR Review: https://git.openjdk.org/jdk/pull/24757#pullrequestreview-2809022545 PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069766184 From iklam at openjdk.org Thu May 1 03:48:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 1 May 2025 03:48:57 GMT Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v9] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 02:01:36 GMT, ExE Boss wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - @AlanBateman comments >> - @xmas92 comments > > src/java.base/share/classes/java/lang/ref/Reference.java line 314: > >> 312: } >> 313: >> 314: private static void runtimeSetup() { > > The?comment was?added in?the?wrong?spot: > Suggestion: > > static { > runtimeSetup(); > } > > // Called from JVM when loading an AOT cache > private static void runtimeSetup() { Oops, I will fix in an related PR #24979 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069812435 From liach at openjdk.org Thu May 1 04:45:46 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 04:45:46 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes In-Reply-To: References: Message-ID: <_uZd7RSmdekF9WeP5qXOOl24Lf00VgithwXEtQcQ9dM=.70173f42-a29e-4a5a-a43f-933b94a8506f@github.com> On Wed, 30 Apr 2025 21:49:12 GMT, Chen Liang wrote: >> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). >> >> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues) >> >> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table. >> >> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase. > > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1533: > >> 1531: } >> 1532: >> 1533: private static void runtimeSetup() { > > Suggestion: > > > // Called from JVM when loading an AOT cache > private static void runtimeSetup() { Same problem in Reference, credit to @exe-boss ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24956#discussion_r2069844711 From vyazici at openjdk.org Thu May 1 05:38:27 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 1 May 2025 05:38:27 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods Message-ID: Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. ------------- Commit messages: - Improve `JavaLangAccess` documentation Changes: https://git.openjdk.org/jdk/pull/24982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353197 Stats: 41 lines in 1 file changed: 22 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From duke at openjdk.org Thu May 1 07:23:03 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 1 May 2025 07:23:03 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v9] In-Reply-To: References: <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com> Message-ID: On Wed, 30 Apr 2025 21:57:07 GMT, Joe Darcy wrote: >> Unfortunately the same happens. ? > > The following javadoc for String's getChars method has, I believe, the desired effect: > > > /** > * {@inheritDoc CharSequence} > * @param srcBegin {@inheritDoc CharSequence} > * @param srcEnd {@inheritDoc CharSequence} > * @param dst {@inheritDoc CharSequence} > * @param dstBegin {@inheritDoc CharSequence} > * @throws IndexOutOfBoundsException {@inheritDoc CharSequence} > */ > > > HTH Thank you, Joe. That actually produces the expected result. IMHO it is just a workaround for a bug in the javadoc processor, hence I would keep it *just here*, but in all locations (in particular in the CSR) I would propose to keep the shorter form. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2069929069 From duke at openjdk.org Thu May 1 07:23:03 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 1 May 2025 07:23:03 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v10] In-Reply-To: References: Message-ID: > This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. > > In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. > > To ensure quality... > * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. > * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21730/files - new: https://git.openjdk.org/jdk/pull/21730/files/99fcefbd..342bc842 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=08-09 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21730.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730 PR: https://git.openjdk.org/jdk/pull/21730 From duke at openjdk.org Thu May 1 07:32:09 2025 From: duke at openjdk.org (erifan) Date: Thu, 1 May 2025 07:32:09 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v4] In-Reply-To: References: Message-ID: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... erifan 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: - Update the jtreg test - Merge branch 'master' into JDK-8354242 - Addressed some review comments 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. 2. Improve code comments. - Merge branch 'master' into JDK-8354242 - Merge branch 'master' into JDK-8354242 - 8354242: VectorAPI: combine vector not operation with compare This patch optimizes the following patterns: For integer types: ``` (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) => (VectorMaskCmp src1 src2 ncond) (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) => (VectorMaskCmp src1 src2 ncond) ``` cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. For float and double types: ``` (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) ``` cond can be eq or ne. Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 testCompareLTMaskNotLong ops/s 856502.2695 12276.82851 1177671.815 496.723302 1.37 testCompareLTMaskNotShort ops/s 3325798.025 2412.702501 4711554.181 1779.302112 1.41 testCompareNEMaskNotByte ops/s 7910002.518 2771.82477 10245315.33 16321.93935 1.29 testCompareNEMaskNotDouble ops/s 863754.6022 523.140788 1179133.982 476.572178 1.36 testCompareNEMaskNotFloat ops/s 1723321.883 2598.484803 2358492.186 877.1401 1.36 testCompareNEMaskNotInt ops/s 1670288.841 751.774826 2354158.125 835.720163 1.4 testCompareNEMaskNotLong ops/s 836327.6835 410.525466 1178178.825 308.757932 1.4 testCompareNEMaskNotShort ops/s 3327815.841 1511.978763 4711379.136 2336.505531 1.41 testCompareUGEMaskNotByte ops/s 7906699.024 3200.936474 10253843.74 15067.59401 1.29 testCompareUGEMaskNotInt ops/s 1674003.923 3287.191727 2353340.666 951.381021 1.4 testCompareUGEMaskNotLong ops/s 852424.5562 8920.408939 1177943.609 389.6621 1.38 testCompareUGEMaskNotShort ops/s 3327255.858 1584.885143 4711622.355 1247.215277 1.41 testCompareUGTMaskNotByte ops/s 7909249.189 4435.283667 10245541.34 10993.34739 1.29 testCompareUGTMaskNotInt ops/s 1693713.433 20650.00213 2353153.787 1055.343846 1.38 testCompareUGTMaskNotLong ops/s 851022.3395 7079.065268 1177910.677 538.604598 1.38 testCompareUGTMaskNotShort ops/s 3327236.988 1616.886789 4711209.865 3098.494145 1.41 testCompareULEMaskNotByte ops/s 7909350.825 3251.262342 10261449.03 7273.831341 1.29 testCompareULEMaskNotInt ops/s 1672350.925 1545.304304 2353231.755 914.231193 1.4 testCompareULEMaskNotLong ops/s 853349.4765 9804.906913 1177967.254 435.044367 1.38 testCompareULEMaskNotShort ops/s 3325757.891 1555.062257 4712873.187 1650.986905 1.41 testCompareULTMaskNotByte ops/s 7912218.621 2633.477744 10242095.98 21921.39902 1.29 testCompareULTMaskNotInt ops/s 1673994.849 2672.507666 2353449.22 946.105757 1.4 testCompareULTMaskNotLong ops/s 849032.5868 10406.06689 1177586.047 506.541456 1.38 testCompareULTMaskNotShort ops/s 3328062.026 1892.991844 4713247.216 1855.983724 1.41 ``` With option `-XX:UseSVE=0`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 7895961.919 72712.90804 7746493.731 71481.92938 0.98 testCompareEQMaskNotDouble ops/s 789811.0455 384.493088 766473.7994 2216.581793 0.97 testCompareEQMaskNotFloat ops/s 1806305.818 638.010451 1819616.613 3295.38958 1 testCompareEQMaskNotInt ops/s 1815820.144 1225.336135 1849538.401 766.29902 1.01 testCompareEQMaskNotLong ops/s 807336.492 335.451807 792732.9483 277.954432 0.98 testCompareEQMaskNotShort ops/s 4818266.38 1927.862665 4668903.001 1922.782715 0.96 testCompareGEMaskNotByte ops/s 7818439.678 75374.97739 16498003.98 41440.49653 2.11 testCompareGEMaskNotInt ops/s 1815159.05 1090.912209 2372095.779 1664.397112 1.3 testCompareGEMaskNotLong ops/s 804324.5575 2301.686878 927919.8507 371.766719 1.15 testCompareGEMaskNotShort ops/s 4818966.563 2443.643652 5385561.038 29558.37423 1.11 testCompareGTMaskNotByte ops/s 7893406.157 82687.74264 16470663.2 22165.55812 2.08 testCompareGTMaskNotInt ops/s 1815316.812 915.894106 2370447.198 655.016338 1.3 testCompareGTMaskNotLong ops/s 807019.456 526.525482 928079.0541 330.582693 1.15 testCompareGTMaskNotShort ops/s 4820552.881 1684.247747 5355902.93 5893.2915 1.11 testCompareLEMaskNotByte ops/s 7816263.323 79560.0015 16473621.19 56688.99585 2.1 testCompareLEMaskNotInt ops/s 1814915.724 926.998625 2368790.306 932.594778 1.3 testCompareLEMaskNotLong ops/s 806483.9 935.718082 928110.9074 407.096695 1.15 testCompareLEMaskNotShort ops/s 4813660.241 6817.870509 5357107.852 10061.47975 1.11 testCompareLTMaskNotByte ops/s 7838948.962 69136.4504 16424405.96 24464.75469 2.09 testCompareLTMaskNotInt ops/s 1815056.833 1187.6453 2369892.187 1103.819634 1.3 testCompareLTMaskNotLong ops/s 806602.1804 287.923365 928346.4118 617.682824 1.15 testCompareLTMaskNotShort ops/s 4817940.643 2767.1509 5372537.84 15397.47169 1.11 testCompareNEMaskNotByte ops/s 9078493.798 4630.339307 16484348.42 18925.88346 1.81 testCompareNEMaskNotDouble ops/s 661769.6272 398.712981 926763.5839 1808.843788 1.4 testCompareNEMaskNotFloat ops/s 1570527.252 563.642144 2312425.678 1815.844846 1.47 testCompareNEMaskNotInt ops/s 1619146.58 626.793854 2369711.543 942.330478 1.46 testCompareNEMaskNotLong ops/s 680201.5381 2252.836482 927808.6147 414.917863 1.36 testCompareNEMaskNotShort ops/s 3763508.054 3622.560798 5367808.015 8591.466599 1.42 testCompareUGEMaskNotByte ops/s 7886373.129 75917.74675 16480928.93 27524.31005 2.08 testCompareUGEMaskNotInt ops/s 1815636.832 750.036241 2369683.015 901.609404 1.3 testCompareUGEMaskNotLong ops/s 806862.5826 287.819616 928001.4394 361.063837 1.15 testCompareUGEMaskNotShort ops/s 4820581.361 2098.537435 5375854.248 25619.40165 1.11 testCompareUGTMaskNotByte ops/s 7891591.465 96614.93542 16410405.93 15012.37096 2.07 testCompareUGTMaskNotInt ops/s 1814871.179 662.825588 2371325.903 1170.491164 1.3 testCompareUGTMaskNotLong ops/s 804013.7658 2240.534209 928062.2169 531.306897 1.15 testCompareUGTMaskNotShort ops/s 4818150.337 3051.717685 5381449.337 21212.34187 1.11 testCompareULEMaskNotByte ops/s 7831540.628 81306.67253 16495250.78 38682.19675 2.1 testCompareULEMaskNotInt ops/s 1814484.14 687.860656 2369265.075 940.609586 1.3 testCompareULEMaskNotLong ops/s 807780.5749 769.876816 927538.0732 1278.267724 1.14 testCompareULEMaskNotShort ops/s 4817437.42 5141.336541 5356183.359 7015.608124 1.11 testCompareULTMaskNotByte ops/s 7849078.225 56753.59764 16395975.27 34043.67295 2.08 testCompareULTMaskNotInt ops/s 1814328.226 2697.219111 2370700.47 1991.841988 1.3 testCompareULTMaskNotLong ops/s 807166.8197 253.061506 927926.2803 252.933462 1.14 testCompareULTMaskNotShort ops/s 4821098.216 1625.959044 5348980.243 4100.768121 1.1 ``` Benchmarks on AMD EPYC 9124 16-Core Processor: With option `-XX:UseAVX=3`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 16607323.35 1233692.631 18381557.66 1163201.522 1.1 testCompareEQMaskNotDouble ops/s 2114285.245 58782.2534 2959946.353 43016.0445 1.39 testCompareEQMaskNotFloat ops/s 4480874.437 89975.29074 6960151.436 64799.143 1.55 testCompareEQMaskNotInt ops/s 4370906.91 51784.80889 6856955.043 313858.5504 1.56 testCompareEQMaskNotLong ops/s 2080065.895 26762.06732 2939142.143 67179.05314 1.41 testCompareEQMaskNotShort ops/s 7968282.563 210437.2781 12701214.56 473152.6407 1.59 testCompareGEMaskNotByte ops/s 18419141.89 473408.9451 19880059.68 321638.0397 1.07 testCompareGEMaskNotInt ops/s 4419015.62 77352.98633 7037639.227 151066.0383 1.59 testCompareGEMaskNotLong ops/s 2147982.48 49227.42782 3000275.928 39298.75344 1.39 testCompareGEMaskNotShort ops/s 8469039.613 17833.19707 12288229.49 244317.8812 1.45 testCompareGTMaskNotByte ops/s 18728997.5 468328.8358 20544730.05 392264.6466 1.09 testCompareGTMaskNotInt ops/s 4510009.705 78812.57357 7364629.942 70970.78473 1.63 testCompareGTMaskNotLong ops/s 2124104.969 40917.89257 2953536.279 35199.19687 1.39 testCompareGTMaskNotShort ops/s 8690557.621 311534.1159 12344017.51 457931.8741 1.42 testCompareLEMaskNotByte ops/s 17758400.53 478383.4945 19209183.26 1143297.241 1.08 testCompareLEMaskNotInt ops/s 4363664.862 43443.18063 7054093.064 78141.11476 1.61 testCompareLEMaskNotLong ops/s 2068632.213 29844.78023 2954766.412 50667.22502 1.42 testCompareLEMaskNotShort ops/s 8637608.548 183538.5511 12719010.27 473568.8825 1.47 testCompareLTMaskNotByte ops/s 14406138.95 423105.0163 17292417.96 371386.9689 1.2 testCompareLTMaskNotInt ops/s 4546707.266 131977.3144 7040483.394 213590.4657 1.54 testCompareLTMaskNotLong ops/s 2123277.356 47243.21499 2848720.442 58896.97045 1.34 testCompareLTMaskNotShort ops/s 7570169.363 649873.6295 11945383.75 988276.5955 1.57 testCompareNEMaskNotByte ops/s 18274529.55 683396.7384 19081938.8 1118739.778 1.04 testCompareNEMaskNotDouble ops/s 2112533.61 43295.50012 2912115.441 78189.51083 1.37 testCompareNEMaskNotFloat ops/s 4628683.814 93817.07362 6967208.729 145135.8544 1.5 testCompareNEMaskNotInt ops/s 4470900.214 75974.50842 7286913.662 116328.5277 1.62 testCompareNEMaskNotLong ops/s 2134091.061 46377.94061 2934667.477 81675.46021 1.37 testCompareNEMaskNotShort ops/s 8790384.287 396161.8599 13076858.35 286272.1155 1.48 testCompareUGEMaskNotByte ops/s 18009150.9 660803.8886 17551258.33 1667014.843 0.97 testCompareUGEMaskNotInt ops/s 4442928.74 83190.81019 6854088.277 329008.8901 1.54 testCompareUGEMaskNotLong ops/s 2088357.736 71696.24791 2973202.26 63278.78974 1.42 testCompareUGEMaskNotShort ops/s 8348624.02 116562.7876 12832250.78 546869.3006 1.53 testCompareUGTMaskNotByte ops/s 17871101.25 800199.6321 19902619.81 214003.3262 1.11 testCompareUGTMaskNotInt ops/s 4088304.421 137797.9723 7135454.33 124553.651 1.74 testCompareUGTMaskNotLong ops/s 2070610.42 19881.82182 2991536.365 36260.60767 1.44 testCompareUGTMaskNotShort ops/s 8637099.341 155822.1608 12756579.77 186068.199 1.47 testCompareULEMaskNotByte ops/s 17940901.36 1258029.364 18932484.94 694554.6305 1.05 testCompareULEMaskNotInt ops/s 4369177.511 74982.31936 6392773.082 550171.2266 1.46 testCompareULEMaskNotLong ops/s 2135905.761 43693.63178 2877579.631 41651.56289 1.34 testCompareULEMaskNotShort ops/s 8607710.544 132655.1676 12446370.04 441718.3035 1.44 testCompareULTMaskNotByte ops/s 17409912.23 1033204.537 20607479.99 362000.5056 1.18 testCompareULTMaskNotInt ops/s 4386455.9 119192.1635 6920123.264 186158.2845 1.57 testCompareULTMaskNotLong ops/s 2064995.149 38622.2734 2988343.589 39037.90006 1.44 testCompareULTMaskNotShort ops/s 8642182.752 230919.2442 13029582.09 437101.4923 1.5 ``` The small amount of performance degradation is due to test fluctuations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24674/files - new: https://git.openjdk.org/jdk/pull/24674/files/34eae981..4fbf84e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=02-03 Stats: 13350 lines in 388 files changed: 9247 ins; 1843 del; 2260 mod Patch: https://git.openjdk.org/jdk/pull/24674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674 PR: https://git.openjdk.org/jdk/pull/24674 From duke at openjdk.org Thu May 1 07:34:52 2025 From: duke at openjdk.org (erifan) Date: Thu, 1 May 2025 07:34:52 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v3] In-Reply-To: <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com> References: <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com> Message-ID: On Tue, 29 Apr 2025 10:22:22 GMT, Emanuel Peter wrote: >> erifan 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: >> >> - Addressed some review comments >> >> 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. >> 2. Improve code comments. >> - Merge branch 'master' into JDK-8354242 >> - Merge branch 'master' into JDK-8354242 >> - 8354242: VectorAPI: combine vector not operation with compare >> >> This patch optimizes the following patterns: >> For integer types: >> ``` >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> ``` >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the >> negative comparison of cond. >> >> For float and double types: >> ``` >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> ``` >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: >> With option `-XX:UseSVE=2`: >> ``` >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393... > > Yes, this discussion is down to `requires` vs `applyIf`. This is my argument for `applyIf`, quoted from above, I have not yet seen an argument against it: > >> If you use @require, then the person does not realize there is a test AND the test is not run. If you use applyIf, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash. > > In my understanding, `requires` should only be used if the test really **requires** a certain platform or feature. That can be because some flags are only available under certain platforms for example. But for IR tests, we should try to always use `applyIf`, because it allows testing on other platforms. > > Actually, I filed this RFE a while ago: https://bugs.openjdk.org/browse/JDK-8310891 > We should try to move as many tests from using `requires` to `applyIf`, so that we have an increased test coverage. @eme64 @jatin-bhateja I have updated the test, thanks for your suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2844256626 From jlahoda at openjdk.org Thu May 1 07:45:55 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 May 2025 07:45:55 GMT Subject: Integrated: 8344708: Implement JEP 511: Module Import Declarations In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 13:50:52 GMT, Jan Lahoda wrote: > This is a patch to finalize the module imports feature. Please see: > https://bugs.openjdk.org/browse/JDK-8344700 This pull request has now been integrated. Changeset: 0a697f6f Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/0a697f6ff4c2f8254e95519e04708cf406009dc3 Stats: 484 lines in 32 files changed: 268 ins; 136 del; 80 mod 8344708: Implement JEP 511: Module Import Declarations Reviewed-by: mcimadamore, vromero, alanb ------------- PR: https://git.openjdk.org/jdk/pull/23801 From duke at openjdk.org Thu May 1 08:45:06 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 1 May 2025 08:45:06 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: > This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. > > In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. > > To ensure quality... > * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. > * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21730/files - new: https://git.openjdk.org/jdk/pull/21730/files/342bc842..62a6867b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21730.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730 PR: https://git.openjdk.org/jdk/pull/21730 From duke at openjdk.org Thu May 1 08:45:06 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 1 May 2025 08:45:06 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v8] In-Reply-To: <4Rrs1AMrJ4M-_7x6li7dDhSVnasUVy8w4I42IjZCU30=.f0c85e6b-3bb8-464e-a006-3a34e77e06c9@github.com> References: <1s3MwTXb7v_7WWORxAL4WXOlbMOnpCkt8kbjc613-UM=.a81c62cc-4cc5-4714-8d3b-a63f0b9e092d@github.com> <4Rrs1AMrJ4M-_7x6li7dDhSVnasUVy8w4I42IjZCU30=.f0c85e6b-3bb8-464e-a006-3a34e77e06c9@github.com> Message-ID: On Mon, 28 Apr 2025 13:29:06 GMT, Daniel Fuchs wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' > > src/java.base/share/classes/java/lang/StringBuilder.java line 2: > >> 1: /* >> 2: * Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved. > > If there's no change to this file the copyright year update could be reverted? Good catch, Daniel! Fixed. Thank you! ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2069997101 From dfuchs at openjdk.org Thu May 1 08:47:46 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 May 2025 08:47:46 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v4] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 412 commits: - merge latest changes from master branch - merge latest changes from master branch - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods. - merge latest changes from master branch - http3: add missing

separator to Http3DiscoveryMode.ALT_SVC API documentation - http3: improve documentation for Http3DiscoveryMode.ALT_SVC - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test - http3: minor improvement to log message - http3: Artur's review - remove commented out code from test - ... and 402 more: https://git.openjdk.org/jdk/compare/526951db...9156a51e ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=03 Stats: 102846 lines in 472 files changed: 100217 ins; 1120 del; 1509 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From mli at openjdk.org Thu May 1 08:52:45 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 1 May 2025 08:52:45 GMT Subject: RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786 In-Reply-To: <1hfhvGjxKFAYEtj1D_pIdgU659AE2oPWoQEyXl8sRgQ=.3aa62617-142a-49c9-82c4-0f761cb73aff@github.com> References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com> <1hfhvGjxKFAYEtj1D_pIdgU659AE2oPWoQEyXl8sRgQ=.3aa62617-142a-49c9-82c4-0f761cb73aff@github.com> Message-ID: On Wed, 30 Apr 2025 19:41:52 GMT, Vladimir Ivanov wrote: > Overall, it still looks like a JDK build issue to me. Hiding problems occurred during the build is not good. If some toolchains can't successfully build the library, the library shouldn't be included in JDK. No, in riscv case (possiblely also on arm?) I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different. How about we consider this in another way, we could fix this issue first, as it fails regularly on riscv and x64 in some situations. Then if you still consider the existing behaviour should be changed and could be improved further, it can be done in another pr. After all, it already broke the existing jdk in some scenarios. How do you think about it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2844401476 From mcimadamore at openjdk.org Thu May 1 09:08:46 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 09:08:46 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Improve on comments src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 81: > 79: @Override > 80: public int hashCode() { > 81: return System.identityHashCode(this); What's the value in these overloads? Isn't this implementation the same we'd get if there were no overrides? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070015191 From mcimadamore at openjdk.org Thu May 1 09:08:46 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 09:08:46 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 09:04:00 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve on comments > > src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 81: > >> 79: @Override >> 80: public int hashCode() { >> 81: return System.identityHashCode(this); > > What's the value in these overloads? Isn't this implementation the same we'd get if there were no overrides? Ugh - it's a record, I see. Which brings up the question -- should it be a record? Should it advertize its `size and `tl` components (they seem rather implementation specific?). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070017489 From mcimadamore at openjdk.org Thu May 1 09:11:46 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 09:11:46 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: <7Cz0Yoz7CNQXNgnCNlUTI96sTtV87FsVc7sRgPAP6gU=.0b79f998-26e2-4567-af60-8bcd75391105@github.com> On Thu, 1 May 2025 09:05:58 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 81: >> >>> 79: @Override >>> 80: public int hashCode() { >>> 81: return System.identityHashCode(this); >> >> What's the value in these overloads? Isn't this implementation the same we'd get if there were no overrides? > > Ugh - it's a record, I see. Which brings up the question -- should it be a record? Should it advertize its `size and `tl` components (they seem rather implementation specific?). Was this done so that the final field could be trusted? (I believe all final fields are implicitly trusted in jdk/internal/foreign): holder->is_in_package("jdk/internal/foreign/layout") || holder->is_in_package("jdk/internal/foreign") || ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070024350 From mcimadamore at openjdk.org Thu May 1 09:25:46 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 09:25:46 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Improve on comments src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 163: > 161: lock.unlock(); > 162: } > 163: Reference.reachabilityFence(arena); I'm not sure this is enough to keep the automatic arena alive. If the client lets the Frame arena go out of scope w/o calling close, then `arena` will become unreachable, but some segments created by the Frame arena might still be reachable. To be more correct, I think `Frame` should add a "close action" to its confined arena which keeps the outer automatic arena alive. This can be done, for instance, by passing a close action to the `reinterpret` call: frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, () -> Reference.reachabilityFence(arena))); The close action is installed in the `MemorySession` object of `confinedArena` -- which is then attached to all segments returned by `Frame` -- thus keeping the automatic arena alive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070063828 From mcimadamore at openjdk.org Thu May 1 09:35:48 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 09:35:48 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: <4jpiMz176AvMXMYO5YwjyNrWre6cTxNcVy6O4wmbq7k=.cb6fc8da-2d89-4f75-896a-c253ff9a3e36@github.com> On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Improve on comments src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 139: > 137: public MemorySegment allocate(long byteSize, long byteAlignment) { > 138: // Make sure we are on the right thread > 139: if (((MemorySessionImpl) scope()).ownerThread() != Thread.currentThread()) { This can also be rewritten as: `MemorySession.toMemorySession(confinedArena).checkValidState()` -- which is what we use elsewhere ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070089765 From duke at openjdk.org Thu May 1 09:55:49 2025 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 1 May 2025 09:55:49 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v5] In-Reply-To: References: Message-ID: On Sun, 27 Apr 2025 14:23:50 GMT, Tatsunori Uchino wrote: >> I misunderstood that I have tested `stdin.encoding`. >> I cannot confirm that `stdin.encoding` is changed in Windows to proper ones because it has not been included in the latest EA build (20) and I cannot build master for Windows. However, it is changed to `US-ASCII` in Ubuntu when I change `LANG`. I will believe its author until the latest EA build is updated. > > Anyway you need to merge master first to test `stdin.encoding`. `stdin.encoding` seems to work as intended in Windows for Japanese. No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070108439 From zuniquex at protonmail.com Thu May 1 10:10:10 2025 From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=) Date: Thu, 01 May 2025 10:10:10 +0000 Subject: JavaDoc fix in java.util.Date In-Reply-To: <54dbafaf-5cac-45d3-a5e3-2cac737dba9e@oracle.com> References: <54dbafaf-5cac-45d3-a5e3-2cac737dba9e@oracle.com> Message-ID: Thanks for all these helpful responses. So I guess there's nothing to do here except we want to integrate the change proposed by Chen to update the expression to use Long.hashCode. Cheers, Steffen -------- Urspr?ngliche Nachricht -------- Am 30.04.25 23:25 schrieb Roger Riggs : > Hi Steffen, > > One other oddity about the shift operators in Java, they only use the lower 5 bits of the shift distance argument. > > So, > > int x = 1024; > x >>4 == 64; and > x >> 36 == 64; > > It is unusual to specify the algorithm used for hashcodes, though in some cases backward compatibility has forced them to be specified. > > Regards, Roger > > On 4/30/25 4:37 PM, Steffen Nie?ing wrote: > >> Thanks, haven't seen unsigned right shift before. You're right, it should be fine to use the unsigned one and hence Long.hashCode for that. >> >> However, the docs should match the expression used in the implementation when explicitly naming the returned expression. Should we update both to Long.hashCode(this.getTime())? >> >> Cheers, >> Steffen >> >> Chen Liang [](mailto:chen.l.liang at oracle.com) schrieb am Mittwoch, 30. April 2025 um 22:27: >> >>> Well, the sign has no impact here - the most significant 32 bits duplicated from the original sign bit are immediately discarded in the subsequent int cast truncation to the least significant 32 bits. However, how there is such a difference from before OpenJDK was published is still intriguing. >>> --------------------------------------------------------------- >>> >>> From: core-libs-dev [](mailto:core-libs-dev-retn at openjdk.org) on behalf of Naoto Sato [](mailto:naoto.sato at oracle.com) >>> Sent: Wednesday, April 30, 2025 3:11 PM >>> To: core-libs-dev at openjdk.org [](mailto:core-libs-dev at openjdk.org) >>> Subject: Re: JavaDoc fix in java.util.Date >>> >>> Interestingly, the implementation of Date.hashCode() does use the signed >>> right shift ">>". >>> >>> Naoto >>> >>> On 4/30/25 1:06 PM, Chen Liang wrote: >>>> Indeed, Joe is right. Unsigned right shift does not appear often and is >>>> equivalent to signed right shift if the sign bit is 0. >>>> >>>> However, this piece of quote can get an upgrade - it can become >>>> `Long.hashCode(this.getTime())`. >>>> >>>> * >>>> Chen >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* core-libs-dev [](mailto:core-libs-dev-retn at openjdk.org) on behalf of >>>> Joseph D. Darcy [](mailto:joe.darcy at oracle.com) >>>> *Sent:* Wednesday, April 30, 2025 2:54 PM >>>> *To:* Steffen Nie?ing [](mailto:zuniquex at protonmail.com); core-libs- >>>> dev at openjdk.org [](mailto:core-libs-dev at openjdk.org) >>>> *Subject:* Re: JavaDoc fix in java.util.Date >>>> Unsigned right shift is non-existent? >>>> >>>> "The operators << (left shift), >> (signed right shift), and >>> >>>> (unsigned right shift) are called the shift operators. The left-hand >>>> operand of a shift operator is the value to be shifted; the right-hand >>>> operand specifies the shift distance. " >>>> >>>> https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19 >>>> >>>> >>>> -Joe >>>> >>>> On 4/30/2025 12:46 PM, Steffen Nie?ing wrote: >>>>> Hello, >>>>> >>>>> I'm new to the OpenJDK community and plan to make my first change. >>>>> >>>>> I've found a small mistake in the documentation of >>>>> java.util.Date#hashCode(). The documentation provides a Java >>>>> expression of the returned value, which uses a non-existent operator >>>>> '>>>'. >>>>> >>>>> Now I'm searching for a sponsor for a JBS issue and the code review. >>>>> Chen Liang directed me to this mailing list to ask for sponsoring on >>>>> this topic. >>>>> >>>>> Cheers, >>>>> Steffen >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Thu May 1 10:24:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 10:24:47 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 09:22:57 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve on comments > > src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 163: > >> 161: lock.unlock(); >> 162: } >> 163: Reference.reachabilityFence(arena); > > I'm not sure this is enough to keep the automatic arena alive. If the client lets the Frame arena go out of scope w/o calling close, then `arena` will become unreachable, but some segments created by the Frame arena might still be reachable. To be more correct, I think `Frame` should add a "close action" to its confined arena which keeps the outer automatic arena alive. This can be done, for instance, by passing a close action to the `reinterpret` call: > > > frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, () -> Reference.reachabilityFence(arena))); > > > The close action is installed in the `MemorySession` object of `confinedArena` -- which is then attached to all segments returned by `Frame` -- thus keeping the automatic arena alive. (if you agree with this analysis, perhaps adding an extra stress test, or tweaking one of the existing stress tests to check this could also be useful) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070128504 From mcimadamore at openjdk.org Thu May 1 10:24:49 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 10:24:49 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Improve on comments test/jdk/java/foreign/TestBufferStack.java line 192: > 190: assertEquals(firstAddress, segment.address()); > 191: var segmentTwo = arena.allocate(JAVA_INT); > 192: assertNotEquals(firstAddress, segmentTwo.address()); Should this check be stronger -- e.g. that the address of the second segment should be the address of the first + the size of JAVA_INT? test/jdk/java/foreign/TestBufferStack.java line 203: > 201: > 202: @Test > 203: void allocationCaptureStateLayout() { This test is not really testing much re. capture state layout. It feels like the only added thing w.r.t. `allocationSameAsPoolSize` is that it also checks that additional allocation will fail with IOOBE -- maybe these two tests should be merged? test/jdk/java/foreign/TestBufferStack.java line 241: > 239: @Test > 240: void closeConfinement() { > 241: var pool = BufferStack.of(POOL_SIZE); Nice confinement tests! test/jdk/java/foreign/TestBufferStackStress.java line 28: > 26: * @modules java.base/jdk.internal.foreign > 27: * @build NativeTestHelper TestBufferStackStress > 28: * @run junit/othervm --enable-native-access=ALL-UNNAMED TestBufferStackStress is `--enable-native-access` needed here (and also in the other stress test) ? test/jdk/java/foreign/TestBufferStackStress2.java line 45: > 43: import java.util.concurrent.atomic.AtomicBoolean; > 44: > 45: final class TestBufferStackStress2 extends NativeTestHelper { This also extends `NativeTestHelper` -- does it need to? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070124607 PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070126160 PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070126843 PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070129639 PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070129263 From mcimadamore at openjdk.org Thu May 1 10:27:48 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 May 2025 10:27:48 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Improve on comments test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 87: > 85: public void byValue() throws Throwable { > 86: // point = unit(); > 87: MemorySegment unused = (MemorySegment) MH_UNIT_BY_VALUE.invokeExact( This benchmark is a bit misleading, because the allocator object will add some noise in the mix. I suggest to have some allocator object ready in a field, and just pass that (avoiding the lambda). That would also be more similar to idiomatic FFM code (which assumes some allocator is already available at the callsite). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070131376 From rriggs at openjdk.org Thu May 1 12:58:51 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 12:58:51 GMT Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version [v7] In-Reply-To: References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Message-ID: <_lhfHVwnay07O9vLnUFPnJ1mRuj50y5oxO-lq7oR_Cg=.1ae3a9c1-7856-48f7-ac58-718bcc3b30a6@github.com> On Wed, 30 Apr 2025 22:12:20 GMT, Chen Liang wrote: >> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions. >> >> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse > - review: improve comments about implicit null checks > - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse > - Adapt the location APIs > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags > - 8355956: Prepare javap for class file format aware access flag parsing > - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse > - Explicit imports > - Wording updates > - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse > - ... and 21 more: https://git.openjdk.org/jdk/compare/e36756b2...b1cf4ebb Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24760#pullrequestreview-2809740302 From liach at openjdk.org Thu May 1 12:59:51 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 12:59:51 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 08:45:06 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 488: > 486: /** > 487: * {@inheritDoc CharSequence} > 488: */ Suggestion: * {@inheritDoc CharSequence} * @param srcBegin {@inheritDoc CharSequence} * @param srcEnd {@inheritDoc CharSequence} * @param dst {@inheritDoc CharSequence} * @param dstBegin {@inheritDoc CharSequence} * @throws IndexOutOfBoundsException {@inheritDoc CharSequence} */ Let's aim for text parity for now; can you create a bug for Javadoc for this inheritDoc inconsistency? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070240781 From lancea at openjdk.org Thu May 1 12:58:50 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 1 May 2025 12:58:50 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v7] In-Reply-To: References: <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com> <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com> Message-ID: On Thu, 1 May 2025 01:15:26 GMT, Jaikiran Pai wrote: > > I think throwing the SkippedException is the right way to go long term but I assume this shows as a reported failure in Mach5 and in the case of assumeTrue it does not result in a failure being reported? > > That is correct, use of assumeTrue will skip the test (which is what we want) but it will be classified as aborted instead of skipped. Throwing jtreg.SkippedException however fails that test which isn't a good thing. So I think it is important that the reporting is addressed WRT SkippedException, especially in light of some of the discussions raised in previous threads for Mach5. So in order to keep the Mach5 pipeline happy, I see the options is simply returning or use assumeTrue providing this does not create any additional reporting noise. It might be worthwhile creating a follow on bug to address this in the test, linking to the JtREG bug so that it does not get lost/forgotten ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2070240224 From liach at openjdk.org Thu May 1 13:04:47 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 13:04:47 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici wrote: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 315: > 313: * WARNING: The caller of this method shall relinquish and transfer the > 314: * ownership of the byte array to the callee, since the later will not > 315: * make a copy. I think we should add a note on why no copy is made - there may be multiple reads to the input array for decoding, so the input array must not be accessible by untrusted code, which can racily modify it. A side effect is that this array is simply reused if it's eligible to be the string content array, which is unfortunately abused in a few places in the JDK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2070244058 From alanb at openjdk.org Thu May 1 12:43:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 May 2025 12:43:45 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 23:38:02 GMT, Brian Burkhalter wrote: > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. I've added the "csr" label as we will need to create a CSR for this. It will need a release note too. src/java.base/windows/classes/java/io/WinNTFileSystem.java line 45: > 43: > 44: private static final boolean DELETE_READONLY = > 45: Boolean.getBoolean("jdk.io.File.deleteReadOnly"); What would you think of allowDeleteReadOnlyFiles rather than deleteReadOnly? src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 665: > 663: BOOL attrSet = FALSE; > 664: if (deleteReadOnly && ((a & FILE_ATTRIBUTE_READONLY) != 0)) > 665: attrSet = SetFileAttributesW(path, a & (~FILE_ATTRIBUTE_READONLY)); A small comment on the name "attrSet". It hints that it will be set to TRUE if the attribute is set whereas the use here is to mean that SetFileAttributesW has succeeded, a bit confusing because it's clearing the READONLY value, not setting it. If you rename to something that has the word "modified" or "cleared" might be easy for future maintainers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2844767305 PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070223272 PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070222588 From duke at openjdk.org Thu May 1 13:06:50 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 1 May 2025 13:06:50 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 12:56:42 GMT, Chen Liang wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 488: > >> 486: /** >> 487: * {@inheritDoc CharSequence} >> 488: */ > > Suggestion: > > * {@inheritDoc CharSequence} > * @param srcBegin {@inheritDoc CharSequence} > * @param srcEnd {@inheritDoc CharSequence} > * @param dst {@inheritDoc CharSequence} > * @param dstBegin {@inheritDoc CharSequence} > * @throws IndexOutOfBoundsException {@inheritDoc CharSequence} > */ > > Let's aim for text parity for now; can you create a bug for Javadoc for this inheritDoc inconsistency? I can open a bug report, but I think text parity makes no sense: There are lots of other places in OpenJDK where the short form is used already, so there will not be any benefit of text parity with just one other code location, but it will force use to open another JBS / PR once the bug is fixed to come back to the short form. So it brings just work but we gain nothing IMHO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070246526 From rriggs at openjdk.org Thu May 1 13:41:01 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 13:41:01 GMT Subject: RFR: 8354334: Remove @ValueBased from ProcessHandle Message-ID: Remove internal ValueBased annotation from the ProcessHandle interface declaration. The implementation remains value based as described in the javadoc. Remove unnecessary "public" keyword in interfaces and cleanup javadoc. ------------- Commit messages: - 8354334: Remove @ValueBased from ProcessHandle Changes: https://git.openjdk.org/jdk/pull/24986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354334 Stats: 16 lines in 1 file changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24986/head:pull/24986 PR: https://git.openjdk.org/jdk/pull/24986 From rriggs at openjdk.org Thu May 1 13:55:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 13:55:46 GMT Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen wrote: > Similar to #24959, java.util.Locale.hashCode can also make the same improvement. > > Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode. lgltm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24971#pullrequestreview-2809829827 From liach at openjdk.org Thu May 1 14:01:55 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 14:01:55 GMT Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen wrote: > Similar to #24959, java.util.Locale.hashCode can also make the same improvement. > > Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode. Thanks for this cleanup, indeed equivalent. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24971#pullrequestreview-2809839693 From liach at openjdk.org Thu May 1 14:02:46 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 14:02:46 GMT Subject: RFR: 8354334: Remove @ValueBased from ProcessHandle In-Reply-To: References: Message-ID: On Thu, 1 May 2025 13:36:13 GMT, Roger Riggs wrote: > Remove internal ValueBased annotation from the ProcessHandle interface declaration. > The implementation remains value based as described in the javadoc. > Remove unnecessary "public" keyword in interfaces and cleanup javadoc. Good cleanup, now interfaces are no longer identity or value. src/java.base/share/classes/java/lang/ProcessHandle.java line 287: > 285: * {@link java.util.concurrent.Future#get() wait} for it to terminate. > 286: * {@link java.util.concurrent.Future#cancel(boolean) Cancelling} > 287: * the {@linkplain CompletableFuture CompletableFuture} does not affect the Process. Suggestion: * the {@linkplain CompletableFuture} does not affect the Process. is sufficient. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24986#pullrequestreview-2809842025 PR Review Comment: https://git.openjdk.org/jdk/pull/24986#discussion_r2070303153 From duke at openjdk.org Thu May 1 14:15:48 2025 From: duke at openjdk.org (Hendrik Schick) Date: Thu, 1 May 2025 14:15:48 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs wrote: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. test/jdk/java/lang/StringBuilder/StringBuilderRepeat.java line 110: > 108: String expected = "repeat233333233333-2-3-3-3-3-3\u2461\u2462\u2462\u2462\u2462\u2462\u2461\u2462\u2462\u2462\u2462\u2462-\u2461-\u2462-\u2462-\u2462-\u2462-\u2462abcabcabc" + > 109: "nullnullnullnullnullnullnullnullnullnullnullnull"; > 110: assertEquals(expected, sb.toString()); copyright year update missing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2070317617 From weijun at openjdk.org Thu May 1 14:50:31 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 14:50:31 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: > Finalize the KDF API. Weijun Wang 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 - add a positive debug log and update exception message - enhancing exception messages and debug outputs - update @since tags as required by JEP 12 - add enum back - the change ------------- Changes: https://git.openjdk.org/jdk/pull/24520/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=04 Stats: 206 lines in 17 files changed: 158 ins; 29 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From vromero at openjdk.org Thu May 1 15:06:06 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 1 May 2025 15:06:06 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 02:32:06 GMT, Chen Liang wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253: > >> 4251: >> 4252: # lint: identity >> 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\ > > How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint? the requirement is for the identity lint warning to be an alias of the synchronization warning ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2053222093 From liach at openjdk.org Thu May 1 15:06:05 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 15:06:05 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 00:06:26 GMT, Vicente Romero wrote: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1: > 1: /* Need to add handling of `RequiresIdentity` in `createAnnotation` src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253: > 4251: > 4252: # lint: identity > 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\ How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049917728 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049921677 From vromero at openjdk.org Thu May 1 15:06:04 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 1 May 2025 15:06:04 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API Message-ID: This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. For more details please refer to the complete description in the corresponding JIRA entry [1] TIA [1] https://bugs.openjdk.org/browse/JDK-8354556 ------------- Commit messages: - final adjustments - additional refactorings - removing unneeded changes - more refactorings - more refactorings and tests - refactoring - refactoring - covering more cases plus refactoring in order to simplify the code - Merge branch 'JDK-8354556' of https://github.com/vicente-romero-oracle/jdk into JDK-8354556 - additional coverage for other uses of types - ... and 11 more: https://git.openjdk.org/jdk/compare/4dd64b49...5e3acc92 Changes: https://git.openjdk.org/jdk/pull/24746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354556 Stats: 495 lines in 25 files changed: 469 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From liach at openjdk.org Thu May 1 15:44:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 15:44:53 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v2] In-Reply-To: <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com> References: <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com> Message-ID: <9waxLSP10cwzA8b5lKJjSfnELxy6TcQg5U7feCkE3X0=.253d4943-09f9-4059-bc3b-cbacbae33a9d@github.com> On Wed, 30 Apr 2025 23:02:24 GMT, Chen Liang wrote: >> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Add a test case, fails isWrapperInstance on mainline > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/mhp-wrapper-check-async > - 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe Re jai for repeating: do we want this repeat for a single run or all tier1 runs (which I will use junit RepeatedTest) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23757#issuecomment-2845095159 From jpai at openjdk.org Thu May 1 15:37:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 1 May 2025 15:37:52 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v2] In-Reply-To: <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com> References: <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com> Message-ID: On Wed, 30 Apr 2025 23:02:24 GMT, Chen Liang wrote: >> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Add a test case, fails isWrapperInstance on mainline > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/mhp-wrapper-check-async > - 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe Thank you Chen for adding the test. The test looks OK to me. Please add `8350549` to the `@bug` in the test definition. I think a brief comment on the test method would make it easier to understand what it does. Would you consider adding a comment, something like: /** * The test verifies that MethodHandleProxies.asInterfaceInstance() and * MethodHandleProxies.isWrapperInstance() work as expected when invoked concurrently. */ Finally, given the nature of this new test, I think it would be good to have it run in our CI with a test repeat of around 50 to be sure that it doesn't fail intermittently. test/jdk/java/lang/invoke/MethodHandleProxies/BasicTest.java line 275: > 273: .limit(100) > 274: .forEach(inst -> assertTrue(MethodHandleProxies.isWrapperInstance(inst), > 275: () -> Objects.toIdentityString(inst))); Nit - the failure message (if at all it fails for any reason) could perhaps be: Objects.toIdentityString(inst) + " was expected to be a wrapper instance, but isn't" ------------- PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequestreview-2810048465 PR Review Comment: https://git.openjdk.org/jdk/pull/23757#discussion_r2070418275 From swen at openjdk.org Thu May 1 15:49:53 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 1 May 2025 15:49:53 GMT Subject: Integrated: 8356021: Use Double::hashCode in java.util.Locale::hashCode In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen wrote: > Similar to #24959, java.util.Locale.hashCode can also make the same improvement. > > Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode. This pull request has now been integrated. Changeset: 2ad639f1 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/2ad639f1b33fcd8e218e8ad549caf32024a36cb2 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8356021: Use Double::hashCode in java.util.Locale::hashCode Reviewed-by: rriggs, liach ------------- PR: https://git.openjdk.org/jdk/pull/24971 From bpb at openjdk.org Thu May 1 15:57:46 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 May 2025 15:57:46 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) In-Reply-To: References: Message-ID: On Thu, 1 May 2025 12:40:41 GMT, Alan Bateman wrote: > It will need a release note too. The issue is already so labelled. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845119678 From liach at openjdk.org Thu May 1 14:39:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 14:39:53 GMT Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version [v7] In-Reply-To: References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Message-ID: On Wed, 30 Apr 2025 22:12:20 GMT, Chen Liang wrote: >> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions. >> >> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse > - review: improve comments about implicit null checks > - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse > - Adapt the location APIs > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags > - 8355956: Prepare javap for class file format aware access flag parsing > - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse > - Explicit imports > - Wording updates > - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse > - ... and 21 more: https://git.openjdk.org/jdk/compare/e36756b2...b1cf4ebb Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2844964939 From liach at openjdk.org Thu May 1 14:39:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 14:39:53 GMT Subject: Integrated: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Message-ID: On Fri, 18 Apr 2025 20:33:27 GMT, Chen Liang wrote: > Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions. > > A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955. This pull request has now been integrated. Changeset: bee273d6 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/bee273d6b4e34692952d4e7474ab72ee5c54e33a Stats: 159 lines in 10 files changed: 99 ins; 23 del; 37 mod 8297271: AccessFlag.maskToAccessFlags should be specific to class file version Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/24760 From duke at openjdk.org Thu May 1 15:05:48 2025 From: duke at openjdk.org (Jason Mehrens) Date: Thu, 1 May 2025 15:05:48 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 23:38:02 GMT, Brian Burkhalter wrote: > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. Will the new property will also change behavior of java.io.File.deleteOnExit() and java.nio.file.StandardOpenOption.DELETE_ON_CLOSE? Might want to talk about that in the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845018199 From bpb at openjdk.org Thu May 1 15:57:48 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 May 2025 15:57:48 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) In-Reply-To: References: Message-ID: On Thu, 1 May 2025 15:03:02 GMT, Jason Mehrens wrote: > Will the new property will also change behavior of java.io.File.deleteOnExit() Yes, as that calls `File.delete`. > and java.nio.file.StandardOpenOption.DELETE_ON_CLOSE? No. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845125188 From alanb at openjdk.org Thu May 1 16:18:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 May 2025 16:18:46 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) In-Reply-To: References: Message-ID: On Thu, 1 May 2025 15:54:39 GMT, Brian Burkhalter wrote: > > Will the new property will also change behavior of java.io.File.deleteOnExit() > > Yes, as that calls `File.delete`. Jason's message is a reminder that we will need to find everything that might be accidentally depending on the behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845169530 From darcy at openjdk.org Thu May 1 16:25:53 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 May 2025 16:25:53 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com> On Thu, 1 May 2025 13:03:47 GMT, Markus KARG wrote: >> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 488: >> >>> 486: /** >>> 487: * {@inheritDoc CharSequence} >>> 488: */ >> >> Suggestion: >> >> * {@inheritDoc CharSequence} >> * @param srcBegin {@inheritDoc CharSequence} >> * @param srcEnd {@inheritDoc CharSequence} >> * @param dst {@inheritDoc CharSequence} >> * @param dstBegin {@inheritDoc CharSequence} >> * @throws IndexOutOfBoundsException {@inheritDoc CharSequence} >> */ >> >> Let's aim for text parity for now; can you create a bug for Javadoc for this inheritDoc inconsistency? > > I can open a bug report, but I think text parity makes no sense: There are lots of other places in OpenJDK where the short form is used already, so there will not be any benefit of text parity with just one other code location, but it will force us to open another JBS / PR once the bug is fixed to come back to the short form. So it brings just work but we gain nothing IMHO. There are subtleties and perhaps surprises in `@inheritDoc`, but that doesn't necessarily imply the current behavior is buggy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070475122 From smarks at openjdk.org Thu May 1 16:57:53 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 1 May 2025 16:57:53 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 09:51:41 GMT, Tatsunori Uchino wrote: >> Anyway you need to merge master first to test `stdin.encoding`. > > `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you. Hello @tats-u , there is no bother, I appreciate you looking at this. The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful. Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512. In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070508985 From bpb at openjdk.org Thu May 1 17:07:45 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 May 2025 17:07:45 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) In-Reply-To: References: Message-ID: On Thu, 1 May 2025 16:16:22 GMT, Alan Bateman wrote: > [...] we will need to find everything that might be accidentally depending on the behavior. So far I found only `SetAccess` but there is more testing to do, as well as code scanning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845262183 From jvernee at openjdk.org Thu May 1 16:58:47 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 1 May 2025 16:58:47 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 10:20:44 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 163: >> >>> 161: lock.unlock(); >>> 162: } >>> 163: Reference.reachabilityFence(arena); >> >> I'm not sure this is enough to keep the automatic arena alive. If the client lets the Frame arena go out of scope w/o calling close, then `arena` will become unreachable, but some segments created by the Frame arena might still be reachable. To be more correct, I think `Frame` should add a "close action" to its confined arena which keeps the outer automatic arena alive. This can be done, for instance, by passing a close action to the `reinterpret` call: >> >> >> frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, () -> Reference.reachabilityFence(arena))); >> >> >> The close action is installed in the `MemorySession` object of `confinedArena` -- which is then attached to all segments returned by `Frame` -- thus keeping the automatic arena alive. > > (if you agree with this analysis, perhaps adding an extra stress test, or tweaking one of the existing stress tests to check this could also be useful) I've thought about it a bit, and I think adding a cleanup action to the reinterpret call is indeed the only fool proof way to add a link back to the parent segment. MemorySegment is what gives a user access to the memory (almost like an access token), so the memory needs to be kept alive through the MS. MS has a reference to its scope, which can then reference the original scope through a cleanup action. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070510278 From joehw at openjdk.org Thu May 1 17:07:56 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 1 May 2025 17:07:56 GMT Subject: Integrated: 8354084: Streamline XPath API's extension function control In-Reply-To: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com> References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com> Message-ID: On Fri, 11 Apr 2025 23:05:51 GMT, Joe Wang wrote: > Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions. > > Note the comment in JAXPExtensionsProvider, starting at "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions. > > Tests: > Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757). > JCK passed except the previously reported issue (JCK-7322355). This pull request has now been integrated. Changeset: cf0db963 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/cf0db96314863376254bacbff4eefd13e3527707 Stats: 464 lines in 9 files changed: 211 ins; 241 del; 12 mod 8354084: Streamline XPath API's extension function control Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/24605 From duke at openjdk.org Thu May 1 17:20:49 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 1 May 2025 17:20:49 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com> References: <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com> Message-ID: On Thu, 1 May 2025 16:23:13 GMT, Joe Darcy wrote: >> I can open a bug report, but I think text parity makes no sense: There are lots of other places in OpenJDK where the short form is used already, so there will not be any benefit of text parity with just one other code location, but it will force us to open another JBS / PR once the bug is fixed to come back to the short form. So it brings just work but we gain nothing IMHO. > > There are subtleties and perhaps surprises in `@inheritDoc`, but that doesn't necessarily imply the current behavior is buggy. So it is actually *wanted* behavior that in one situation the text *is* inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070545048 From jvernee at openjdk.org Thu May 1 17:21:45 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 1 May 2025 17:21:45 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 16:34:14 GMT, Chen Liang wrote: >> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review suggestions Changes look good. Thanks! ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequestreview-2810276387 From darcy at openjdk.org Thu May 1 17:29:54 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 May 2025 17:29:54 GMT Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails intermittently in tier6 [v2] In-Reply-To: References: Message-ID: On Thu, 24 Apr 2025 16:24:53 GMT, Stuart Marks wrote: >> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor. >> On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers. > > Note, the timeout factor also adjusts the jtreg timeout for the entire test. The adjustTimeout() method allows internal test timeouts to scale along with the jtreg timeout. > Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor. On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers. Catching up on PR comments, to make my concerns more explicit: it is best is we don't pessimize the common case of increasing the _minimum_ run time of the test in order to make the test more robust in highly-contended situations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2070554333 From naoto at openjdk.org Thu May 1 16:29:50 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 May 2025 16:29:50 GMT Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen wrote: > Similar to #24959, java.util.Locale.hashCode can also make the same improvement. > > Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode. Thanks for the fix. Even though the fix is trivial and small, please keep the PR open at least for 24 hours so that every region of the globe can see the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24971#issuecomment-2845189930 From liach at openjdk.org Thu May 1 16:34:14 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 16:34:14 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v3] In-Reply-To: References: Message-ID: > Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Review suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23757/files - new: https://git.openjdk.org/jdk/pull/23757/files/60404635..eb405dd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23757&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23757&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23757.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23757/head:pull/23757 PR: https://git.openjdk.org/jdk/pull/23757 From smarks at openjdk.org Thu May 1 17:54:47 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 1 May 2025 17:54:47 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test src/java.base/share/classes/java/io/Reader.java line 408: > 406: *

This method works as if invoking it were equivalent to evaluating > 407: * the expression: > 408: *

{@linkplain #readAllChars()}.lines().toList()
I think this is actually too specific, as it could imply the returned List is the exact implementation that is returned by Stream.toList(). It is in this implementation, but I could easily imagine another implementation that constructs the list a different way. It might be better to be descriptive here and say that the entire input is read and is split into lines (where "line" is defined as above) which are returned in an unmodifiable list. And then have "unmodifiable list" be a link to the Unmodifiable Lists section, something like "java/util/List.html#unmodifiable". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070581767 From liach at openjdk.org Thu May 1 17:38:43 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 17:38:43 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v3] In-Reply-To: References: Message-ID: <9j4Q0K-DT0X_lM2ysFJ-u17cbdHSmmsmCGWZu36CYJ0=.db78f2e1-d9a6-46c3-b9ce-294cdb301d56@github.com> On Thu, 1 May 2025 16:34:14 GMT, Chen Liang wrote: >> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review suggestions Thanks for the reviews. On baseline this new test has a 50% failure rate so we should be likely to trigger when running on all platforms. Missed the bug id in last push; pushed again, and please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23757#issuecomment-2845325170 From jlahoda at openjdk.org Thu May 1 17:44:47 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 May 2025 17:44:47 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v7] In-Reply-To: References: Message-ID: <79mjbgCz8a1HC6r0_an5GwcY6lWssji50XWSoV1lrlM=.5fea494d-0bad-4e73-a482-090f47663302@github.com> > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: - Merge branch 'master' into finalize-concise-source-files - Merge branch 'master' into finalize-concise-source-files - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files - Add clause about handling of malformed/unmappable bytes. - Rewrite bits about charset decoding, removing mention of "internal objects." - Use local variable for System.out in print(). - Reverting test commit. This reverts commit 7047cf007cc7de937aa21e96125083ee92932692. - Fixing tests. - Updating copyright year. - Adding bug number to tests. - ... and 28 more: https://git.openjdk.org/jdk/compare/6b553acb...3868019e ------------- Changes: https://git.openjdk.org/jdk/pull/24438/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=06 Stats: 1060 lines in 59 files changed: 336 ins; 585 del; 139 mod Patch: https://git.openjdk.org/jdk/pull/24438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438 PR: https://git.openjdk.org/jdk/pull/24438 From smarks at openjdk.org Thu May 1 17:46:52 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 1 May 2025 17:46:52 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test src/java.base/share/classes/java/io/Reader.java line 405: > 403: * a carriage return followed immediately by a line feed, or by reaching the > 404: * end-of-file (EOF). > 405: * I think the definition here should be copied from String.lines(), or it should refer to it. The main difference is that spec is explicit about a line being zero-or-more chars followed by a line terminator or one-or-more chars followed by EOF. This implies there is no blank line between a trailing line terminator and EOF. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070573057 From jlahoda at openjdk.org Thu May 1 17:48:22 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 1 May 2025 17:48:22 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v8] In-Reply-To: References: Message-ID: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com> > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updating copyright year. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24438/files - new: https://git.openjdk.org/jdk/pull/24438/files/3868019e..5d0a867f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438 PR: https://git.openjdk.org/jdk/pull/24438 From duke at openjdk.org Thu May 1 18:17:50 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Thu, 1 May 2025 18:17:50 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 13:34:07 GMT, Oleksii Sylichenko wrote: > This PR proposes three improvements to the `Basic.java` test: > > 1. Increase Timeout > - The current timeout is insufficient when running the test in IntelliJ IDEA. > - I propose increasing it by one minute. > - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. > > 2. Fix Incompatibility with Windows (Cygwin vs. Native) > - One of the tests executes the `echo` command. > - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). > - I propose replacing echo with `cmd /c echo.`, which produces the same output (a single newline) in Windows, ensuring compatibility. > > 3. Prevent Autorun Scripts in the `cmd /c set` Command > - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. > - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. > > These changes improve test reliability and ensure compatibility across different environments. > Testing: > - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. > - Confirmed that `cmd /c echo.` produces the expected output in Windows. > - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. > > # Detailed Description > > ## echo > The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) with envstrings without any `=' > //---------------------------------------------------------------- > > with following error: > > Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified > > > ## cmd.exe /c set > The following test fails in a Windows environment under specific conditions: > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) > // Check for sort order of environment variables on Windows. > //---------------------------------------------------------------- > > with following error: > >>'+=+ > BAZ=GORP > CONDA_BAT=C:\.......\\miniconda3\\condabin\\conda.bat > CONDA_EXE=C:\........\\miniconda3\\Scripts\\conda.exe > CONDA_SHLVL=0 > FOO=BAR > PATH=C:\.........\\miniconda3\\condabin; > QUUX= > SystemRoot=C:\\WINDOWS > _=_ > ~=~ > '< not equal to '+=+ > BAZ=GORP > FOO=BAR > QUUX= > SystemRoot=C:\\WINDOWS > _=_ > ~=~ > ' > > > **Reason** > In my ... keep-alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/23933#issuecomment-2845409656 From bpb at openjdk.org Thu May 1 18:31:37 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 May 2025 18:31:37 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v2] In-Reply-To: References: Message-ID: > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355954: Address comments on naming in the PR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24977/files - new: https://git.openjdk.org/jdk/pull/24977/files/84905743..efca3cf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=00-01 Stats: 15 lines in 3 files changed: 2 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977 PR: https://git.openjdk.org/jdk/pull/24977 From naoto at openjdk.org Thu May 1 17:44:48 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 May 2025 17:44:48 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 16:55:06 GMT, Stuart Marks wrote: >> `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you. > > Hello @tats-u , there is no bother, I appreciate you looking at this. > > The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful. > > Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512. > > In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK. `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070569424 From smarks at openjdk.org Thu May 1 18:03:51 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 1 May 2025 18:03:51 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test src/java.base/share/classes/java/io/BufferedReader.java line 413: > 411: *

This method works as if invoking it were equivalent to evaluating > 412: * the expression: > 413: *

{@linkplain #lines()}.toList()
I'd suggest avoiding being too specific here, as this implies that this method will invoke the `lines()` method which can be overridden by a subclass. One could have an argument about whether this indeed is implied by the "as if" wording but I think it would be preferable to avoid this. I also think we don't want to have this method depend on possible overridden methods, so that we can provide a future optimized implementation without breaking something. Thus I think most of this doc comment can be inherited form Reader, even though the implementation might be overridden. src/java.base/share/classes/java/io/BufferedReader.java line 433: > 431: public List readAllLines() throws IOException { > 432: try { > 433: return lines().toList(); I'd suggest not having this method's implementation depend on an overridable method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070590867 PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070591288 From vromero at openjdk.org Thu May 1 18:32:00 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 1 May 2025 18:32:00 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v8] In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com> References: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com> Message-ID: On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) >> - `java. ... .IO` is no longer automatically imported in any compilation unit >> - the feature is finalized (i.e. no longer requires `--enable-preview`) > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Updating copyright year. last changes lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810409833 From adinn at openjdk.org Thu May 1 18:54:50 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 1 May 2025 18:54:50 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes In-Reply-To: References: Message-ID: <5vOdChaItphSz0dAvDqdniRjHRAAzeUBu2e7rxMkS54=.05079043-e02a-4853-891e-c7d34919af8d@github.com> On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam wrote: > This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). > > AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues) > > In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table. > > I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase. @iklam We have seen this problem with Red Hat deployments in jdk24 as well as jdk25-ea. I'm saying that mostly for information. However, I do have to ask: If this is fixed for jdk25 is there any question of also fixing it in jdk24? I would be content to receive a no answer -- a similar issue with patch that could be backported from jdk26 -> jdk25 might be something to think about a bit more? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24956#issuecomment-2845492119 From bpb at openjdk.org Thu May 1 18:31:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 May 2025 18:31:38 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v2] In-Reply-To: References: Message-ID: <_5k1CPtAMmKlN2ZjGxsP7j6V_GQ77RziAbkh1avwSWE=.ba639ea9-ba14-482a-9bcd-97211c3c0b8c@github.com> On Thu, 1 May 2025 12:40:02 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8355954: Address comments on naming in the PR > > src/java.base/windows/classes/java/io/WinNTFileSystem.java line 45: > >> 43: >> 44: private static final boolean DELETE_READONLY = >> 45: Boolean.getBoolean("jdk.io.File.deleteReadOnly"); > > What would you think of allowDeleteReadOnlyFiles rather than deleteReadOnly? Sounds better. So changed in efca3cf. > src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 665: > >> 663: BOOL attrSet = FALSE; >> 664: if (deleteReadOnly && ((a & FILE_ATTRIBUTE_READONLY) != 0)) >> 665: attrSet = SetFileAttributesW(path, a & (~FILE_ATTRIBUTE_READONLY)); > > A small comment on the name "attrSet". It hints that it will be set to TRUE if the attribute is set whereas the use here is to mean that SetFileAttributesW has succeeded, a bit confusing because it's clearing the READONLY value, not setting it. If you rename to something that has the word "modified" or "cleared" might be easy for future maintainers. Name updated in efca3cf. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070627406 PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070627002 From kbarrett at openjdk.org Thu May 1 19:20:48 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 1 May 2025 19:20:48 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v7] In-Reply-To: References: <1tGRJ4ejgEBN_prDxdLQajmtGU4whVg5OAH8ziKR3pQ=.9b4a8e19-0fec-43a3-a357-4f63d6f7078c@github.com> Message-ID: On Wed, 30 Apr 2025 20:23:13 GMT, Brent Christian wrote: > It spins until at least one `MyObject` has entered `finalize()` before proceeding to fetch the histogram. My eyes must be going. Somehow I read that as a `-1`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2070687204 From kbarrett at openjdk.org Thu May 1 19:33:48 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 1 May 2025 19:33:48 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v7] In-Reply-To: References: <1tGRJ4ejgEBN_prDxdLQajmtGU4whVg5OAH8ziKR3pQ=.9b4a8e19-0fec-43a3-a357-4f63d6f7078c@github.com> Message-ID: On Thu, 1 May 2025 19:17:42 GMT, Kim Barrett wrote: >> It spins until at least one `MyObject` has entered `finalize()` before proceeding to fetch the histogram. > >> It spins until at least one `MyObject` has entered `finalize()` before proceeding to fetch the histogram. > > My eyes must be going. Somehow I read that as a `-1`. I still think this loop isn't actually needed. What the test is interested in is having final references in the finalizer queue. Waiting for reference processing does that. Waiting for trappedCount to be non-zero (really, waiting for 1, with more than one indicating a problem with the locking and possible failure to keep the objects in the finalizer queue), isn't necessary for the remainder of the test to work. I think trappedCount isn't needed at all in the current version, and should either be removed or made useful in some fashion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2070702444 From rriggs at openjdk.org Thu May 1 19:22:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 19:22:48 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v11] In-Reply-To: <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com> Message-ID: <33QRkIdttGlAkEQOo1lBKm2j-2fgofs1OuaC9qk_-sU=.dd89a944-affc-4ac0-aa29-adadb5d030e1@github.com> On Tue, 22 Apr 2025 16:51:05 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: Add Reader.readAllLines; test not yet updated > > src/java.base/share/classes/java/io/Reader.java line 403: > >> 401: * by any one of a line feed ('\n'), a carriage return ('\r'), a carriage >> 402: * return followed immediately by a line feed, or by reaching the >> 403: * end-of-file (EOF). > > Reader is for reading characters so I think the starting line will say that is reads all remaining characters as lines of text. > > In any case, I think you've enough here to help decide if a method should be added to Reader. I think the main observation is that it doesn't require Reader to be buffering. The description of the method should be the same in Reader and BufferedReader with respect to the behavior, line break handling, etc. It should be possible to use {@inheritDoc} to re-use it in BufferedReader. Except for the description of the implementation, that can be in an {@impSpec} paragraph. The method is consuming characters from the stream, assembling lines and returning list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070687773 From vlivanov at openjdk.org Thu May 1 18:29:50 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 May 2025 18:29:50 GMT Subject: RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786 In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> Message-ID: On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation. > But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime. > > This change the behaviour of existing jdk, and it should not throw exception anyway. > > @iwanowww @RealFYang > > Thanks! I want to understand the issue with missing entries in vector math native libraries first before making a decision how to proceed. > I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different. Sorry, I don't get it. How does it affect the contents of the native library? JDK vendors do have an option to bundle the library or drop it from their distribution. But when SLEEF-based and SVML math libraries are built by JDK there's no distinction between entries being included in the library. If a vendor modifies make files or native library code, it's up to them to adjust JDK accordingly. Upstream JDK doesn't have to take such scenarios into account. I looked through SVML and SLEEF-based vector math code and noticed there are some capability check [1] [2] [3] guarding library code. It means that if some library entry is missing, then the whole library is empty. Can you confirm it's the case you see? [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc#L35 [2] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc#L28 [3] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/unix/native/libsleef/lib/vector_math_rvv.c#L36 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2845433084 From rriggs at openjdk.org Thu May 1 19:26:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 19:26:47 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 13:34:07 GMT, Oleksii Sylichenko wrote: > This PR proposes three improvements to the `Basic.java` test: > > 1. Increase Timeout > - The current timeout is insufficient when running the test in IntelliJ IDEA. > - I propose increasing it by one minute. > - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. > > 2. Fix Incompatibility with Windows (Cygwin vs. Native) > - One of the tests executes the `echo` command. > - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). > - I propose replacing echo with `cmd /c echo.`, which produces the same output (a single newline) in Windows, ensuring compatibility. > > 3. Prevent Autorun Scripts in the `cmd /c set` Command > - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. > - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. > > These changes improve test reliability and ensure compatibility across different environments. > Testing: > - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. > - Confirmed that `cmd /c echo.` produces the expected output in Windows. > - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. > > # Detailed Description > > ## echo > The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) with envstrings without any `=' > //---------------------------------------------------------------- > > with following error: > > Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified > > > ## cmd.exe /c set > The following test fails in a Windows environment under specific conditions: > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) > // Check for sort order of environment variables on Windows. > //---------------------------------------------------------------- > > with following error: > >>'+=+ > BAZ=GORP > CONDA_BAT=C:\.......\\miniconda3\\condabin\\conda.bat > CONDA_EXE=C:\........\\miniconda3\\Scripts\\conda.exe > CONDA_SHLVL=0 > FOO=BAR > PATH=C:\.........\\miniconda3\\condabin; > QUUX= > SystemRoot=C:\\WINDOWS > _=_ > ~=~ > '< not equal to '+=+ > BAZ=GORP > FOO=BAR > QUUX= > SystemRoot=C:\\WINDOWS > _=_ > ~=~ > ' > > > **Reason** > In my ... test/jdk/java/lang/ProcessBuilder/Basic.java line 1843: > 1841: //---------------------------------------------------------------- > 1842: try { > 1843: String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo."} : new String[]{"echo"}; Why the extra "." in the echo string? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070694582 From dfuchs at openjdk.org Thu May 1 17:36:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 May 2025 17:36:49 GMT Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails intermittently in tier6 [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 17:26:48 GMT, Joe Darcy wrote: >> Note, the timeout factor also adjusts the jtreg timeout for the entire test. The adjustTimeout() method allows internal test timeouts to scale along with the jtreg timeout. > >> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor. On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers. > > Catching up on PR comments, to make my concerns more explicit: it is best is we don't pessimize the common case of increasing the _minimum_ run time of the test in order to make the test more robust in highly-contended situations. Right. But it's still way better than hard to diagnose intermittent failures. If this [the 2s x timeout factor minimum time] becomes an issue - I guess we could update the test to only test the case where there should no longer be a deadlock - and remove the self-test that proves that a deadlock would be detected if there was one. That would need to be carried out in a different PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2070562152 From kbarrett at openjdk.org Thu May 1 19:37:02 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 1 May 2025 19:37:02 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v13] In-Reply-To: References: Message-ID: <_MaD4F7X83A_LevqwBFFnJ7vcXjNhT0k5CPU6dWxq9M=.54ae4358-d6dc-4c51-809e-62667b3330db@github.com> On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. >> >> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [x] Linux x86_64 server fastdebug, `all` >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > A bit more comments FYI, I've been working on some more ideas here. I hope to have more to report in the next couple of days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2845588548 From liach at openjdk.org Thu May 1 18:57:50 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 18:57:50 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v8] In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com> References: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com> Message-ID: On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) >> - `java. ... .IO` is no longer automatically imported in any compilation unit >> - the feature is finalized (i.e. no longer requires `--enable-preview`) > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Updating copyright year. src/java.base/share/classes/java/lang/IO.java line 157: > 155: *

> 156: * Writes a prompt as if by calling {@code print}, and then reads a single > 157: * line of text as if by calling {@link readln readln()}. Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`. src/java.base/share/classes/java/lang/IO.java line 179: > 177: * the reader() method. > 178: */ > 179: static BufferedReader br; The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070645283 PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070647143 From duke at openjdk.org Thu May 1 20:29:46 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Thu, 1 May 2025 20:29:46 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: Message-ID: On Thu, 1 May 2025 19:24:13 GMT, Roger Riggs wrote: >> This PR proposes three improvements to the `Basic.java` test: >> >> 1. Increase Timeout >> - The current timeout is insufficient when running the test in IntelliJ IDEA. >> - I propose increasing it by one minute. >> - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. >> >> 2. Fix Incompatibility with Windows (Cygwin vs. Native) >> - One of the tests executes the `echo` command. >> - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). >> - I propose replacing echo with `cmd /c echo.`, which produces the same output (a single newline) in Windows, ensuring compatibility. >> >> 3. Prevent Autorun Scripts in the `cmd /c set` Command >> - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. >> - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. >> >> These changes improve test reliability and ensure compatibility across different environments. >> Testing: >> - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. >> - Confirmed that `cmd /c echo.` produces the expected output in Windows. >> - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. >> >> # Detailed Description >> >> ## echo >> The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): >> >> //---------------------------------------------------------------- >> // Test Runtime.exec(...envp...) with envstrings without any `=' >> //---------------------------------------------------------------- >> >> with following error: >> >> Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified >> >> >> ## cmd.exe /c set >> The following test fails in a Windows environment under specific conditions: >> >> //---------------------------------------------------------------- >> // Test Runtime.exec(...envp...) >> // Check for sort order of environment variables on Windows. >> //---------------------------------------------------------------- >> >> with following error: >> >>>'+=+ >> BAZ=GORP >> CONDA_BAT=C:\.......\\miniconda3\\condabin\\conda.bat >> CONDA_EXE=C:\........\\miniconda3\\Scripts\\conda.exe >> CONDA_SHLVL=0 >> FOO=BAR >> PATH=C:\.........\\miniconda3\\condabin; >> QUUX= >> SystemRoot=C:\\WIN... > > test/jdk/java/lang/ProcessBuilder/Basic.java line 1843: > >> 1841: //---------------------------------------------------------------- >> 1842: try { >> 1843: String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo."} : new String[]{"echo"}; > > Why the extra "." in the echo string? In Windows CMD, the `echo` command, when called without arguments, displays the current state of the command echoing mode ? either enabled (`ON`) or disabled (`OFF`). For the case when this test is run from IntelliJ IDEA. And the `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. And to ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c echo.`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070763745 From rriggs at openjdk.org Thu May 1 21:08:29 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 21:08:29 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v2] In-Reply-To: References: Message-ID: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Added missing bugid to tests Applied review suggestions. Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores. Updated missing copyright years. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/b59a2e9a..f5003244 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=00-01 Stats: 55 lines in 6 files changed: 16 ins; 14 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From swen at openjdk.org Thu May 1 18:16:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 1 May 2025 18:16:50 GMT Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode In-Reply-To: References: Message-ID: <9DKNGgorVgpZOig2AsE3iVx3ZsexlX9r7WDTbBsY6lA=.8b79a8b2-4a61-4d66-99ab-a254adb09fb0@github.com> On Thu, 1 May 2025 16:27:17 GMT, Naoto Sato wrote: >> Similar to #24959, java.util.Locale.hashCode can also make the same improvement. >> >> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode. > > Thanks for the fix. Even though the fix is trivial and small, please keep the PR open at least for 24 hours so that every region of the globe can see the fix. @naotoj Thank you for your reminder. There is a problem with GitHub's prompt. It shows yesterday in less than 24 hours. I will avoid this problem next time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24971#issuecomment-2845399910 From myankelevich at openjdk.org Thu May 1 21:27:48 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 21:27:48 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 20:17:57 GMT, Alexander Matveev wrote: > - Symbolic links will not be followed for `--app-content` on all platforms. > - Added test to cover this case. > - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. test/jdk/tools/jpackage/share/AppContentTest.java line 57: > 55: */ > 56: public class AppContentTest { > 57: Nitpick: do you think it might be worth it to add a bug id to the `@test`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2070827582 From bchristi at openjdk.org Thu May 1 21:47:01 2025 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 1 May 2025 21:47:01 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v9] In-Reply-To: References: Message-ID: > I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures: > > * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method > * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger` > * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: remove unneeded 'trappedCount' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24143/files - new: https://git.openjdk.org/jdk/pull/24143/files/0468fe73..88b26871 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24143/head:pull/24143 PR: https://git.openjdk.org/jdk/pull/24143 From rriggs at openjdk.org Thu May 1 21:32:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 21:32:47 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: Message-ID: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> On Thu, 1 May 2025 20:27:01 GMT, Oleksii Sylichenko wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 1843: >> >>> 1841: //---------------------------------------------------------------- >>> 1842: try { >>> 1843: String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo."} : new String[]{"echo"}; >> >> Why the extra "." in the echo string? > > In Windows CMD, the `echo` command, when called without arguments, displays the current state of the command echoing mode ? either enabled (`ON`) or disabled (`OFF`). For the case when this test is run from IntelliJ IDEA. > > And the `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. > > And to ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c echo.`. Is `echo.` shorthand for `echo.exe`; if so, please change to the long form to make it clearer the echo program is being run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070834029 From duke at openjdk.org Thu May 1 22:01:07 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Thu, 1 May 2025 22:01:07 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> References: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> Message-ID: On Thu, 1 May 2025 21:30:30 GMT, Roger Riggs wrote: >> In Windows CMD, the `echo` command, when called without arguments, displays the current state of the command echoing mode ? either enabled (`ON`) or disabled (`OFF`). For the case when this test is run from IntelliJ IDEA. >> >> And the `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. >> >> And to ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c echo.`. > > Is `echo.` shorthand for `echo.exe`; if so, please change to the long form to make it clearer the echo program is being run. No, `echo.` is not an executable, this is a command of the Windows Command Processor. See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070858894 From rriggs at openjdk.org Thu May 1 19:22:50 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 May 2025 19:22:50 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Thu, 1 May 2025 17:51:53 GMT, Stuart Marks wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test > > src/java.base/share/classes/java/io/Reader.java line 408: > >> 406: *

This method works as if invoking it were equivalent to evaluating >> 407: * the expression: >> 408: *

{@linkplain #readAllChars()}.lines().toList()
> > I think this is actually too specific, as it could imply the returned List is the exact implementation that is returned by Stream.toList(). It is in this implementation, but I could easily imagine another implementation that constructs the list a different way. It might be better to be descriptive here and say that the entire input is read and is split into lines (where "line" is defined as above) which are returned in an unmodifiable list. And then have "unmodifiable list" be a link to the Unmodifiable Lists section, something like "java/util/List.html#unmodifiable". The word 'equivalent' mitigates the exactness of the code to describe the expected result. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070689232 From liach at openjdk.org Thu May 1 17:38:42 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 17:38:42 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v4] In-Reply-To: References: Message-ID: > Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Missed bug id ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23757/files - new: https://git.openjdk.org/jdk/pull/23757/files/eb405dd9..66066be7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23757&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23757&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23757.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23757/head:pull/23757 PR: https://git.openjdk.org/jdk/pull/23757 From duke at openjdk.org Thu May 1 23:40:49 2025 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 1 May 2025 23:40:49 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 17:40:56 GMT, Naoto Sato wrote: >> Hello @tats-u , there is no bother, I appreciate you looking at this. >> >> The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful. >> >> Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512. >> >> In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK. > > `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. > As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues. In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader. https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070927346 From duke at openjdk.org Fri May 2 00:00:59 2025 From: duke at openjdk.org (Tatsunori Uchino) Date: Fri, 2 May 2025 00:00:59 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 23:33:00 GMT, Tatsunori Uchino wrote: >> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. >> As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues. > > In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. > JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. > > One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader. > > https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418 I think we have only to change console encodings by e.g. `chcp 932` (CMD) or `[Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::Get Encoding(932)` (PowerShell) in Windows. They correspond to `GetConsoleCP` and `GetConsoleOutputCP`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070940588 From huizhe.wang at oracle.com Fri May 2 00:24:43 2025 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 1 May 2025 17:24:43 -0700 Subject: Namespace Prefix Issue in XML to XSL Transformation In-Reply-To: References: Message-ID: <054f569e-cf8a-4241-ac3d-ca248ac1d65b@oracle.com> Hi Hempushpa, You may want to talk to Christoph on JDK-8168664, he might have temped a fix at the time. Otherwise, feel free to create a new bug and PR, and we can start from there. Thanks, Joe On 4/23/25 7:03 AM, Hempushpa Sahu wrote: > > Problem Description : > > XSLT transformation creating unique namespace prefixes. > > Analysis & Observation : > > The XSLT transformation is generating a new namespace prefix for every > XML element, even when the namespace value matches that of the parent > element. This leads to large XML file transformations exceeding the > file size and memory limits on our systems. > > The behaviour in OpenJDK has remained consistent since JDK 8; however, > the namespace prefix issue is not something we find optimum. > > During our investigation of the OpenJDK codebase, we identified defect > https://bugs.openjdk.org/browse/JDK-8167179, which was intended to > resolve the namespace prefix issue in the OpenJDK 8 release. However, > our testing confirms that the issue persists across multiple versions, > including OpenJDK 8, 11, 17, and 22. Additionally, we found an open > bug report https://bugs.openjdk.org/browse/JDK-8168664 in the OpenJDK > issue tracker referencing a similar problem. Notably, there has been > no recent activity on this bug for several years > > Suggested Solution: > > Introduced a hashmap, and storing the unique namespace-url from root > node and checking if new url namespace-url encountered then we will > store it in the hashmap and increment the namespace prefix, else we > will not increment the prefix. > > Implemented in existing function startXslElement() of > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java > > ????????????? else { > > ??????? // Need to generate a prefix? > > ??????? if (namespace != null && namespace.length() > 0) { > > ??????????? prefix = generatePrefix(); > > ??????????? qname = prefix + ':' + qname; > > ??????????? handler.startElement(namespace, qname, qname); > > handler.namespaceAfterStartElement(prefix, namespace); > > ??????? } > > The above code is changed to > > ????????????? else { > > ??????? // Need to generate a prefix? > > ???????????????????????????? if (namespace != null && > namespace.length() > 0) { > > //Check if prefix needs to be incremented. > > if (!namespaceMap.containsKey(namespace)) > > { > > namespaceMap.put(namespace, > threadLocalPrefixIndex.get().getAndIncrement()); > > prefix = "ns"+namespaceMap.get(namespace); > > qname = prefix + ':' + qname; > > handler.startElement(namespace, qname, qname); > > ????????????? handler.namespaceAfterStartElement(prefix, namespace); > > } > > else > > { > > //Namespace URI already exist in map. > > prefix = "ns"+namespaceMap.get(namespace); > > qname = prefix + ':' + qname; > > handler.startElement(namespace, qname, qname); > > ????????????? handler.namespaceAfterStartElement(prefix, namespace); > > } > > ???????????????????????????? } > > Releases: > > OpenJDK 8, 11, 17 & 22 the issue is seen. > > Note: > > Proceeding with this approach, we will need to update the test files. > For instance, we have identified one test case that validates the > namespace prefix in the result - > test/jaxp/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java > > Next steps: > > We want to take the above-mentioned fix to OpenJDK. > > Please review and suggest if the above understanding is right and we > shall take the fix to OpenJDK. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Fri May 2 00:57:27 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 2 May 2025 00:57:27 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v9] In-Reply-To: References: Message-ID: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Make br field private; tweaks to javadoc. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24438/files - new: https://git.openjdk.org/jdk/pull/24438/files/5d0a867f..9c095792 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438 PR: https://git.openjdk.org/jdk/pull/24438 From liach at openjdk.org Fri May 2 00:57:27 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 00:57:27 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v9] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 00:54:24 GMT, Jan Lahoda wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) >> - `java. ... .IO` is no longer automatically imported in any compilation unit >> - the feature is finalized (i.e. no longer requires `--enable-preview`) > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Make br field private; tweaks to javadoc. Thanks for the update Stuart. Looks all good to me. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810991411 From smarks at openjdk.org Fri May 2 00:57:28 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 2 May 2025 00:57:28 GMT Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v8] In-Reply-To: References: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com> Message-ID: On Thu, 1 May 2025 18:43:57 GMT, Chen Liang wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating copyright year. > > src/java.base/share/classes/java/lang/IO.java line 157: > >> 155: *

>> 156: * Writes a prompt as if by calling {@code print}, and then reads a single >> 157: * line of text as if by calling {@link readln readln()}. > > Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`. I added `#` prefixes. I had intended `readln()` to indicate that this referred to the no-arg overload of `readln()` but I think that's too subtle so I removed the parens. But one has to look at the link to determine that it refers to the no-arg readln and not the one-arg readln (which is this method). I also changed the `print` to a link as well. > src/java.base/share/classes/java/lang/IO.java line 179: > >> 177: * the reader() method. >> 178: */ >> 179: static BufferedReader br; > > The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**. Added a comment. Making it `private` doesn't really help, but I made it private anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070971289 PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070970447 From jpai at openjdk.org Fri May 2 01:33:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 2 May 2025 01:33:59 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v4] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 17:38:42 GMT, Chen Liang wrote: >> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Missed bug id Thank you for the updates. Changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequestreview-2811019544 From liach at openjdk.org Fri May 2 01:33:59 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 01:33:59 GMT Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe [v4] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 17:38:42 GMT, Chen Liang wrote: >> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Missed bug id Thanks for the refreshed review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23757#issuecomment-2846110001 From liach at openjdk.org Fri May 2 01:33:59 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 01:33:59 GMT Subject: Integrated: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 23:47:02 GMT, Chen Liang wrote: > Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set. This pull request has now been integrated. Changeset: bd7c7789 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/bd7c77898a75dece0586bef24d4e18d540f08288 Stats: 34 lines in 2 files changed: 29 ins; 2 del; 3 mod 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe Reviewed-by: jpai, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/23757 From jiangli at openjdk.org Fri May 2 02:15:32 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 2 May 2025 02:15:32 GMT Subject: RFR: 8356050: Problemlist jdk & langtools tier1 tests requiring runtime usages of /bin/tools for static-jdk Message-ID: Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of /bin/tools, for testing on static-jdk. The affected tests using following tools at runtime: - javac - javadoc - jar - jarsigner - jimage - jps ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8356050 - Problem jdk & langtools tier1 tests requiring runtime usages of /bin/tools for static-jdk. Changes: https://git.openjdk.org/jdk/pull/24995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24995&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356050 Stats: 43 lines in 2 files changed: 43 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24995/head:pull/24995 PR: https://git.openjdk.org/jdk/pull/24995 From swen at openjdk.org Fri May 2 03:04:02 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 03:04:02 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v12] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 19:27:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix @Param due to the rename from default to class+method The value of flags can only be 0 or 0x08000000, so flags & MEMBER_INFO_FLAGS in isHidden and isCallerSensitive methods are always false ClassFrameInfo(StackWalker walker) { this.flags = walker.retainClassRef ? RETAIN_CLASS_REF_BIT : 0; } private static final int MEMBER_INFO_FLAGS = 0x00FFFFFF; private static final int RETAIN_CLASS_REF_BIT = 0x08000000; // retainClassRef The flags field is only assigned in the ClassFrameInfo constructor, so flags can be set to final, and the value here will only be 0 or RETAIN_CLASS_REF_BIT (0x08000000). So `flags & MEMBER_INFO_FLAGS` in the following code is always false boolean isCallerSensitive() { return JLIA.isCallerSensitive(flags & MEMBER_INFO_FLAGS); } boolean isHidden() { return JLIA.isHiddenMember(flags & MEMBER_INFO_FLAGS); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-2846210254 From swen at openjdk.org Fri May 2 03:36:06 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 03:36:06 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v12] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 19:27:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix @Param due to the rename from default to class+method Sorry, I misread it. There is a comment in flags: `updated by VM to set hidden and caller-sensitive bits` ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-2846236653 From swen at openjdk.org Fri May 2 03:49:39 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 03:49:39 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: > In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string. > > For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 # Conflicts: # src/java.base/share/classes/java/lang/AbstractStringBuilder.java - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 # Conflicts: # src/java.base/share/classes/java/lang/StringUTF16.java - putCharsUnchecked - copyright - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[]) - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[]) - add append(char[]) benchmark ------------- Changes: https://git.openjdk.org/jdk/pull/24773/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=03 Stats: 46 lines in 3 files changed: 40 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24773.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24773/head:pull/24773 PR: https://git.openjdk.org/jdk/pull/24773 From swen at openjdk.org Fri May 2 03:53:23 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 03:53:23 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v21] In-Reply-To: References: Message-ID: <1aM0ee4KZZMdJ-P_D4fyHctD5SI-0MSYmqnQ61Bv3p0=.909cc730-2bb7-4a1c-b4f8-4f18734d7b63@github.com> > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 # Conflicts: # src/java.base/share/classes/java/lang/Integer.java # src/java.base/share/classes/java/lang/Long.java - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 - remove ForceInline - fix comments - fix comments - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Raffaello Giulietti - copyright - fix JdbExprTest - Update src/java.base/share/classes/java/lang/Long.java Co-authored-by: Raffaello Giulietti - Update src/java.base/share/classes/java/lang/Integer.java Co-authored-by: Raffaello Giulietti - ... and 29 more: https://git.openjdk.org/jdk/compare/bd7c7789...047e1709 ------------- Changes: https://git.openjdk.org/jdk/pull/22919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=20 Stats: 179 lines in 6 files changed: 101 ins; 26 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From swen at openjdk.org Fri May 2 03:55:24 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 03:55:24 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v3] In-Reply-To: References: Message-ID: > The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance. 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 'upstream/master' into allocate_un_init_202501 # Conflicts: # src/java.base/share/classes/java/lang/Integer.java # src/java.base/share/classes/java/lang/Long.java - use StringConcatHelper.newArray - simplify - use Unsafe.allocateUninitializedArray - revert StringConcatHelper newArray change - copyright - remove duplicate check - allocateUninitializedArray ------------- Changes: https://git.openjdk.org/jdk/pull/23353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=02 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23353/head:pull/23353 PR: https://git.openjdk.org/jdk/pull/23353 From swen at openjdk.org Fri May 2 04:59:45 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 04:59:45 GMT Subject: RFR: 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor In-Reply-To: References: Message-ID: On Thu, 1 May 2025 00:01:08 GMT, Chen Liang wrote: > As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types. > > In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported. > > These behaviors are already covered by the tests added in JDK-8350704 #23788. > > Testing: reflect/annotation/Class, running tier 1+2 src/java.base/share/classes/java/lang/Class.java line 1565: > 1563: Class[] parameterClasses = types.toArray(EMPTY_CLASS_ARRAY); > 1564: > 1565: final Class enclosingCandidate = enclosingInfo.getEnclosingClass(); Suggestion: Constructor[] candidates = enclosingInfo.getEnclosingClass() .privateGetDeclaredConstructors(false); Here the local variable `enclosingInfo` is only used once, the above code may be simpler ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071095785 From duke at openjdk.org Fri May 2 05:08:52 2025 From: duke at openjdk.org (duke) Date: Fri, 2 May 2025 05:08:52 GMT Subject: Withdrawn: 8351344: Avoid explicit Objects.requireNonNull in String.join In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov wrote: > We have helpful NPE messages now - they are more user-friendly. > And shorter methods are more likely to be inlined. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23710 From liach at openjdk.org Fri May 2 05:14:49 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 05:14:49 GMT Subject: RFR: 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor In-Reply-To: References: Message-ID: On Fri, 2 May 2025 04:56:51 GMT, Shaojin Wen wrote: >> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types. >> >> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported. >> >> These behaviors are already covered by the tests added in JDK-8350704 #23788. >> >> Testing: reflect/annotation/Class, running tier 1+2 > > src/java.base/share/classes/java/lang/Class.java line 1565: > >> 1563: Class[] parameterClasses = types.toArray(EMPTY_CLASS_ARRAY); >> 1564: >> 1565: final Class enclosingCandidate = enclosingInfo.getEnclosingClass(); > > Suggestion: > > Constructor[] candidates = enclosingInfo.getEnclosingClass() > .privateGetDeclaredConstructors(false); > > Here the local variable `enclosingInfo` is only used once, the above code may be simpler This patch intentionally did not change this part - and this part can get much more in-depth optimization; for example, arrayContentsEq can be shared for all `Class` arrays, copy of reflective objects can be simplified, etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071104255 From swen at openjdk.org Fri May 2 05:19:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 05:19:52 GMT Subject: RFR: 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor In-Reply-To: References: Message-ID: <734JhRuV4oIyVO7f9czHorMNCKqoucxHTA5wVdAxtS8=.480541f0-854b-43ab-96c0-378054af4350@github.com> On Thu, 1 May 2025 00:01:08 GMT, Chen Liang wrote: > As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types. > > In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported. > > These behaviors are already covered by the tests added in JDK-8350704 #23788. > > Testing: reflect/annotation/Class, running tier 1+2 src/java.base/share/classes/java/lang/Class.java line 1563: > 1561: List> types = BytecodeDescriptor.parseMethod(enclosingInfo.getDescriptor(), getClassLoader()); > 1562: types.removeLast(); > 1563: Class[] parameterClasses = types.toArray(EMPTY_CLASS_ARRAY); Suggestion: var parameterClasses = types.toArray(EMPTY_CLASS_ARRAY); Here the type of parameterClasses is very clear, or you can use var ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071107230 From swen at openjdk.org Fri May 2 05:23:45 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 05:23:45 GMT Subject: RFR: 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor In-Reply-To: References: Message-ID: On Thu, 1 May 2025 00:01:08 GMT, Chen Liang wrote: > As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types. > > In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported. > > These behaviors are already covered by the tests added in JDK-8350704 #23788. > > Testing: reflect/annotation/Class, running tier 1+2 src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 48: > 46: int[] i = {0}; > 47: var ret = parseSig(descriptor, i, descriptor.length(), loader); > 48: if (i[0] != descriptor.length() || ret == null) { var ret = parseSig(descriptor, new int[] {0}, descriptor.length(), loader); if (descriptor.length() != 0 || ret == null) { Can it be rewritten like this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071109091 From liach at openjdk.org Fri May 2 05:23:45 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 05:23:45 GMT Subject: RFR: 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor In-Reply-To: References: Message-ID: On Fri, 2 May 2025 05:19:57 GMT, Shaojin Wen wrote: >> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types. >> >> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported. >> >> These behaviors are already covered by the tests added in JDK-8350704 #23788. >> >> Testing: reflect/annotation/Class, running tier 1+2 > > src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 48: > >> 46: int[] i = {0}; >> 47: var ret = parseSig(descriptor, i, descriptor.length(), loader); >> 48: if (i[0] != descriptor.length() || ret == null) { > > var ret = parseSig(descriptor, new int[] {0}, descriptor.length(), loader); > if (descriptor.length() != 0 || ret == null) { > > Can it be rewritten like this? i[0] is modified by parseSig ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071109980 From swen at openjdk.org Fri May 2 06:01:57 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 06:01:57 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 21:08:29 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added missing bugid to tests > Applied review suggestions. > Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores. > Updated missing copyright years. The test code in java/lang/Helper.java needs to be changed to fix the build error // test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java package java.lang; class Helper { public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) { int end = i + 4; StringUTF16.checkBoundsBeginEnd(i, end, value); StringUTF16.putCharsAt(value, i, c1, c2, c3, c4); return end; } public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) { int end = i + 5; StringUTF16.checkBoundsBeginEnd(i, end, value); StringUTF16.putCharsAt(value, i, c1, c2, c3, c4, c5); return end; } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2846432424 From swen at openjdk.org Fri May 2 06:07:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 06:07:47 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 21:08:29 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added missing bugid to tests > Applied review suggestions. > Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores. > Updated missing copyright years. src/java.base/share/classes/java/lang/StringUTF16.java line 1538: > 1536: putChar(value, i++, c3); > 1537: putChar(value, i++, c4); > 1538: assert(i == end); Suggestion: checkBoundsBeginEnd(i, end, value); putChar(value, i , c1); putChar(value, i + 1, c2); putChar(value, i + 2, c3); putChar(value, i + 3, c4); StringUTF16 can also use `+1 +2 +3` to replace `++` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2071140535 From jlahoda at openjdk.org Fri May 2 06:13:57 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 2 May 2025 06:13:57 GMT Subject: Integrated: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: <7qJ1POdMGcRYtfcq6u1v6pcCu3MCfOFXoAZIyOf9IVA=.aeb8b7db-e8bf-4db9-9dcc-fd7f55549c39@github.com> On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda wrote: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) This pull request has now been integrated. Changeset: d29700cc Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/d29700cc80003d6baddb419f2974ab226478bacc Stats: 1061 lines in 59 files changed: 336 ins; 585 del; 140 mod 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods Co-authored-by: Stuart Marks Reviewed-by: liach, cstein, vromero, naoto ------------- PR: https://git.openjdk.org/jdk/pull/24438 From duke at openjdk.org Fri May 2 06:18:46 2025 From: duke at openjdk.org (Markus KARG) Date: Fri, 2 May 2025 06:18:46 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory In-Reply-To: <2zlSFcT1XiOm_I2AsEmRYsi3hPVec_7BEIhxFI5wyro=.5f31ddfe-29b4-4794-906f-8865d7e57121@github.com> References: <2zlSFcT1XiOm_I2AsEmRYsi3hPVec_7BEIhxFI5wyro=.5f31ddfe-29b4-4794-906f-8865d7e57121@github.com> Message-ID: <7X7GuAy6-NuAZ1aAqm2M7B6HGm-j7WZ_kmTCbdJRxdk=.5978203c-2997-4bfa-8f2e-fb7d4e3c3d07@github.com> On Mon, 21 Apr 2025 15:19:40 GMT, Chen Liang wrote: > This might be helpful combined with #21730. That implies creating a copy of the chars: private final void appendChars(CharSequence s, int off, int end) { if (isLatin1()) { byte[] val = this.value; // ----- Begin of Experimental Section ----- char[] ca = new char[end - off]; s.getChars(off, end, ca, 0); int compressed = StringUTF16.compress(ca, 0, val, count, end - off); count += compressed; off += compressed; // ----- End of Experimental Section ----- for (int i = off, j = count; i < end; i++) { char c = s.charAt(i); if (StringLatin1.canEncode(c)) { val[j++] = (byte)c; } else { count = j; inflate(); // Store c to make sure sb has a UTF16 char StringUTF16.putCharSB(this.value, j++, c); count = j; i++; StringUTF16.putCharsSB(this.value, j, s, i, end); count += end - i; return; } } } else { StringUTF16.putCharsSB(this.value, count, s, off, end); } count += end - off; } While I do *assume* that it should faster to let machine code perform the copy and compression over letting Java code perform a char-by-char approach, to be sure there should be another benchmark to actually proof this claim. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846452819 From swen at openjdk.org Fri May 2 06:18:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 06:18:47 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 21:08:29 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added missing bugid to tests > Applied review suggestions. > Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores. > Updated missing copyright years. src/java.base/share/classes/java/lang/StringUTF16.java line 1549: > 1547: putChar(value, i++, c4); > 1548: putChar(value, i++, c5); > 1549: assert(i == end); We can also use `+1 +2 +3 +4` to replace `++` checkBoundsBeginEnd(i, end, value); putChar(value, i , c1); putChar(value, i + 1, c2); putChar(value, i + 2, c3); putChar(value, i + 3, c4); putChar(value, i + 4, c5); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2071148628 From epeter at openjdk.org Fri May 2 06:31:51 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 2 May 2025 06:31:51 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 06:14:19 GMT, Emanuel Peter wrote: >> erifan 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: >> >> - Update the jtreg test >> - Merge branch 'master' into JDK-8354242 >> - Addressed some review comments >> >> 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. >> 2. Improve code comments. >> - Merge branch 'master' into JDK-8354242 >> - Merge branch 'master' into JDK-8354242 >> - 8354242: VectorAPI: combine vector not operation with compare >> >> This patch optimizes the following patterns: >> For integer types: >> ``` >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> ``` >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the >> negative comparison of cond. >> >> For float and double types: >> ``` >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> ``` >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: >> With option `-XX:UseSVE=2`: >> ``` >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 1... > > src/hotspot/share/opto/vectornode.cpp line 2216: > >> 2214: in2->is_predicated_vector()) { >> 2215: with_predicated = true; >> 2216: } > > Suggestion: > > bool with_predicated = is_predicated_vector() || > in1->is_predicated_vector() || > in2->is_predicated_vector(); Would that not be easier to read? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2071147181 From swen at openjdk.org Fri May 2 06:43:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 06:43:47 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 03:49:39 GMT, Shaojin Wen wrote: >> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string. >> >> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 > > # Conflicts: > # src/java.base/share/classes/java/lang/AbstractStringBuilder.java > - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 > > # Conflicts: > # src/java.base/share/classes/java/lang/StringUTF16.java > - putCharsUnchecked > - copyright > - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[]) > - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[]) > - add append(char[]) benchmark > > This might be helpful combined with #21730. > > That implies creating a copy of the chars: > > ```java > private final void appendChars(CharSequence s, int off, int end) { > if (isLatin1()) { > byte[] val = this.value; > > // ----- Begin of Experimental Section ----- > char[] ca = new char[end - off]; > s.getChars(off, end, ca, 0); > int compressed = StringUTF16.compress(ca, 0, val, count, end - off); > count += compressed; > off += compressed; > // ----- End of Experimental Section ----- > > for (int i = off, j = count; i < end; i++) { > char c = s.charAt(i); > if (StringLatin1.canEncode(c)) { > val[j++] = (byte)c; > } else { > count = j; > inflate(); > // Store c to make sure sb has a UTF16 char > StringUTF16.putCharSB(this.value, j++, c); > count = j; > i++; > StringUTF16.putCharsSB(this.value, j, s, i, end); > count += end - i; > return; > } > } > } else { > StringUTF16.putCharsSB(this.value, count, s, off, end); > } > count += end - off; > } > ``` > > While I do _assume_ that it should faster to let machine code perform the copy and compression over letting Java code perform a char-by-char approach, to be sure there should be another benchmark to actually proof this claim. > char[] ca = new char[end - off]; Your code here has a memory allocation, which may cause slowdown ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846483320 From duke at openjdk.org Fri May 2 06:43:48 2025 From: duke at openjdk.org (Markus KARG) Date: Fri, 2 May 2025 06:43:48 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 03:49:39 GMT, Shaojin Wen wrote: >> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string. >> >> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 > > # Conflicts: > # src/java.base/share/classes/java/lang/AbstractStringBuilder.java > - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 > > # Conflicts: > # src/java.base/share/classes/java/lang/StringUTF16.java > - putCharsUnchecked > - copyright > - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[]) > - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[]) > - add append(char[]) benchmark > ```java > > char[] ca = new char[end - off]; > ``` > > Your code here has a memory allocation, which may cause slowdown This is exactly what I wanted to express with my posting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846485487 From swen at openjdk.org Fri May 2 07:15:45 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 07:15:45 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 06:41:14 GMT, Markus KARG wrote: > > ```java > > > char[] ca = new char[end - off]; > > ``` > > > > > > > > > > > > > > > > > > > > > > > > Your code here has a memory allocation, which may cause slowdown > > This is exactly what I wanted to express with my posting. I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846530206 From mdoerr at openjdk.org Fri May 2 08:01:52 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 2 May 2025 08:01:52 GMT Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float divisions by zero on AIX In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken wrote: > Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero. > At least this is the case on AIX. > > (seen in the jtreg test java/lang/Math/PowTests.java ) src/hotspot/share/sanitizers/ub.hpp line 39: > 37: #define ATTRIBUTE_NO_UBSAN __attribute__((no_sanitize("undefined","float-divide-by-zero"))) > 38: #endif > 39: #if defined(__GNUC__) && !defined(__clang__) Maybe use `#elif`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24963#discussion_r2071246318 From pminborg at openjdk.org Fri May 2 08:04:48 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 08:04:48 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: <7Cz0Yoz7CNQXNgnCNlUTI96sTtV87FsVc7sRgPAP6gU=.0b79f998-26e2-4567-af60-8bcd75391105@github.com> References: <7Cz0Yoz7CNQXNgnCNlUTI96sTtV87FsVc7sRgPAP6gU=.0b79f998-26e2-4567-af60-8bcd75391105@github.com> Message-ID: On Thu, 1 May 2025 09:09:16 GMT, Maurizio Cimadamore wrote: >> Ugh - it's a record, I see. Which brings up the question -- should it be a record? Should it advertize its `size and `tl` components (they seem rather implementation specific?). > > Was this done so that the final field could be trusted? (I believe all final fields are implicitly trusted in jdk/internal/foreign): > > > holder->is_in_package("jdk/internal/foreign/layout") || holder->is_in_package("jdk/internal/foreign") || Yes. We should revert to a normal class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071249389 From pminborg at openjdk.org Fri May 2 08:04:50 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 08:04:50 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: <8zAGokzs5CTDvvlNRh8YRaMDChm9Qi4RCWI2SBihE3w=.ade66b03-422a-4cd2-9d1d-085d8a3cae0b@github.com> References: <8zAGokzs5CTDvvlNRh8YRaMDChm9Qi4RCWI2SBihE3w=.ade66b03-422a-4cd2-9d1d-085d8a3cae0b@github.com> Message-ID: <9wYUZVaWE0sWHHMNJ7hK2uKyTSFaAuCddS32S4PINTE=.9ae90209-ec8b-4d5f-a302-6c3c9566bcb6@github.com> On Wed, 30 Apr 2025 17:59:31 GMT, Jorn Vernee wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve on comments > > test/jdk/java/foreign/TestBufferStackStress2.java line 98: > >> 96: System.gc(); >> 97: } >> 98: segment.get(ValueLayout.JAVA_BYTE, i); > > Won't this read out of bounds? `SMALL_ALLOC_SIZE` is only 8. Good catch! I will fix that and also add a check that the VT is completed as expected to avoid such issues in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071248812 From mbaesken at openjdk.org Fri May 2 08:13:44 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 2 May 2025 08:13:44 GMT Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float divisions by zero on AIX In-Reply-To: References: Message-ID: On Fri, 2 May 2025 07:59:12 GMT, Martin Doerr wrote: >> Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero. >> At least this is the case on AIX. >> >> (seen in the jtreg test java/lang/Math/PowTests.java ) > > src/hotspot/share/sanitizers/ub.hpp line 39: > >> 37: #define ATTRIBUTE_NO_UBSAN __attribute__((no_sanitize("undefined","float-divide-by-zero"))) >> 38: #endif >> 39: #if defined(__GNUC__) && !defined(__clang__) > > Maybe use `#elif`? Or should I try to set it for BOTH clang and gcc so that the added checks are not needed any more? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24963#discussion_r2071258909 From swen at openjdk.org Fri May 2 08:14:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 08:14:50 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v6] In-Reply-To: References: Message-ID: <0L6OqV-kWUKj74gabM-sbchxjWPPVuOv7ZsnXDX5D4k=.576321e2-146e-440a-b28e-38a37f491c8c@github.com> On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Improve on comments src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 108: > 106: final Arena arena = Arena.ofAuto(); > 107: final SlicingAllocator stack = new SlicingAllocator(arena.allocate(size)); > 108: return new PerThread(new ReentrantLock(), stack, arena); Suggestion: final Arena arena = Arena.ofAuto(); return new PerThread(new ReentrantLock(), new SlicingAllocator(arena.allocate(size)), arena); } The local variable stack is only used once, is it okay not to use it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071260412 From duke at openjdk.org Fri May 2 09:01:57 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 09:01:57 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Simplify long power computing > Is there a reason this cannot simply be the traditional "repeated square" method? Why this complexity? @rgiulietti By the way, could make sense recycling this algorithm scheme to speed up the computing of powers of `int`s that don't fit into a `long`, using `unsignedLongPow(long, int)` instead of `Math.pow()`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2846711109 From mli at openjdk.org Fri May 2 09:11:47 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 2 May 2025 09:11:47 GMT Subject: RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786 In-Reply-To: References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> Message-ID: On Thu, 1 May 2025 18:27:24 GMT, Vladimir Ivanov wrote: > I want to understand the issue with missing entries in vector math native libraries first before making a decision how to proceed. > > > I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different. > > Sorry, I don't get it. How does it affect the contents of the native library? JDK vendors do have an option to bundle the library or drop it from their distribution. But when SLEEF-based and SVML math libraries are built by JDK there's no distinction between entries being included in the library. If a vendor modifies make files or native library code, it's up to them to adjust JDK accordingly. Upstream JDK doesn't have to take such scenarios into account. Sorry for confusing you. No, what I mean is vendors can choose their build environment (e.g. with/without support of compiler, I discuss this a bit below), and different environment will lead to whether sleef is supported or not (i.e. whether there are entries in the libsleef.so). > > I looked through SVML and SLEEF-based vector math code and noticed there are some capability check [1] [2] [3] guarding library code. It means that if some library entry is missing, then the whole library is empty. Can you confirm it's the case you see? > > [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc#L35 [2] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc#L28 [3] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/unix/native/libsleef/lib/vector_math_rvv.c#L36 In riscv sleef case, yes, it checks native compiler version and a flat, this is required because only these versions (or higher) support vector intrinsics which are used in sleef header files. ( I think arm is the same case, but in a bit simpler way only with a flag). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2846731509 From swen at openjdk.org Fri May 2 09:19:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 09:19:50 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v5] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 10:55:16 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti 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 8343829 > - Redacted comments. > - Merge branch 'master' into 8343829 > - Minors in comments. > - Removed repeated comment. > - Refactoring some code and comments. > - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal static final int BIG_DECIMAL_EXPONENT = 324; The BIG_DECIMAL_EXPONENT in line 50 is no longer used and can be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2846746380 From duke at openjdk.org Fri May 2 10:00:07 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 2 May 2025 10:00:07 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Refactor container runtime version code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/223a5d1b..3b18431d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=01-02 Stats: 246 lines in 3 files changed: 111 ins; 133 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From duke at openjdk.org Fri May 2 10:00:07 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 2 May 2025 10:00:07 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: <_D4nqTI9xJUe43WrWHRaozFfHG5HQSv-jzFSNnrggmo=.fc3318d8-a776-48a3-b564-2d8e376bc299@github.com> On Tue, 29 Apr 2025 20:18:17 GMT, Sergey Chernyshev wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor container runtime version code > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 74: > >> 72: return; >> 73: } >> 74: if (IS_DOCKER && TestDockerMemoryMetricsSubgroup.DockerVersion.VERSION_20_10_0.compareTo(getDockerVersion()) > 0) { > > Should this change also cover Podman, in which the minimum version that supports `--cgroupns` is 3.0 ? updated for podman In podman cgroupns support was added in 1.5.0 https://github.com/containers/podman/releases?page=18 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071383984 From duke at openjdk.org Fri May 2 10:00:08 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 2 May 2025 10:00:08 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v2] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 20:28:36 GMT, Sergey Chernyshev wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> update reference of DockerVersion > > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 149: > >> 147: } >> 148: >> 149: private static class DockerVersion implements Comparable { > > The same code is added to multiple tests. Created a util file for common code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071384406 From pminborg at openjdk.org Fri May 2 10:40:04 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 10:40:04 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v7] In-Reply-To: References: Message-ID: > This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. > > Re-allocated segments are not zeroed between allocations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24829/files - new: https://git.openjdk.org/jdk/pull/24829/files/22c384f9..dcce2e94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=05-06 Stats: 165 lines in 6 files changed: 71 ins; 43 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/24829.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829 PR: https://git.openjdk.org/jdk/pull/24829 From pminborg at openjdk.org Fri May 2 10:43:46 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 10:43:46 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:40:04 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments Updated benchmarks: Benchmark (ELEM_SIZE) Mode Cnt Score Error Units BufferStackBench.OfVirtual.buffer 8 avgt 15 12.695 ? 0.205 ns/op BufferStackBench.OfVirtual.buffer 16 avgt 15 12.622 ? 0.078 ns/op BufferStackBench.OfVirtual.buffer 32 avgt 15 12.523 ? 0.022 ns/op BufferStackBench.OfVirtual.confined 8 avgt 15 22.902 ? 0.407 ns/op BufferStackBench.OfVirtual.confined 16 avgt 15 23.858 ? 0.652 ns/op BufferStackBench.OfVirtual.confined 32 avgt 15 25.544 ? 0.458 ns/op BufferStackBench.buffer 8 avgt 15 4.923 ? 0.029 ns/op BufferStackBench.buffer 16 avgt 15 4.971 ? 0.095 ns/op BufferStackBench.buffer 32 avgt 15 4.980 ? 0.105 ns/op BufferStackBench.confined 8 avgt 15 22.713 ? 0.289 ns/op BufferStackBench.confined 16 avgt 15 23.576 ? 0.348 ns/op BufferStackBench.confined 32 avgt 15 25.272 ? 0.530 ns/op and vBenchmark Mode Cnt Score Error Units CallOverheadByValue.OfVirtual.byPtr avgt 15 4.159 ? 0.097 ns/op CallOverheadByValue.OfVirtual.byValue avgt 15 16.535 ? 0.433 ns/op CallOverheadByValue.byPtr avgt 15 4.119 ? 0.031 ns/op CallOverheadByValue.byValue avgt 15 11.404 ? 0.240 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2846906803 From mli at openjdk.org Fri May 2 10:48:50 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 2 May 2025 10:48:50 GMT Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v4] In-Reply-To: References: Message-ID: <-bAHBy4AmqSglDpT2t94FrSQ7n1oFPkBDuxfcd2C0A8=.802dff01-b8da-439e-8b80-aa5dddc4031c@github.com> On Wed, 30 Apr 2025 12:00:45 GMT, Robbin Ehn wrote: >> Hi, for you to consider. >> >> These tests constantly fails in qemu-user. >> Either the require host to be same arch explicit or implicit (sysroot). >> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests. >> >> From bug: >>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that). >>> We add this uarch to CPU feature string. >>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user. >> >> Relevant qemu code: >> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29 >> >> Relevant hotspot code: >> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250 >> >> Tested that the require only filters out tests in qemu+riscv64. >> >> Thanks! >> >> /Robbin > > Robbin Ehn 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 qemu-user-issues > - Merge branch 'master' into qemu-user-issues > - Revert > - Merge branch 'master' into qemu-user-issues > - Merge branch 'master' into qemu-user-issues > - more > - more > - native or very long Looks good, thanks for fixing this and discussing! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24229#pullrequestreview-2811707177 From pminborg at openjdk.org Fri May 2 11:13:27 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 11:13:27 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: References: Message-ID: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> > This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. > > Re-allocated segments are not zeroed between allocations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Cleanup and only create CleanupAction once per thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24829/files - new: https://git.openjdk.org/jdk/pull/24829/files/dcce2e94..c819553c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=06-07 Stats: 33 lines in 2 files changed: 15 ins; 8 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24829.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829 PR: https://git.openjdk.org/jdk/pull/24829 From swen at openjdk.org Fri May 2 11:24:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 11:24:50 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:40:04 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 186: > 184: } > 185: } > 186: } Suggestion: private record PerThread(ReentrantLock lock, Arena arena, SlicingAllocator stack) { @ForceInline @SuppressWarnings("restricted") public Arena pushFrame(long size, long byteAlignment) { boolean needsLock = Thread.currentThread().isVirtual() && !lock.isHeldByCurrentThread(); if (needsLock && !lock.tryLock()) { // Rare: another virtual thread on the same carrier competed for acquisition. return Arena.ofConfined(); } if (!stack.canAllocate(size, byteAlignment)) { if (needsLock) lock.unlock(); return Arena.ofConfined(); } Arena confinedArena = Arena.ofConfined(); long parentOffset = stack.currentOffset(); MemorySegment frameSegment = stack.allocate(size, byteAlignment); long topOfStack = stack.currentOffset(); // The cleanup action will keep the original automatic `arena` (from which // the reusable segment is first allocated) alive even if this Frame // becomes unreachable but there are reachable segments still alive. SegmentAllocator frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, new Frame.CleanupAction(arena))); return new Frame(this, needsLock, parentOffset, topOfStack, confinedArena, frame); } static PerThread of(long byteSize, long byteAlignment) { final Arena arena = Arena.ofAuto(); return new PerThread(new ReentrantLock(), arena, new SlicingAllocator(arena.allocate(byteSize, byteAlignment))); } } private record Frame(PerThread thread, boolean locked, long parentOffset, long topOfStack, Arena confinedArena, SegmentAllocator frame) implements Arena { record CleanupAction(Arena arena) implements Consumer { @Override public void accept(MemorySegment memorySegment) { Reference.reachabilityFence(arena); } } @ForceInline private void assertOrder() { if (topOfStack != thread.stack.currentOffset()) throw new IllegalStateException("Out of order access: frame not top-of-stack"); } @ForceInline @Override @SuppressWarnings("restricted") public MemorySegment allocate(long byteSize, long byteAlignment) { // Make sure we are on the right thread and not closed MemorySessionImpl.toMemorySession(confinedArena).checkValidState(); return frame.allocate(byteSize, byteAlignment); } @ForceInline @Override public MemorySegment.Scope scope() { return confinedArena.scope(); } @ForceInline @Override public void close() { assertOrder(); // the Arena::close method is called "early" as it checks thread // confinement and crucially before any mutation of the internal // state takes place. confinedArena.close(); thread.stack.resetTo(parentOffset); if (locked) { thread.lock.unlock(); } } } I find it a bit strange to nest a class inside a record. What do you think if I change it to two records? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071471740 From swen at openjdk.org Fri May 2 11:33:48 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 11:33:48 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> Message-ID: On Fri, 2 May 2025 11:13:27 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup and only create CleanupAction once per thread src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 194: > 192: } > 193: } > 194: } Suggestion: private record PerThread(ReentrantLock lock, Arena arena, SlicingAllocator stack, CleanupAction cleanupAction) { @SuppressWarnings("restricted") @ForceInline public Arena pushFrame(long size, long byteAlignment) { boolean needsLock = Thread.currentThread().isVirtual() && !lock.isHeldByCurrentThread(); if (needsLock && !lock.tryLock()) { // Rare: another virtual thread on the same carrier competed for acquisition. return Arena.ofConfined(); } if (!stack.canAllocate(size, byteAlignment)) { if (needsLock) lock.unlock(); return Arena.ofConfined(); } long parentOffset = stack.currentOffset(); final MemorySegment frameSegment = stack.allocate(size, byteAlignment); long topOfStack = stack.currentOffset(); Arena confinedArena = Arena.ofConfined(); // return new Frame(needsLock, size, byte // The cleanup action will keep the original automatic `arena` (from which // the reusable segment is first allocated) alive even if this Frame // becomes unreachable but there are reachable segments still alive. return new Frame(this, needsLock, parentOffset, topOfStack, confinedArena, new SlicingAllocator(frameSegment.reinterpret(confinedArena, cleanupAction))); } static PerThread of(long byteSize, long byteAlignment) { final Arena arena = Arena.ofAuto(); return new PerThread(new ReentrantLock(), arena, new SlicingAllocator(arena.allocate(byteSize, byteAlignment)), new CleanupAction(arena)); } private record CleanupAction(Arena arena) implements Consumer { @Override public void accept(MemorySegment memorySegment) { Reference.reachabilityFence(arena); } } } private record Frame(PerThread thead, boolean locked, long parentOffset, long topOfStack, Arena confinedArena, SegmentAllocator frame) implements Arena { @ForceInline private void assertOrder() { if (topOfStack != thead.stack.currentOffset()) throw new IllegalStateException("Out of order access: frame not top-of-stack"); } @ForceInline @Override @SuppressWarnings("restricted") public MemorySegment allocate(long byteSize, long byteAlignment) { // Make sure we are on the right thread and not closed MemorySessionImpl.toMemorySession(confinedArena).checkValidState(); return frame.allocate(byteSize, byteAlignment); } @ForceInline @Override public MemorySegment.Scope scope() { return confinedArena.scope(); } @ForceInline @Override public void close() { assertOrder(); // the Arena::close method is called "early" as it checks thread // confinement and crucially before any mutation of the internal // state takes place. confinedArena.close(); thead.stack.resetTo(parentOffset); if (locked) { thead.lock.unlock(); } } } Same as the suggestion above, you changed the code. I updated and remade the suggestion and changed it to two records. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071481137 From mcimadamore at openjdk.org Fri May 2 11:39:53 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 May 2025 11:39:53 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> Message-ID: <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> On Fri, 2 May 2025 11:13:27 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup and only create CleanupAction once per thread src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 127: > 125: arena, > 126: new SlicingAllocator(arena.allocate(byteSize, byteAlignment)), > 127: new CleanupAction(arena)); any reason why you didn't use a lambda here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071487667 From aph-open at littlepinkcloud.com Fri May 2 11:43:37 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 2 May 2025 12:43:37 +0100 Subject: RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786 In-Reply-To: References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> Message-ID: On 5/2/25 10:11, Hamlin Li wrote: > what I mean is vendors can choose their build environment (e.g. with/without support of compiler, I discuss this a bit below), and different environment will lead to whether sleef is supported or not (i.e. whether there are entries in the libsleef.so). Again, this is an unhelpful thing to do. If the environment doesn't support building the full JDK, kick it out. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at openjdk.org Fri May 2 11:43:47 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 2 May 2025 11:43:47 GMT Subject: RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786 In-Reply-To: References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com> <1hfhvGjxKFAYEtj1D_pIdgU659AE2oPWoQEyXl8sRgQ=.3aa62617-142a-49c9-82c4-0f761cb73aff@github.com> Message-ID: <_Zjv0l0jFcm3LyXV8aU8IdBDIiXTGatgRfV5BEv6_Fc=.1b5646f8-f905-45e8-9d7f-aec437edfb84@github.com> On Thu, 1 May 2025 08:50:27 GMT, Hamlin Li wrote: > > Overall, it still looks like a JDK build issue to me. Hiding problems occurred during the build is not good. If some toolchains can't successfully build the library, the library shouldn't be included in JDK. > > No, in riscv case (possiblely also on arm?) I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different. I am not convinced that supporting such a divergence between builds of the JDK is something we should support. Sure, we can choose at runtime whether to link with SLEEF or not, but having some builds of (say) risc OpenJDK with SLEEF and some without is a Bad Thing. It is a build issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2847012173 From mcimadamore at openjdk.org Fri May 2 11:44:48 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 May 2025 11:44:48 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:41:38 GMT, Per Minborg wrote: > Updated benchmarks: > > ``` > Benchmark (ELEM_SIZE) Mode Cnt Score Error Units > BufferStackBench.OfVirtual.buffer 8 avgt 15 12.695 ? 0.205 ns/op > BufferStackBench.OfVirtual.buffer 16 avgt 15 12.622 ? 0.078 ns/op > BufferStackBench.OfVirtual.buffer 32 avgt 15 12.523 ? 0.022 ns/op > BufferStackBench.OfVirtual.confined 8 avgt 15 22.902 ? 0.407 ns/op > BufferStackBench.OfVirtual.confined 16 avgt 15 23.858 ? 0.652 ns/op > BufferStackBench.OfVirtual.confined 32 avgt 15 25.544 ? 0.458 ns/op > BufferStackBench.buffer 8 avgt 15 4.923 ? 0.029 ns/op > BufferStackBench.buffer 16 avgt 15 4.971 ? 0.095 ns/op > BufferStackBench.buffer 32 avgt 15 4.980 ? 0.105 ns/op > BufferStackBench.confined 8 avgt 15 22.713 ? 0.289 ns/op > BufferStackBench.confined 16 avgt 15 23.576 ? 0.348 ns/op > BufferStackBench.confined 32 avgt 15 25.272 ? 0.530 ns/op > ``` > > and > > ``` > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.OfVirtual.byPtr avgt 15 4.159 ? 0.097 ns/op > CallOverheadByValue.OfVirtual.byValue avgt 15 16.535 ? 0.433 ns/op > CallOverheadByValue.byPtr avgt 15 4.119 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 15 11.404 ? 0.240 ns/op > ``` What was the result before this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847012659 From rgiulietti at openjdk.org Fri May 2 11:51:55 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 11:51:55 GMT Subject: RFR: 8355992: Add some useful "exact" methods to Math and StrictMath Message-ID: Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. Further, add `unsignedMultiplyExact` methods as well. ------------- Commit messages: - 8355992: Add some useful "exact" methods to Math and StrictMath Changes: https://git.openjdk.org/jdk/pull/25003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25003&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355992 Stats: 324 lines in 2 files changed: 324 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25003/head:pull/25003 PR: https://git.openjdk.org/jdk/pull/25003 From rgiulietti at openjdk.org Fri May 2 11:51:56 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 11:51:56 GMT Subject: RFR: 8355992: Add some useful "exact" methods to Math and StrictMath In-Reply-To: References: Message-ID: <8-F9aOP-sX2MrXtcHsR1vZbA9tv5YW-v3_CrkZP8Co8=.7bdee1c0-b42a-4516-93e4-8ae49af76922@github.com> On Fri, 2 May 2025 11:47:32 GMT, Raffaello Giulietti wrote: > Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. > Further, add `unsignedMultiplyExact` methods as well. Tests will be added once the CSR has been approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25003#issuecomment-2847026026 From mcimadamore at openjdk.org Fri May 2 11:52:49 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 May 2025 11:52:49 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> Message-ID: On Fri, 2 May 2025 11:13:27 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup and only create CleanupAction once per thread Looks good - I left some stylistic comments on the use of records ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24829#pullrequestreview-2811821102 From mcimadamore at openjdk.org Fri May 2 11:52:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 May 2025 11:52:51 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> Message-ID: On Fri, 2 May 2025 11:36:56 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup and only create CleanupAction once per thread > > src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 127: > >> 125: arena, >> 126: new SlicingAllocator(arena.allocate(byteSize, byteAlignment)), >> 127: new CleanupAction(arena)); > > any reason why you didn't use a lambda here? Also, not a big fan of records here -- it seems that many implementation details such as cleanup action, lock and slicing allocator are "leaked out" to the caller, that is now responsible to set things up correctly. I think a `PerThread` class with a constructor taking arena, size, alignment would make the code less coupled and more readable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071496742 From jvernee at openjdk.org Fri May 2 11:52:50 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 2 May 2025 11:52:50 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> Message-ID: On Fri, 2 May 2025 11:13:27 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup and only create CleanupAction once per thread Latest version looks good to me as well. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24829#pullrequestreview-2811825794 From mcimadamore at openjdk.org Fri May 2 11:52:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 May 2025 11:52:51 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> Message-ID: <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com> On Fri, 2 May 2025 11:45:33 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 127: >> >>> 125: arena, >>> 126: new SlicingAllocator(arena.allocate(byteSize, byteAlignment)), >>> 127: new CleanupAction(arena)); >> >> any reason why you didn't use a lambda here? > > Also, not a big fan of records here -- it seems that many implementation details such as cleanup action, lock and slicing allocator are "leaked out" to the caller, that is now responsible to set things up correctly. I think a `PerThread` class with a constructor taking arena, size, alignment would make the code less coupled and more readable. And, if you do that, you then don't need the `of` factory -- clients can just use `new` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071498324 From swen at openjdk.org Fri May 2 11:58:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 11:58:50 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com> Message-ID: <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com> On Fri, 2 May 2025 11:47:15 GMT, Maurizio Cimadamore wrote: >> Also, not a big fan of records here -- it seems that many implementation details such as cleanup action, lock and slicing allocator are "leaked out" to the caller, that is now responsible to set things up correctly. I think a `PerThread` class with a constructor taking arena, size, alignment would make the code less coupled and more readable. > > And, if you do that, you then don't need the `of` factory -- clients can just use `new` > any reason why you didn't use a lambda here? I also think that CleanupAction should be changed to lambda ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071508856 From rgiulietti at openjdk.org Fri May 2 12:00:13 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 12:00:13 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v6] In-Reply-To: References: Message-ID: > See the JBS bug for some details. Raffaello Giulietti 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: - Remove unused BIG_DECIMAL_EXPONENT - Merge branch 'master' into 8343829 - Merge branch 'master' into 8343829 - Redacted comments. - Merge branch 'master' into 8343829 - Minors in comments. - Removed repeated comment. - Refactoring some code and comments. - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22737/files - new: https://git.openjdk.org/jdk/pull/22737/files/092755b4..49ed9aac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=04-05 Stats: 672210 lines in 9937 files changed: 267712 ins; 352817 del; 51681 mod Patch: https://git.openjdk.org/jdk/pull/22737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737 PR: https://git.openjdk.org/jdk/pull/22737 From duke at openjdk.org Fri May 2 12:06:49 2025 From: duke at openjdk.org (ExE Boss) Date: Fri, 2 May 2025 12:06:49 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 07:54:23 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Since when? src/java.base/share/classes/java/lang/ScopedValue.java line 1: > 1: /* It?occurred to?me that?`ScopedValue.NEW_THREAD_BINDINGS` can?be?made package?private and?used in?`Thread`, removing?duplication in?`Thread.NEW_THREAD_BINDINGS`. -------------------------------------------------------------------------------- This?was?done this?way back?when `ScopedValue` lived?under the?`jdk.incubator.*` package?tree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2071516117 From swen at openjdk.org Fri May 2 12:10:51 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 12:10:51 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v6] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:00:13 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti 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: > > - Remove unused BIG_DECIMAL_EXPONENT > - Merge branch 'master' into 8343829 > - Merge branch 'master' into 8343829 > - Redacted comments. > - Merge branch 'master' into 8343829 > - Minors in comments. > - Removed repeated comment. > - Refactoring some code and comments. > - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2352: > 2350: > 2351: /* The precision of the format. */ > 2352: private static final int[] P = { private static final int[] P private static final int[] EP_MIN private static final int[] EP_MAX private static final int[] W private static final int[] E_MAX private static final int[] E_MIN private static final int[] Q_MIN private static final int[] HEX_COUNT These should all be added with @Stable ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2071520733 From rehn at openjdk.org Fri May 2 12:14:50 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 2 May 2025 12:14:50 GMT Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 17:57:37 GMT, Hamlin Li wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into qemu-user-issues >> - more >> - more >> - native or very long > > I also feel annoying to see some tests fail interminently. > > Not sure if I understand the goal of this pr, seems it might not be the best solution to simply disable these tests when running with qemu. My concerns are: qemu is still one of main methods to quickly verify the functionality changes, but when we just disable the failed tests, and maybe in the future disable more and more tests, then qemu is no longer able to play the role it was supposed to play. Thanks @Hamlin-Li and @RealFYang. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2847064204 From swen at openjdk.org Fri May 2 12:26:54 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 12:26:54 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v6] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:00:13 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti 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: > > - Remove unused BIG_DECIMAL_EXPONENT > - Merge branch 'master' into 8343829 > - Merge branch 'master' into 8343829 > - Redacted comments. > - Merge branch 'master' into 8343829 > - Minors in comments. > - Removed repeated comment. > - Refactoring some code and comments. > - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal We can do some cleanup before this PR, such as #24999 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847085253 From alanb at openjdk.org Fri May 2 12:37:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 2 May 2025 12:37:48 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:03:35 GMT, ExE Boss wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Since when? > > src/java.base/share/classes/java/lang/ScopedValue.java line 1: > >> 1: /* > > It?occurred to?me that?`ScopedValue.NEW_THREAD_BINDINGS` can?be?made package?private and?used in?`Thread`, removing?duplication in?`Thread.NEW_THREAD_BINDINGS`. > > -------------------------------------------------------------------------------- > > This?was?done this?way back?when `ScopedValue` lived?under the?`jdk.incubator.*` package?tree. I think it would be better not change that in this PR, as this PR is about making the feature permanent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2071550253 From rgiulietti at openjdk.org Fri May 2 12:40:52 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 12:40:52 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v6] In-Reply-To: References: Message-ID: <0hh5fiC97LYCIv7GQburF28XZt25Z1UFHYvkO2_MH50=.d6c0e09b-19b4-44b0-9039-430bdc38bd10@github.com> On Fri, 2 May 2025 12:00:13 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti 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: > > - Remove unused BIG_DECIMAL_EXPONENT > - Merge branch 'master' into 8343829 > - Merge branch 'master' into 8343829 > - Redacted comments. > - Merge branch 'master' into 8343829 > - Minors in comments. > - Removed repeated comment. > - Refactoring some code and comments. > - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal This is just the first step of a planned overhaul of conversions from decimal strings to floating-point values. There are more steps to come. So I'm not sure that #24999 turns out to be useful at this stage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847108653 From rgiulietti at openjdk.org Fri May 2 12:45:55 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 12:45:55 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46] In-Reply-To: References: <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com> Message-ID: On Tue, 29 Apr 2025 19:11:32 GMT, Johannes Graham wrote: >> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Adjust the type of operand >> - Use a more loose formula to do range check >> >> Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range > > A thought for a future PR - computing long powers could be useful as a public method as well. @j3graham > A thought for a future PR - computing long powers could be useful as a public method as well. FYI, I just submitted #25003. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2847118072 From swen at openjdk.org Fri May 2 12:47:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 12:47:52 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v11] In-Reply-To: References: Message-ID: <7jVupzlyU-2eLnFy6h8c_zmY-hh_zpRXn6gVMbknZTc=.a60050c3-ed30-456c-80d3-3e4df1da9e0f@github.com> On Wed, 30 Apr 2025 20:26:33 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove > - Reviews from viktor > - Rewrite impl to follow the new simplified spec > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove > - Try to simplify the model - use the finish of computeValue > > - Test updates - remove repetition, test case for no stale installation > - Fix incorrect promise removal when unnecessary and add regression test > - Cannot test for recursion eagerly - add test case > - More spec, eager exception, finish with existing, thanks John > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove > - ... and 9 more: https://git.openjdk.org/jdk/compare/b679d9c3...2292212b src/java.base/share/classes/java/lang/ClassValue.java line 371: > 369: Version v = version(); > 370: if (v == null) return false; > 371: if (v.isLive()) return true; Suggestion: if (v == null) return false; if (v.isLive()) return true; Remove a space to align the code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2071561616 From mullan at openjdk.org Fri May 2 12:56:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 May 2025 12:56:50 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang 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 > - add a positive debug log and update exception message > - enhancing exception messages and debug outputs > - update @since tags as required by JEP 12 > - add enum back > - the change src/java.base/share/classes/javax/crypto/KDF.java line 481: > 479: > 480: // Rethrows the IAPE thrown by an implementation, adding an explanation > 481: // on in which situation it fails. suggest rewording as "for the situation in which it fails." src/java.base/share/classes/javax/crypto/KDF.java line 491: > 489: + "using the supplied derivation " > 490: + "inputs, using the " + source + " " > 491: + theOne.provider().getName() Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071561925 PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071567362 From jpai at openjdk.org Fri May 2 12:59:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 2 May 2025 12:59:46 GMT Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based on "os.name" property value [v6] In-Reply-To: References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com> Message-ID: <4EvORA4ZZNr4eJtxhFiKREV5bFXqLj1zVW8hCVY9muM=.824f677f-820e-47d5-8362-c824ee4a03fa@github.com> On Wed, 30 Apr 2025 17:06:28 GMT, Brian Burkhalter wrote: >> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355444: Remove requires tag from ManyFiles Hello Brian, I went back and checked the history of this ManyFiles test. The original test did not have the check to skip running on Linux. I do see which commit introduced that check but it doesn't have any additional details other than the brief code comment which said "Linux does not yet allow opening this many files". That was back in 2003. So I think the removal of this check and `@requires` is fine. > I ran 30 repeats on each of the two Linux architectures in the CI I would suggest doing a similar run without specifying a specific test platform. That way it will get run on all relevant platforms. I don't expect it to fail, but it would be good to have that tested before this is integrated. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24860#pullrequestreview-2811947219 From dl at openjdk.org Fri May 2 13:21:45 2025 From: dl at openjdk.org (Doug Lea) Date: Fri, 2 May 2025 13:21:45 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote: > We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR. > > 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take > > The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. > > 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators > > LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. > > The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking. > > This can be fixed very easily by linking both f.prev and f.next back to f. > > 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached > > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > 4. LinkedBlockingDeque allows us to overflow size with addAll() > > In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed... I agree that these changes make behavior more consistent with LinkedBlockingQueue, which is worth doing. Thanks for finding straightforward ways to do these that don't impact anything else. Changing count field to volatile and sometimes read outside of lock introduces more potential non-sequential-consistency (for example checking size while adding) but doesn't impact observable guarantees. It may have small performance impact in either direction that could vary across platforms, but I have not detected any. There are possible (not likely, and still legal according to spec) observable consequences of using lockInterruptibly, but better to have them now not surprisingly different than other blocking queues. ------------- Marked as reviewed by dl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24925#pullrequestreview-2811993260 From rgiulietti at openjdk.org Fri May 2 13:34:02 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 13:34:02 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: > See the JBS bug for some details. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Make some static arrays @Stable. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22737/files - new: https://git.openjdk.org/jdk/pull/22737/files/49ed9aac..41d070ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=05-06 Stats: 13 lines in 1 file changed: 10 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737 PR: https://git.openjdk.org/jdk/pull/22737 From swen at openjdk.org Fri May 2 13:42:48 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 13:42:48 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 13:34:02 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Make some static arrays @Stable. Q_MIN -> E_MIN -> E_MAX -> W -> P Five layers of Stable, I don't know if C2 can work correctly, maybe need to confirm ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847240211 From swen at openjdk.org Fri May 2 13:44:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 13:44:47 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:41:38 GMT, Per Minborg wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > Updated benchmarks: > > > Benchmark (ELEM_SIZE) Mode Cnt Score Error Units > BufferStackBench.OfVirtual.buffer 8 avgt 15 12.695 ? 0.205 ns/op > BufferStackBench.OfVirtual.buffer 16 avgt 15 12.622 ? 0.078 ns/op > BufferStackBench.OfVirtual.buffer 32 avgt 15 12.523 ? 0.022 ns/op > BufferStackBench.OfVirtual.confined 8 avgt 15 22.902 ? 0.407 ns/op > BufferStackBench.OfVirtual.confined 16 avgt 15 23.858 ? 0.652 ns/op > BufferStackBench.OfVirtual.confined 32 avgt 15 25.544 ? 0.458 ns/op > BufferStackBench.buffer 8 avgt 15 4.923 ? 0.029 ns/op > BufferStackBench.buffer 16 avgt 15 4.971 ? 0.095 ns/op > BufferStackBench.buffer 32 avgt 15 4.980 ? 0.105 ns/op > BufferStackBench.confined 8 avgt 15 22.713 ? 0.289 ns/op > BufferStackBench.confined 16 avgt 15 23.576 ? 0.348 ns/op > BufferStackBench.confined 32 avgt 15 25.272 ? 0.530 ns/op > > > and > > > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.OfVirtual.byPtr avgt 15 4.159 ? 0.097 ns/op > CallOverheadByValue.OfVirtual.byValue avgt 15 16.535 ? 0.433 ns/op > CallOverheadByValue.byPtr avgt 15 4.119 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 15 11.404 ? 0.240 ns/op https://github.com/minborg/jdk/pull/7 @minborg I submitted a PR to you, please see if it is useful to you ------------- PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847244523 From rgiulietti at openjdk.org Fri May 2 13:48:47 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 13:48:47 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 13:40:14 GMT, Shaojin Wen wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Make some static arrays @Stable. > > Q_MIN -> E_MIN -> E_MAX -> W -> P Five layers of Stable, I don't know if C2 can work correctly, maybe need to confirm @wenshao Do you mean that C2 might generate erroneous code (bad situation!), or that it might not take advantage of `@Stable` in optimized code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847252667 From swen at openjdk.org Fri May 2 14:04:49 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 14:04:49 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. >> >> >> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac): >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail avgt 30 24.330 ? 0.820 ns/op >> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess avgt 30 8.257 ? 0.117 ns/op >> CaptureStateUtilBench.OfVirtual.explicitAllocationFail avgt 30 41.415 ? 1.013 ns/op >> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess avgt 30 21.720 ? 0.463 ns/op >> CaptureStateUtilBench.OfVirtual.tlAllocationFail avgt 30 23.636 ? 0.182 ns/op >> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess avgt 30 8.234 ? 0.156 ns/op >> CaptureStateUtilBench.adaptedSysCallFail avgt 30 23.918 ? 0.487 ns/op >> CaptureStateUtilBench.adaptedSysCallSuccess avgt 30 4.946 ? 0.089 ns/op >> CaptureStateUtilBench.explicitAllocationFail avgt 30 42.280 ? 1.128 ns/op >> CaptureStateUtilBench.explicitAllocationSuccess avgt 30 21.809 ? 0.413 ns/op >> CaptureStateUtilBench.tlAllocationFail avgt 30 24.422 ? 0.673 ns/op >> CaptureStateUtilBench.tlAllocationSuccess avgt 30 5.182 ? 0.152 ns/op >> >> >> Adapted system call: >> >> return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool >> ``` >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> ``` >> Thread Local allocation: >> >> try (var arena = POOLS.take()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool >> } >> ``` >> The adapted system call exhibits a ~4x performance improvement ove... > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add hashCode/equals to record to improve startup time src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 726: > 724: return this instanceof NoInitSegmentAllocator noInit ? > 725: noInit.allocateNoInit(byteSize, 1) : > 726: allocate(byteSize); Suggestion: return this instanceof NoInitSegmentAllocator noInit ? noInit.allocateNoInit(byteSize, 1) : allocate(byteSize); How about a different coding style? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r2071659669 From swen at openjdk.org Fri May 2 14:07:46 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 14:07:46 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 13:40:14 GMT, Shaojin Wen wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Make some static arrays @Stable. > > Q_MIN -> E_MIN -> E_MAX -> W -> P Five layers of Stable, I don't know if C2 can work correctly, maybe need to confirm > @wenshao Do you mean that C2 might generate erroneous code (bad situation!), or that it might not take advantage of `@Stable` in optimized code? I am worried that too many layers will cause C2 to not be optimized, but I am not sure, and I also hope to learn how to know that `@Stable` works ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847290855 From pminborg at openjdk.org Fri May 2 14:08:46 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 14:08:46 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath In-Reply-To: References: Message-ID: On Fri, 2 May 2025 11:47:32 GMT, Raffaello Giulietti wrote: > Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. > Further, add `unsignedMultiplyExact` methods as well. Maybe it is too late, but shouldn't there be a better way to structure all these methods and variants in Math and MathExact? x(), xExact() and all the different parameter types create a rather big Cartesian product. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25003#issuecomment-2847293324 From rgiulietti at openjdk.org Fri May 2 14:12:46 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 14:12:46 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: <-V6dZL-N-yUiRPE0Dj661ygG4XB_6CKLzK3AaVtxmno=.fc380bc5-d43d-41a0-b69a-96fd55aa868a@github.com> On Fri, 2 May 2025 13:34:02 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Make some static arrays @Stable. I'm not worried if C2 cannot optimize too many levels of `@Stable` here. The values are used in an unusually long method, so I don't think there are measurable benefits anyway. In contrast, I would be _much_ concerned if there are real risks of erroneous code being generated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847304061 From rgiulietti at openjdk.org Fri May 2 14:17:45 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 14:17:45 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:06:23 GMT, Per Minborg wrote: >> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. >> Further, add `unsignedMultiplyExact` methods as well. > > Maybe it is too late, but shouldn't there be a better way to structure all these methods and variants in Math and MathExact? x(), xExact() and all the different parameter types create a rather big Cartesian product. @minborg I'm open to suggestions for the `pow` methods. But for the `unsignedMultiplyExact` methods, as their signed counterparts are already in `[Strict]Math` since a long time, I think they should land there as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25003#issuecomment-2847316992 From pminborg at openjdk.org Fri May 2 14:17:58 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 14:17:58 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com> <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com> Message-ID: On Fri, 2 May 2025 11:56:31 GMT, Shaojin Wen wrote: >> And, if you do that, you then don't need the `of` factory -- clients can just use `new` > >> any reason why you didn't use a lambda here? > > I also think that CleanupAction should be changed to lambda Using an anonymous class for the cleanup action had very adverse effects on performance. I didn't want to use a lambda for startup performance reasons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071674052 From pminborg at openjdk.org Fri May 2 14:17:57 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 14:17:57 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> Message-ID: <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com> On Fri, 2 May 2025 11:13:27 GMT, Per Minborg wrote: >> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. >> >> Re-allocated segments are not zeroed between allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup and only create CleanupAction once per thread The performance before this PR can be seen in the "confined" benchmarks above. In those benchmarks, a regular `Arena.ofConfined` is created upon every invocation. I will integrate this PR now @wenshao . Can you summarize your proposed changes below as It was a bit unclear to me what you meant. I can create a separate PR with those changes later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847309534 PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847314767 From pminborg at openjdk.org Fri May 2 14:18:01 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 May 2025 14:18:01 GMT Subject: Integrated: 8349146: [REDO] Implement a better allocator for downcalls In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 14:05:58 GMT, Per Minborg wrote: > This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance. > > Re-allocated segments are not zeroed between allocations. This pull request has now been integrated. Changeset: 9f9e73d5 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/9f9e73d5f9fcb5e926a2674c54cbbc92012b75f6 Stats: 1004 lines in 11 files changed: 983 ins; 15 del; 6 mod 8349146: [REDO] Implement a better allocator for downcalls Reviewed-by: mcimadamore, jvernee, liach ------------- PR: https://git.openjdk.org/jdk/pull/24829 From jpai at openjdk.org Fri May 2 14:24:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 2 May 2025 14:24:47 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 13:34:02 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Make some static arrays @Stable. If I understand correctly, we are talking about several (primitive) array type fields having a `@Stable` annotation, in a single class, right? So we aren't really talking about levels? If so, given what `@Stable` is documented to do, I don't think the number of fields annotated as `@Stable` plays any role in the C2 compiler generating the resultant code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847334140 From rriggs at openjdk.org Fri May 2 14:42:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 14:42:46 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici wrote: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314: > 312: *

> 313: * WARNING: The caller of this method shall relinquish and transfer the > 314: * ownership of the byte array to the callee, since the later will not Typo: "later" -> "latter". (pre-existing) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2071714828 From swen at openjdk.org Fri May 2 14:46:54 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 14:46:54 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com> Message-ID: On Fri, 2 May 2025 14:14:28 GMT, Per Minborg wrote: > Can you summarize your proposed changes below as It was a bit unclear to me what you meant. I can create a separate PR with those changes later. My suggestion is to use two records (both PerThread and Frame) to replace the original inner class Frame. This would also eliminate one use of @ForceInline. This might just be my personal coding style preference ? feel free to adopt it if you like. Just a suggestion! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847381560 From nbenalla at openjdk.org Fri May 2 14:57:52 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 2 May 2025 14:57:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 Message-ID: Get JDK 26 underway. ------------- Commit messages: - Update copyright years - Update --release 25 symbol information for JDK 24 build 20 - initial commit start-of-JDK-26 Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355746 Stats: 1193 lines in 54 files changed: 1100 ins; 16 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Fri May 2 15:05:44 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 2 May 2025 15:05:44 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla wrote: > Get JDK 26 underway. This initial commit of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2847422764 From rgiulietti at openjdk.org Fri May 2 15:12:01 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 15:12:01 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: > Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. > Further, add `unsignedMultiplyExact` methods as well. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Clearer and more complete spec of the *pow* methods. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25003/files - new: https://git.openjdk.org/jdk/pull/25003/files/9ab1add2..2d3405f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25003&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25003&range=00-01 Stats: 24 lines in 2 files changed: 8 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25003/head:pull/25003 PR: https://git.openjdk.org/jdk/pull/25003 From liach at openjdk.org Fri May 2 15:17:25 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 15:17:25 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12] In-Reply-To: References: Message-ID: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> > The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. > > The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. > > The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. > > Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/ClassValue.java Co-authored-by: Shaojin Wen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24043/files - new: https://git.openjdk.org/jdk/pull/24043/files/2292212b..3d68f09a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043 PR: https://git.openjdk.org/jdk/pull/24043 From duke at openjdk.org Fri May 2 15:24:45 2025 From: duke at openjdk.org (kabutz) Date: Fri, 2 May 2025 15:24:45 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Fri, 2 May 2025 13:19:13 GMT, Doug Lea

wrote: >> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR. >> >> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take >> >> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. >> >> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators >> >> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. >> >> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking. >> >> This can be fixed very easily by linking both f.prev and f.next back to f. >> >> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached >> >> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. >> >> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. >> >> 4. LinkedBlockingDeque allows us to overflow size with addAll() >> >> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst hol... > > I agree that these changes make behavior more consistent with LinkedBlockingQueue, which is worth doing. Thanks for finding straightforward ways to do these that don't impact anything else. > Changing count field to volatile and sometimes read outside of lock introduces more potential non-sequential-consistency (for example checking size while adding) but doesn't impact observable guarantees. It may have small performance impact in either direction that could vary across platforms, but I have not detected any. > There are possible (not likely, and still legal according to spec) observable consequences of using lockInterruptibly, but better to have them now not surprisingly different than other blocking queues. Thanks @DougLea ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2847463059 From rgiulietti at openjdk.org Fri May 2 15:31:49 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 15:31:49 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:21:54 GMT, Jaikiran Pai wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Make some static arrays @Stable. > > If I understand correctly, we are talking about several (primitive) array type fields having a `@Stable` annotation, in a single class, right? So we aren't really talking about levels? > If so, given what `@Stable` is documented to do, I don't think the number of fields annotated as `@Stable` plays any role in the C2 compiler generating the resultant code. @jaikiran "Levels" in the sense that Q_MIN depends on E_MIN, which depends on E_MAX, which depends on W, which depends on P. If `@Stable` helps, which I think it does, great. If it doesn't, it shouldn't matter in practice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847498217 From duke at openjdk.org Fri May 2 15:43:47 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 15:43:47 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: <5Kbr6WiyE1kEPtuX2j-jJ0O05jWkoYIFwuR4FUes7ig=.c02a5248-b8f5-4edb-a464-fe256fae40aa@github.com> On Fri, 2 May 2025 15:12:01 GMT, Raffaello Giulietti wrote: >> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. >> Further, add `unsignedMultiplyExact` methods as well. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Clearer and more complete spec of the *pow* methods. Some easy optimizations for special cases. ------------- Changes requested by fabioromano1 at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/25003#pullrequestreview-2812333652 From liach at openjdk.org Fri May 2 15:49:52 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 15:49:52 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang 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 > - add a positive debug log and update exception message > - enhancing exception messages and debug outputs > - update @since tags as required by JEP 12 > - add enum back > - the change The changes to finalize this preview feature look good. I did not review the extra security-specific changes in KDF.java and KDFDelayedProviderException.java. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2812347049 From bpb at openjdk.org Fri May 2 15:51:46 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 May 2025 15:51:46 GMT Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based on "os.name" property value [v6] In-Reply-To: <4EvORA4ZZNr4eJtxhFiKREV5bFXqLj1zVW8hCVY9muM=.824f677f-820e-47d5-8362-c824ee4a03fa@github.com> References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com> <4EvORA4ZZNr4eJtxhFiKREV5bFXqLj1zVW8hCVY9muM=.824f677f-820e-47d5-8362-c824ee4a03fa@github.com> Message-ID: <71VXdPis_VBu-CuKJD1UyxjB-spGSIQpemzbCXqumJQ=.00cea23a-cca0-415a-bc12-aa5928210e8a@github.com> On Fri, 2 May 2025 12:56:49 GMT, Jaikiran Pai wrote: > I would suggest doing a similar run without specifying a specific test platform. That way it will get run on all relevant platforms. I don't expect it to fail, but it would be good to have that tested before this is integrated. I ran 30 repeats on all five platforms and there were no failures. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2847557213 From jlu at openjdk.org Fri May 2 15:53:22 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 May 2025 15:53:22 GMT Subject: RFR: 8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out Message-ID: Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`. This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster. Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/25009/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25009&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356040 Stats: 132 lines in 1 file changed: 63 ins; 48 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/25009.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25009/head:pull/25009 PR: https://git.openjdk.org/jdk/pull/25009 From liach at openjdk.org Fri May 2 15:56:47 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 15:56:47 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla wrote: > Get JDK 26 underway. Changes requested by liach (Reviewer). make/conf/version-numbers.conf line 36: > 34: DEFAULT_VERSION_EXTRA2=0 > 35: DEFAULT_VERSION_EXTRA3=0 > 36: DEFAULT_VERSION_DATE=2026-03-16 Is this accurate? src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58: > 56: */ > 57: @SupportedAnnotationTypes("*") > 58: @SupportedSourceVersion(SourceVersion.RELEASE_26) This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`. test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229: > 227: // Check the class' major_version. This field is after the magic and minor_version fields, which > 228: // use 4 and 2 bytes respectively. > 229: if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) { Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API. Open a JBS issue and identify the hotspot tests failing without this change. test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50: > 48: public class HelpOutputColumnWidthTest extends TestRunner { > 49: > 50: public static final int MAX_COLUMNS = 84; What is this for? ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2812349246 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071811476 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071815767 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071819374 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071817584 From bpb at openjdk.org Fri May 2 16:05:05 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 May 2025 16:05:05 GMT Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value [v2] In-Reply-To: References: Message-ID: <3sk11HrnNbniie2o0JSpDgfN7XuZiezp0FX7PBUjgoA=.ede9ebbe-b077-40a0-8e9f-3374dac217b7@github.com> > For tests of the `java.io` package, instead of doing this > > public static void main(String[] args) throws Exception { > if (File.separatorChar != '\') { > /* This test is only valid on win32 systems */ > return; > } > > do this > > @requires (os.family == "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 two commits: - Merge - 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value ------------- Changes: https://git.openjdk.org/jdk/pull/24838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24838&range=01 Stats: 61 lines in 10 files changed: 10 ins; 35 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24838/head:pull/24838 PR: https://git.openjdk.org/jdk/pull/24838 From bpb at openjdk.org Fri May 2 16:05:06 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 May 2025 16:05:06 GMT Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value In-Reply-To: References: Message-ID: On Thu, 24 Apr 2025 00:33:20 GMT, Brian Burkhalter wrote: > For tests of the `java.io` package, instead of doing this > > public static void main(String[] args) throws Exception { > if (File.separatorChar != '\') { > /* This test is only valid on win32 systems */ > return; > } > > do this > > @requires (os.family == "windows") df687c0 resolves a conflict with SJIS.java test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24838#issuecomment-2847582924 From duke at openjdk.org Fri May 2 16:10:51 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 16:10:51 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 15:12:01 GMT, Raffaello Giulietti wrote: >> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. >> Further, add `unsignedMultiplyExact` methods as well. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Clearer and more complete spec of the *pow* methods. Some easy optimizations for special cases. src/java.base/share/classes/java/lang/Math.java line 3494: > 3492: return 1; > 3493: } > 3494: if (x == 0 || x == 1) { Suggestion: if (x == 0 || x == 1 || n == 1) { src/java.base/share/classes/java/lang/Math.java line 3500: > 3498: return (n & 0b1) == 0 ? 1 : -1; > 3499: } > 3500: Suggestion: if (x == 2) { if (n >= Integer.SIZE - 1) throw new ArithmeticException("integer overflow"); return 1 << n; } if (x == -2) { if (n >= Integer.SIZE) throw new ArithmeticException("integer overflow"); // if n == Integer.SIZE - 1, result is correct return (n & 0b1) == 0 ? 1 << n : -(1 << n); } if ((java.math.BigInteger.bitLengthForInt(Math.abs(x)) - 1L) * n + 1L > Integer.SIZE) { throw new ArithmeticException("integer overflow"); } With also a check for the condition `java.math.BigInteger.bitLengthForInt(Math.abs(x)) * n < Integer.SIZE`, when it is true the path could be led to a loop that skips the checks. src/java.base/share/classes/java/lang/Math.java line 3532: > 3530: return 1; > 3531: } > 3532: if (x == 0 || x == 1) { Suggestion: if (x == 0 || x == 1 || n == 1) { src/java.base/share/classes/java/lang/Math.java line 3535: > 3533: return x; > 3534: } > 3535: Suggestion: if (x == 2) { if (n >= Integer.SIZE) throw new ArithmeticException("unsigned integer overflow"); return 1 << n; } if ((java.math.BigInteger.bitLengthForInt(x) - 1L) * n + 1L > Integer.SIZE) { throw new ArithmeticException("unsigned integer overflow"); } With also a check for the condition `java.math.BigInteger.bitLengthForInt(x) * n <= Integer.SIZE`, when it is true the path could be led to a loop that skips the checks. src/java.base/share/classes/java/lang/Math.java line 3567: > 3565: return 1; > 3566: } > 3567: if (x == 0 || x == 1) { Suggestion: if (x == 0 || x == 1 || n == 1) { src/java.base/share/classes/java/lang/Math.java line 3573: > 3571: return (n & 0b1) != 0 ? -1 : 1; > 3572: } > 3573: Suggestion: if (x == 2) { if (n >= Long.SIZE - 1) throw new ArithmeticException("long overflow"); return 1L << n; } if (x == -2) { if (n >= Long.SIZE) throw new ArithmeticException("long overflow"); // if n == Long.SIZE - 1, result is correct return (n & 0b1) == 0 ? 1L << n : -(1L << n); } if ((java.math.BigInteger.bitLengthForLong(Math.abs(x)) - 1L) * n + 1L > Long.SIZE) { throw new ArithmeticException("long overflow"); } With also a check for the condition `java.math.BigInteger.bitLengthForLong(Math.abs(x)) * n < Long.SIZE`, when it is true the path could be led to a loop that skips the checks. src/java.base/share/classes/java/lang/Math.java line 3610: > 3608: * very small when |x| > 1, but not necessarily when |x| <= 1. > 3609: */ > 3610: if (x == 0 || x == 1) { Suggestion: if (x == 0 || x == 1 || n == 1) { src/java.base/share/classes/java/lang/Math.java line 3613: > 3611: return x; > 3612: } > 3613: Suggestion: if (x == 2) { if (n >= Long.SIZE) throw new ArithmeticException("unsigned long overflow"); return 1L << n; } if ((java.math.BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE) { throw new ArithmeticException("unsigned long overflow"); } With also a check for the condition `java.math.BigInteger.bitLengthForLong(x) * n <= Long.SIZE`, when it is true the path could be led to a loop that skips the checks. ------------- PR Review: https://git.openjdk.org/jdk/pull/25003#pullrequestreview-2812357251 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071832231 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071832373 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071833435 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071833501 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071838381 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071833854 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071816617 PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071837334 From swen at openjdk.org Fri May 2 16:10:56 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 16:10:56 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com> <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com> Message-ID: On Fri, 2 May 2025 14:11:19 GMT, Per Minborg wrote: >>> any reason why you didn't use a lambda here? >> >> I also think that CleanupAction should be changed to lambda > > Using an anonymous class for the cleanup action had very adverse effects on performance. I didn't want to use a lambda for startup performance reasons. If using lambda affects performance, how about using anonymous classes? return new PerThread(new ReentrantLock(), arena, new SlicingAllocator(arena.allocate(byteSize, byteAlignment)), new Consumer() { @Override public void accept(MemorySegment memorySegment) { Reference.reachabilityFence(arena); }}); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071839071 From rgiulietti at openjdk.org Fri May 2 16:25:46 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 16:25:46 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:07:31 GMT, fabioromano1 wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Clearer and more complete spec of the *pow* methods. > > src/java.base/share/classes/java/lang/Math.java line 3567: > >> 3565: return 1; >> 3566: } >> 3567: if (x == 0 || x == 1) { > > Suggestion: > > if (x == 0 || x == 1 || n == 1) { @fabioromano1 Unless there's evidence that these cases are _very very_ common, there's no point in adding fast paths. See this comment in `unsignedPowExact(long,int)` /* * To keep the code as simple as possible, there are intentionally * no fast paths, except for |x| <= 1. * The reason is that the number of loop iterations below can be kept * very small when |x| > 1, but not necessarily when |x| <= 1. */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071857047 From duke at openjdk.org Fri May 2 16:29:46 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 16:29:46 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:23:24 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/lang/Math.java line 3567: >> >>> 3565: return 1; >>> 3566: } >>> 3567: if (x == 0 || x == 1) { >> >> Suggestion: >> >> if (x == 0 || x == 1 || n == 1) { > > @fabioromano1 Unless there's evidence that these cases are _very very_ common, there's no point in adding fast paths. > See this comment in `unsignedPowExact(long,int)` > > > /* > * To keep the code as simple as possible, there are intentionally > * no fast paths, except for |x| <= 1. > * The reason is that the number of loop iterations below can be kept > * very small when |x| > 1, but not necessarily when |x| <= 1. > */ @rgiulietti I would keep at least `n == 1` and `(bitLength(x) - 1L) * n + 1L > SIZE` cases ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071860872 From naoto at openjdk.org Fri May 2 16:43:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 May 2025 16:43:46 GMT Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value [v2] In-Reply-To: <3sk11HrnNbniie2o0JSpDgfN7XuZiezp0FX7PBUjgoA=.ede9ebbe-b077-40a0-8e9f-3374dac217b7@github.com> References: <3sk11HrnNbniie2o0JSpDgfN7XuZiezp0FX7PBUjgoA=.ede9ebbe-b077-40a0-8e9f-3374dac217b7@github.com> Message-ID: On Fri, 2 May 2025 16:05:05 GMT, Brian Burkhalter wrote: >> For tests of the `java.io` package, instead of doing this >> >> public static void main(String[] args) throws Exception { >> if (File.separatorChar != '\') { >> /* This test is only valid on win32 systems */ >> return; >> } >> >> do this >> >> @requires (os.family == "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 two commits: > > - Merge > - 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24838#pullrequestreview-2812461982 From liach at openjdk.org Fri May 2 16:44:53 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 16:44:53 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com> <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com> <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com> Message-ID: On Fri, 2 May 2025 16:08:09 GMT, Shaojin Wen wrote: >> Using an anonymous class for the cleanup action had very adverse effects on performance. I didn't want to use a lambda for startup performance reasons. > > If using lambda affects performance, how about using anonymous classes? > > return new PerThread(new ReentrantLock(), > arena, > new SlicingAllocator(arena.allocate(byteSize, byteAlignment)), > new Consumer() { > @Override > public void accept(MemorySegment memorySegment) { > Reference.reachabilityFence(arena); > }}); Anonymous classes also captures outer variables and break cleaner/GC. The only safe measures are local enums or records, which never capture outer variables (anonymous classes cannot be enum or records) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071880222 From rgiulietti at openjdk.org Fri May 2 16:47:47 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 16:47:47 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:06:42 GMT, fabioromano1 wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Clearer and more complete spec of the *pow* methods. > > src/java.base/share/classes/java/lang/Math.java line 3613: > >> 3611: return x; >> 3612: } >> 3613: > > Suggestion: > > > if (x == 2) { > if (n >= Long.SIZE) > throw new ArithmeticException("unsigned long overflow"); > return 1L << n; > } > > if ((java.math.BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE) { > throw new ArithmeticException("unsigned long overflow"); > } > > With also a check for the condition `java.math.BigInteger.bitLengthForLong(x) * n <= Long.SIZE`, when it is true the path could be led to a loop that skips the checks. I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications. Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does. How would you pre-check these two cases using integer arithmetic? IMO, you still need checked multiplications in the loop. (Besides, the product in your checks can overflow, so you would have to add a guard.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071884269 From darcy at openjdk.org Fri May 2 16:47:48 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 May 2025 16:47:48 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 15:47:43 GMT, Chen Liang wrote: >> Get JDK 26 underway. > > make/conf/version-numbers.conf line 36: > >> 34: DEFAULT_VERSION_EXTRA2=0 >> 35: DEFAULT_VERSION_EXTRA3=0 >> 36: DEFAULT_VERSION_DATE=2026-03-16 > > Is this accurate? One day off; should be 2026-03-17. I should have double-checked that in the initial authoring of the change. > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58: > >> 56: */ >> 57: @SupportedAnnotationTypes("*") >> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26) > > This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`. The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation. > test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229: > >> 227: // Check the class' major_version. This field is after the magic and minor_version fields, which >> 228: // use 4 and 2 bytes respectively. >> 229: if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) { > > Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API. Open a JBS issue and identify the hotspot tests failing without this change. There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change. > test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50: > >> 48: public class HelpOutputColumnWidthTest extends TestRunner { >> 49: >> 50: public static final int MAX_COLUMNS = 84; > > What is this for? It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26". Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071878858 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071883440 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071881672 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071880549 From alanb at openjdk.org Fri May 2 16:47:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 2 May 2025 16:47:49 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:43:02 GMT, Joe Darcy wrote: >> test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229: >> >>> 227: // Check the class' major_version. This field is after the magic and minor_version fields, which >>> 228: // use 4 and 2 bytes respectively. >>> 229: if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) { >> >> Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API. Open a JBS issue and identify the hotspot tests failing without this change. > > There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change. Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071884496 From rgiulietti at openjdk.org Fri May 2 16:56:46 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 16:56:46 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com> On Fri, 2 May 2025 16:26:48 GMT, fabioromano1 wrote: >> @fabioromano1 Unless there's evidence that these cases are _very very_ common, there's no point in adding fast paths. >> See this comment in `unsignedPowExact(long,int)` >> >> >> /* >> * To keep the code as simple as possible, there are intentionally >> * no fast paths, except for |x| <= 1. >> * The reason is that the number of loop iterations below can be kept >> * very small when |x| > 1, but not necessarily when |x| <= 1. >> */ > > @rgiulietti I would keep at least `n == 1` and `(bitLength(x) - 1L) * n + 1L > SIZE` cases Again, I don't think that `n == 1` is a frequent case which would make any practical difference. As for the `bitLength` check, the product might overflow. Further, `bitLength` might not be that cheap. Finally, the test would just help to _fail_ faster at the expense of making the successful runs slightly slower. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071894199 From liach at openjdk.org Fri May 2 16:58:50 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 16:58:50 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:45:42 GMT, Alan Bateman wrote: >> There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change. > > Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated. I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071895599 From liach at openjdk.org Fri May 2 16:58:49 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 16:58:49 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com> On Fri, 2 May 2025 16:44:40 GMT, Joe Darcy wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58: >> >>> 56: */ >>> 57: @SupportedAnnotationTypes("*") >>> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26) >> >> This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`. > > The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation. May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071896732 From swen at openjdk.org Fri May 2 17:01:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 17:01:14 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: <9ACW3UJDsgcJh02OftWGSeFNa5dbZVtG5NRVSuk5QnQ=.5119a855-507e-4d8a-a069-6b927a9a049e@github.com> On Fri, 2 May 2025 16:04:18 GMT, fabioromano1 wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Clearer and more complete spec of the *pow* methods. > > src/java.base/share/classes/java/lang/Math.java line 3500: > >> 3498: return (n & 0b1) == 0 ? 1 : -1; >> 3499: } >> 3500: > > Suggestion: > > > if (x == 2) { > if (n >= Integer.SIZE - 1) > throw new ArithmeticException("integer overflow"); > return 1 << n; > } > if (x == -2) { > if (n >= Integer.SIZE) > throw new ArithmeticException("integer overflow"); > // if n == Integer.SIZE - 1, result is correct > return (n & 0b1) == 0 ? 1 << n : -(1 << n); > } > > if ((java.math.BigInteger.bitLengthForInt(Math.abs(x)) - 1L) * n + 1L > Integer.SIZE) { > throw new ArithmeticException("integer overflow"); > } > > With also a check for the condition `java.math.BigInteger.bitLengthForInt(Math.abs(x)) * n < Integer.SIZE`, when it is true the path could be led to a loop that skips the checks. return (n & 0b1) == 0 ? 1 << n : -(1 << n); Equivalent to return ((1 << n) ^ -(n & 1)) + (n & 1); Without branches it should be faster ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071898882 From bpb at openjdk.org Fri May 2 17:02:53 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 May 2025 17:02:53 GMT Subject: Integrated: 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value In-Reply-To: References: Message-ID: <3dtOWqD2k007_CZB3GDr45ASiJzFnA0b1pylZIwga-U=.3558a43c-491d-4a3e-8567-9860b7d316bb@github.com> On Thu, 24 Apr 2025 00:33:20 GMT, Brian Burkhalter wrote: > For tests of the `java.io` package, instead of doing this > > public static void main(String[] args) throws Exception { > if (File.separatorChar != '\') { > /* This test is only valid on win32 systems */ > return; > } > > do this > > @requires (os.family == "windows") This pull request has now been integrated. Changeset: 4826a91e Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/4826a91e7a729999343f450ab7ec4621cc418550 Stats: 61 lines in 10 files changed: 10 ins; 35 del; 16 mod 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value Reviewed-by: naoto, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/24838 From bpb at openjdk.org Fri May 2 17:03:00 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 May 2025 17:03:00 GMT Subject: Integrated: 8355444: [java.io] Use @requires tag instead of exiting based on "os.name" property value In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com> References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com> Message-ID: On Thu, 24 Apr 2025 20:46:42 GMT, Brian Burkhalter wrote: > Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system. This pull request has now been integrated. Changeset: 5faa5590 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/5faa55902211e5ad8edc51282022ed9db3684b25 Stats: 46 lines in 6 files changed: 13 ins; 25 del; 8 mod 8355444: [java.io] Use @requires tag instead of exiting based on "os.name" property value Reviewed-by: jpai, lancea ------------- PR: https://git.openjdk.org/jdk/pull/24860 From aph at openjdk.org Fri May 2 17:04:05 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 2 May 2025 17:04:05 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v4] In-Reply-To: References: Message-ID: > Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a null argument. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Remove unnecessary @since 25 - Remove unnecessary @enablePreview in some tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24923/files - new: https://git.openjdk.org/jdk/pull/24923/files/d3f2ff1f..8f626617 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=02-03 Stats: 4 lines in 4 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923 PR: https://git.openjdk.org/jdk/pull/24923 From duke at openjdk.org Fri May 2 17:09:47 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 17:09:47 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:45:28 GMT, Raffaello Giulietti wrote: > I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications. > > Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does. How would you pre-check these two cases using integer arithmetic? > > IMO, you still need checked multiplications in the loop. > > (Besides, the product in your checks can overflow, so you would have to add a guard.) @rgiulietti 1. `BigInteger.bitLengthForLong(x) * n <= Long.SIZE` is a sufficient condition to ensure no overflow; 2. `(BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE` is a sufficient condition to ensure the overflow. Thus, there remain only the cases when ` Long.SIZE < BigInteger.bitLengthForLong(x) * n && (BigInteger.bitLengthForLong(x) - 1L) * n + 1L <= Long.SIZE`, in this cases checked multiplications in the loop are needed. Moreover, `BigInteger.bitLengthForLong(x) - 1L` is a `long`, so the product does not overflow, so the condition at point 1 never overflows if it is evaluated only if the condition at point 2 is false. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071904898 From naoto at openjdk.org Fri May 2 17:18:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 May 2025 17:18:51 GMT Subject: RFR: 8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out In-Reply-To: References: Message-ID: On Fri, 2 May 2025 15:49:03 GMT, Justin Lu wrote: > Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`. > > This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster. > > Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`. Looks good. test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 61: > 59: * This is not an exhaustive test. Such a test would require iterating (1000x1000)+ > 60: * inputs. Instead, we check against Japanese lang locales which guarantees > 61: * we will run into cases where the CLDR is not preferred and the SPI has defined It would be helpful to mention why CLDR is not the preferred provider (as the SPI impl has variants of the Japanese locale) test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 92: > 90: String jresctry = null; > 91: String jresvrnt = null; > 92: if (!lang.equals("")) { Can be replaced with `isEmpty()` ------------- PR Review: https://git.openjdk.org/jdk/pull/25009#pullrequestreview-2812517069 PR Review Comment: https://git.openjdk.org/jdk/pull/25009#discussion_r2071912893 PR Review Comment: https://git.openjdk.org/jdk/pull/25009#discussion_r2071918059 From duke at openjdk.org Fri May 2 17:19:57 2025 From: duke at openjdk.org (Christoph) Date: Fri, 2 May 2025 17:19:57 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. Followed the stepa and built an unsigned image first and then signed the jpackage build and created the pkg/dmg files. However, notarization fails as it says it's not signed at all: e.g.: > "path": "JabRef-6.0_arm64.dmg/JabRef.app/Contents/MacOS/JabRef", "message": "The binary is not signed with a valid Developer ID certificate.", [ notarylog.log](https://github.com/user-attachments/files/20016162/notarylog.log) Testing now with a presigned image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847722058 From rgiulietti at openjdk.org Fri May 2 17:20:46 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 17:20:46 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:03:30 GMT, fabioromano1 wrote: >> I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications. >> >> Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does. >> How would you pre-check these two cases using integer arithmetic? >> >> IMO, you still need checked multiplications in the loop. >> >> (Besides, the product in your checks can overflow, so you would have to add a guard.) > >> I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications. >> >> Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does. How would you pre-check these two cases using integer arithmetic? >> >> IMO, you still need checked multiplications in the loop. >> >> (Besides, the product in your checks can overflow, so you would have to add a guard.) > > @rgiulietti > > 1. `BigInteger.bitLengthForLong(x) * n <= Long.SIZE` is a sufficient condition to ensure no overflow; > > 2. `(BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE` is a sufficient condition to ensure the overflow. > > > Thus, there remain only the cases when ` Long.SIZE < BigInteger.bitLengthForLong(x) * n && (BigInteger.bitLengthForLong(x) - 1L) * n + 1L <= Long.SIZE`, in this cases checked multiplications in the loop are needed. > > Moreover, `BigInteger.bitLengthForLong(x) - 1L` is a `long`, so the product does not overflow, so the condition at point 1 never overflows if it is evaluated only if the condition at point 2 is false. @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`. Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071920476 From darcy at openjdk.org Fri May 2 17:21:50 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 May 2025 17:21:50 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:54:59 GMT, Chen Liang wrote: > I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071921145 From rriggs at openjdk.org Fri May 2 17:24:06 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 17:24:06 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v3] In-Reply-To: References: Message-ID: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Optimize StringUTF16.putCharsAt a bit. Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/f5003244..d2261cd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=01-02 Stats: 15 lines in 2 files changed: 0 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From duke at openjdk.org Fri May 2 17:30:48 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 17:30:48 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:18:36 GMT, Raffaello Giulietti wrote: > Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything. It serves to skip the checks in the loop if in the common cases the length of the results are way more little with respect to `Long.SIZE` and to fail fast if in the common cases the length of the results are way more bigger than `Long.SIZE`. > @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`. If the condition at point 1 is evaluated only if the condition at point 2 is false, then it can never overflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071929231 From duke at openjdk.org Fri May 2 17:33:50 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 17:33:50 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com> References: <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com> Message-ID: On Fri, 2 May 2025 16:53:39 GMT, Raffaello Giulietti wrote: > As for the `bitLength` check, the product might overflow. Further, `bitLength` might not be that cheap. The current implementations of `bitLength()` calls `numberOfLeadingZeros`, which are: public static int numberOfLeadingZeros(long i) { int x = (int)(i >>> 32); return x == 0 ? 32 + Integer.numberOfLeadingZeros((int)i) : Integer.numberOfLeadingZeros(x); } public static int numberOfLeadingZeros(int i) { // HD, Count leading 0's if (i <= 0) return i == 0 ? 32 : 0; int n = 31; if (i >= 1 << 16) { n -= 16; i >>>= 16; } if (i >= 1 << 8) { n -= 8; i >>>= 8; } if (i >= 1 << 4) { n -= 4; i >>>= 4; } if (i >= 1 << 2) { n -= 2; i >>>= 2; } return n - (i >>> 1); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071934498 From rriggs at openjdk.org Fri May 2 17:35:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 17:35:53 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 03:49:39 GMT, Shaojin Wen wrote: >> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string. >> >> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 > > # Conflicts: > # src/java.base/share/classes/java/lang/AbstractStringBuilder.java > - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 > > # Conflicts: > # src/java.base/share/classes/java/lang/StringUTF16.java > - putCharsUnchecked > - copyright > - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[]) > - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[]) > - add append(char[]) benchmark Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/lang/StringUTF16.java line 1322: > 1320: val, > 1321: Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1), > 1322: ((long) (end - off)) << 1); This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is. ------------- PR Review: https://git.openjdk.org/jdk/pull/24773#pullrequestreview-2812557629 PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2071937012 From mcimadamore at openjdk.org Fri May 2 17:36:57 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 May 2025 17:36:57 GMT Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls [v8] In-Reply-To: <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com> References: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com> <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com> Message-ID: On Fri, 2 May 2025 14:12:42 GMT, Per Minborg wrote: > The performance before this PR can be seen in the "confined" benchmarks above. In those benchmarks, a regular `Arena.ofConfined` is created upon every invocation. Yes - but I was referring to the performance of the native call -- not that of the allocation per se (e.g. `CallOverheadByValue`). If I'm not mistaken the numbers of that benchmark all refer to new code (well, except when we pass by pointer, in which case there's no allocation -- both before and after this PR). E.g. it would be useful to also see how the by-value call has improved before/after this PR, in addition to looking at the difference between byValue/byRef in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847747932 From rriggs at openjdk.org Fri May 2 17:37:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 17:37:54 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 03:55:24 GMT, Shaojin Wen wrote: >> The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance. > > 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 'upstream/master' into allocate_un_init_202501 > > # Conflicts: > # src/java.base/share/classes/java/lang/Integer.java > # src/java.base/share/classes/java/lang/Long.java > - use StringConcatHelper.newArray > - simplify > - use Unsafe.allocateUninitializedArray > - revert StringConcatHelper newArray change > - copyright > - remove duplicate check > - allocateUninitializedArray The StringConcatHelper methods should not be used outside of StringConcat. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23353#pullrequestreview-2812563398 From jlu at openjdk.org Fri May 2 17:39:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 May 2025 17:39:08 GMT Subject: RFR: 8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out [v2] In-Reply-To: References: Message-ID: > Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`. > > This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster. > > Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Naoto review - update comment, isEmpty() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25009/files - new: https://git.openjdk.org/jdk/pull/25009/files/c3e77cde..579c1ebe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25009&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25009&range=00-01 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25009.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25009/head:pull/25009 PR: https://git.openjdk.org/jdk/pull/25009 From duke at openjdk.org Fri May 2 17:41:57 2025 From: duke at openjdk.org (Christoph) Date: Fri, 2 May 2025 17:41:57 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. When supplying mac sign to building the image, it does not work either and then applying. The current branch is here in this PR https://github.com/JabRef/jabref/pull/13032/ And now I remember that probably this was the initial reason for using the original approach mentioned earlier with specifcying the app content "severity": "error", "code": null, "path": "JabRef-6.0_arm64.dmg/JabRef.app/Contents/MacOS/JabRef", "message": "The signature of the binary is invalid.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735", "architecture": "arm64" } ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847757982 From jiangli at openjdk.org Fri May 2 17:43:37 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 2 May 2025 17:43:37 GMT Subject: RFR: 8356050: Problemlist jdk, langtools & lib-test tier1 tests requiring runtime usages of /bin/tools for static-jdk [v2] In-Reply-To: References: Message-ID: > Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of /bin/tools, for testing on static-jdk. The affected tests using following tools at runtime: > > - javac > - javadoc > - jar > - jarsigner > - jcmd > - jimage > - jps > > The latest teir1 testing results on static-jdk: https://github.com/jianglizhou/jdk/actions/runs/14781658116/job/41503569932. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Problemlist jdk/test/lib/hprof/HprofTest. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24995/files - new: https://git.openjdk.org/jdk/pull/24995/files/8954219a..982a6cfc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24995&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24995&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24995/head:pull/24995 PR: https://git.openjdk.org/jdk/pull/24995 From rriggs at openjdk.org Fri May 2 17:45:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 17:45:46 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> Message-ID: On Thu, 1 May 2025 21:58:18 GMT, Oleksii Sylichenko wrote: >> Is `echo.` shorthand for `echo.exe`; if so, please change to the long form to make it clearer the echo program is being run. > > No, `echo.` is not an executable, this is a command of the Windows Command Processor. > > See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo That sounds brittle. The "echo." usage is not specified, only shown as an example. Under what command parsing rule does it run exactly the "echo" builtin? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2071947579 From asemenyuk at openjdk.org Fri May 2 17:46:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 2 May 2025 17:46:53 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: <1ziGVo3kRSjV25DaqA9w4wPyFJYndFyxzxRhtguOhFE=.45e09cd7-7645-4a76-91a5-cc9e7f5a1c15@github.com> On Fri, 2 May 2025 17:39:16 GMT, Christoph wrote: > And now I remember that probably this was the initial reason for using the original approach mentioned earlier with specifcying the app content This means the two-stage packaging with signing is completely broken in jpackage. Not good. Can you share jpackage logs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847767094 From darcy at openjdk.org Fri May 2 17:46:58 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 May 2025 17:46:58 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com> References: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com> Message-ID: On Fri, 2 May 2025 16:55:49 GMT, Chen Liang wrote: > May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates? I know it is possible to write getSupportedSourceVersion to return the latest version, but I don't think it is appropriate for this annotation processor to use that idiom since it might actually need to be meaningfully updated with code changes to support the new source level. Explicitly needing to change this annotation is a backstop reminder to do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071949205 From swen at openjdk.org Fri May 2 17:51:49 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 17:51:49 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:24:06 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Optimize StringUTF16.putCharsAt a bit. > Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1970: > 1968: private static byte[] appendChars(byte[] value, byte coder, int count, char[] s, int off, int end) { > 1969: if (isLatin1(coder)) { > 1970: for (int i = off, j = count; i < end; i++) { Suggestion: int compressed = StringUTF16.compress(s, off, value, count, end - off); for (int i = compressed + off, j = count + compressed; i < end; i++) { Refer to PR #24773, adding StringUTF16.compress preprocessing here will improve the performance of java.io.BufferedReader::readLine method. Should it be done at once or separately for PR #24773 to make changes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2071954862 From rgiulietti at openjdk.org Fri May 2 17:52:44 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 17:52:44 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com> Message-ID: On Fri, 2 May 2025 17:30:55 GMT, fabioromano1 wrote: >> Again, I don't think that `n == 1` is a frequent case which would make any practical difference. >> >> As for the `bitLength` check, the product might overflow. >> Further, `bitLength` might not be that cheap. >> Finally, the test would just help to _fail_ faster at the expense of making the successful runs slightly slower. > >> As for the `bitLength` check, the product might overflow. Further, `bitLength` might not be that cheap. > > The current implementations of `bitLength()` call `numberOfLeadingZeros()`, which are: > > public static int numberOfLeadingZeros(long i) { > int x = (int)(i >>> 32); > return x == 0 ? 32 + Integer.numberOfLeadingZeros((int)i) > : Integer.numberOfLeadingZeros(x); > } > > public static int numberOfLeadingZeros(int i) { > // HD, Count leading 0's > if (i <= 0) > return i == 0 ? 32 : 0; > int n = 31; > if (i >= 1 << 16) { n -= 16; i >>>= 16; } > if (i >= 1 << 8) { n -= 8; i >>>= 8; } > if (i >= 1 << 4) { n -= 4; i >>>= 4; } > if (i >= 1 << 2) { n -= 2; i >>>= 2; } > return n - (i >>> 1); > } Yes, I'm familiar with both this Java code and the intrinsic code. Compare this with the much simpler proposed code. The checked multiplication `unsignedMultiplyExact` apparently performs two 64x64->64 multiplications, but on some architectures it might end up in a single 64x64->128 multiplication and one check. So the proposed code performs 6 such multiplications if the method returns + 5 ordinary multiplications in the worst case. As a general rule, the simpler the code, the better the outcome of the optimizing compiler. Again, to me there's no point in failing fast at the expense of the successful case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071955574 From rgiulietti at openjdk.org Fri May 2 17:57:48 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 May 2025 17:57:48 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:26:21 GMT, fabioromano1 wrote: >> @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`. >> >> Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything. > >> Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything. > > It serves to skip the checks in the loop if in the common cases the length of the results are way more little with respect to `Long.SIZE` and to fail fast if in the common cases the length of the results are way bigger than `Long.SIZE`. > >> @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`. > > If the condition at point 1 is evaluated only if the condition at point 2 is false, then it can never overflow. If that check would be a couple of instructions or so, then I could agree. True, there are no overflows in the checks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071959063 From duke at openjdk.org Fri May 2 17:57:47 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 17:57:47 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: <9ACW3UJDsgcJh02OftWGSeFNa5dbZVtG5NRVSuk5QnQ=.5119a855-507e-4d8a-a069-6b927a9a049e@github.com> References: <9ACW3UJDsgcJh02OftWGSeFNa5dbZVtG5NRVSuk5QnQ=.5119a855-507e-4d8a-a069-6b927a9a049e@github.com> Message-ID: On Fri, 2 May 2025 16:57:43 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/Math.java line 3500: >> >>> 3498: return (n & 0b1) == 0 ? 1 : -1; >>> 3499: } >>> 3500: >> >> Suggestion: >> >> >> if (x == 2) { >> if (n >= Integer.SIZE - 1) >> throw new ArithmeticException("integer overflow"); >> return 1 << n; >> } >> if (x == -2) { >> if (n >= Integer.SIZE) >> throw new ArithmeticException("integer overflow"); >> // if n == Integer.SIZE - 1, result is correct >> return (n & 0b1) == 0 ? 1 << n : -(1 << n); >> } >> >> if ((java.math.BigInteger.bitLengthForInt(Math.abs(x)) - 1L) * n + 1L > Integer.SIZE) { >> throw new ArithmeticException("integer overflow"); >> } >> >> With also a check for the condition `java.math.BigInteger.bitLengthForInt(Math.abs(x)) * n < Integer.SIZE`, when it is true the path could be led to a loop that skips the checks. > > return (n & 0b1) == 0 ? 1 << n : -(1 << n); > > > Equivalent to > > > > return ((1 << n) ^ -(n & 1)) + (n & 1); > > > Without branches it should be faster > ```java > return ((1 << n) ^ -(n & 1)) + (n & 1); > ``` It should have a comment that explains that this does the two's complement if `n` is odd, and it does nothing otherwise. Anyway, probably the optimization for `x == -2` will not be included. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071960548 From swen at openjdk.org Fri May 2 17:58:48 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 17:58:48 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:35:38 GMT, Roger Riggs wrote: > The StringConcatHelper methods should not be used outside of StringConcat. I had a version that used UNSAFE.allocateUninitializedArray , but @liach suggested using StringConcatHelper.newArray ------------- PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2847787404 From duke at openjdk.org Fri May 2 18:04:55 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 2 May 2025 18:04:55 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:53:12 GMT, Raffaello Giulietti wrote: >>> Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything. >> >> It serves to skip the checks in the loop if in the common cases the length of the results are way more little with respect to `Long.SIZE` and to fail fast if in the common cases the length of the results are way bigger than `Long.SIZE`. >> >>> @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`. >> >> If the condition at point 1 is evaluated only if the condition at point 2 is false, then it can never overflow. > > If that check would be a couple of instructions or so, then I could agree. > > True, there are no overflows in the checks. @rgiulietti If you think that this checks might be useful, the choice is yours. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071969275 From liach at openjdk.org Fri May 2 18:05:52 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 18:05:52 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 03:55:24 GMT, Shaojin Wen wrote: >> The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance. > > 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 'upstream/master' into allocate_un_init_202501 > > # Conflicts: > # src/java.base/share/classes/java/lang/Integer.java > # src/java.base/share/classes/java/lang/Long.java > - use StringConcatHelper.newArray > - simplify > - use Unsafe.allocateUninitializedArray > - revert StringConcatHelper newArray change > - copyright > - remove duplicate check > - allocateUninitializedArray src/java.base/share/classes/java/lang/Integer.java line 439: > 437: return new String(buf, LATIN1); > 438: } else { > 439: byte[] buf = StringConcatHelper.newArray(size << 1); @RogerRiggs I recommended StringConcatHelper because that was used in StringLatin1. For StringUTF16, it has its own newBytesFor: Suggestion: byte[] buf = StringUTF16.newBytesFor(size); Or we can factor out a `StringLatin1.newBytesFor` too and encapsulate `newArray` usage. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23353#discussion_r2071969862 From duke at openjdk.org Fri May 2 18:09:58 2025 From: duke at openjdk.org (Christoph) Date: Fri, 2 May 2025 18:09:58 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. >From the GitHub actions run with double signing: (mac os 14 runner) jpackage Log starts at `Creating app package: JabRef.app` [signed_image_signed_dmg_macOS (ARM64) installer and portable version.txt](https://github.com/user-attachments/files/20016626/signed_image_signed_dmg_macOS.ARM64.installer.and.portable.version.txt) Run with only signing the pkg/dmg: [only signing dmg_macOS (ARM64) installer and portable version.txt](https://github.com/user-attachments/files/20016647/only.signing.dmg_macOS.ARM64.installer.and.portable.version.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847804315 From swen at openjdk.org Fri May 2 18:14:45 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 18:14:45 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:32:41 GMT, Roger Riggs wrote: > This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is. The core library also uses Unsafe.copyMemory in many places. Can it be used in this scenario? Or can we find other ways to copy char[] to byte[]? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2071979599 From swen at openjdk.org Fri May 2 18:17:51 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 18:17:51 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:02:57 GMT, Chen Liang 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 eight commits: >> >> - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501 >> >> # Conflicts: >> # src/java.base/share/classes/java/lang/Integer.java >> # src/java.base/share/classes/java/lang/Long.java >> - use StringConcatHelper.newArray >> - simplify >> - use Unsafe.allocateUninitializedArray >> - revert StringConcatHelper newArray change >> - copyright >> - remove duplicate check >> - allocateUninitializedArray > > src/java.base/share/classes/java/lang/Integer.java line 439: > >> 437: return new String(buf, LATIN1); >> 438: } else { >> 439: byte[] buf = StringConcatHelper.newArray(size << 1); > > @RogerRiggs I recommended StringConcatHelper because that was used in StringLatin1. > > For StringUTF16, it has its own newBytesFor: > Suggestion: > > byte[] buf = StringUTF16.newBytesFor(size); > > Or we can factor out a `StringLatin1.newBytesFor` too and encapsulate `newArray` usage. public static byte[] newBytesFor(int len) { return new byte[newBytesLength(len)]; } StringUTF16.newBytesFor uses new byte[], which is not the purpose of this PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23353#discussion_r2071982990 From bpb at openjdk.org Fri May 2 18:19:35 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 May 2025 18:19:35 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24977/files - new: https://git.openjdk.org/jdk/pull/24977/files/efca3cf4..0fef4782 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=01-02 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977 PR: https://git.openjdk.org/jdk/pull/24977 From smarks at openjdk.org Fri May 2 18:31:31 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 2 May 2025 18:31:31 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe Message-ID: Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: - overrides and adds locking to SequencedCollection methods; - performs instance management of reversed synchronized views; - adds test for race conditions and functional tests of synchronized wrappers. ------------- Commit messages: - moar comments - Various tweaks. - fix for synch list - fix copyright line - tests for synch list Changes: https://git.openjdk.org/jdk/pull/24990/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351230 Stats: 227 lines in 3 files changed: 214 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24990.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24990/head:pull/24990 PR: https://git.openjdk.org/jdk/pull/24990 From weijun at openjdk.org Fri May 2 18:31:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 2 May 2025 18:31:52 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:50:41 GMT, Sean Mullan wrote: >> Weijun Wang 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 >> - add a positive debug log and update exception message >> - enhancing exception messages and debug outputs >> - update @since tags as required by JEP 12 >> - add enum back >> - the change > > src/java.base/share/classes/javax/crypto/KDF.java line 491: > >> 489: + "using the supplied derivation " >> 490: + "inputs, using the " + source + " " >> 491: + theOne.provider().getName() > > Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider." The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071997676 From mullan at openjdk.org Fri May 2 18:39:47 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 May 2025 18:39:47 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:29:14 GMT, Weijun Wang wrote: >> src/java.base/share/classes/javax/crypto/KDF.java line 491: >> >>> 489: + "using the supplied derivation " >>> 490: + "inputs, using the " + source + " " >>> 491: + theOne.provider().getName() >> >> Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider." > > The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`? Yes, good to make it consistent. I think it reads slightly better if the name of the provider comes before "provider". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2072005947 From naoto at openjdk.org Fri May 2 18:42:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 May 2025 18:42:45 GMT Subject: RFR: 8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:39:08 GMT, Justin Lu wrote: >> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`. >> >> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster. >> >> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Naoto review - update comment, isEmpty() LGTM. Thanks for simplifying the test ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25009#pullrequestreview-2812676717 From weijun at openjdk.org Fri May 2 18:49:34 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 2 May 2025 18:49:34 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: > Finalize the KDF API. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: fine tuning debug log and exception message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24520/files - new: https://git.openjdk.org/jdk/pull/24520/files/323b046b..f44dc9bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=04-05 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From smarks at openjdk.org Fri May 2 19:03:53 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 2 May 2025 19:03:53 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Thu, 1 May 2025 19:19:32 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/io/Reader.java line 408: >> >>> 406: *

This method works as if invoking it were equivalent to evaluating >>> 407: * the expression: >>> 408: *

{@linkplain #readAllChars()}.lines().toList()
>> >> I think this is actually too specific, as it could imply the returned List is the exact implementation that is returned by Stream.toList(). It is in this implementation, but I could easily imagine another implementation that constructs the list a different way. It might be better to be descriptive here and say that the entire input is read and is split into lines (where "line" is defined as above) which are returned in an unmodifiable list. And then have "unmodifiable list" be a link to the Unmodifiable Lists section, something like "java/util/List.html#unmodifiable". > > The word 'equivalent' mitigates the exactness of the code to describe the expected result. I think it's still ambiguous. There was a back-and-forth a while ago -- I think @bplb was involved -- where there was similar wording about something being "equivalent to" or "as if" foo() was called, and the person was insistent that this meant that foo() should actually be called (and it was a bug that foo() was not called). A possible rewording that might tip the balance is to change "works as if" (which implies implementation) to "the result is as if" (which emphasizes the result and less how it was arrived at). But I'd still recommend avoiding using code as a specification, especially if the code involves a publicly overridable method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072031354 From swen at openjdk.org Fri May 2 19:09:48 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 2 May 2025 19:09:48 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: <-ljVhLq1eqiX7jZaQ_k4IBTLAu1iDbrTLljF8_wdq2Y=.300f3c0d-58a1-40af-9e21-e31afa1ade12@github.com> On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test src/java.base/share/classes/java/util/zip/ZipFile.java line 1240: > 1238: entries[index] = hash; > 1239: entries[index + 1] = next; > 1240: entries[index + 2] = pos; Suggestion: entries[index ] = hash; entries[index + 1] = next; entries[index + 2] = pos; Aligned code is more readable ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2072037453 From liach at openjdk.org Fri May 2 19:19:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 19:19:55 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 Message-ID: Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. Testing: riscv64 cross build ------------- Commit messages: - 8355962: RISCV64 cross build fails after 8354996 Changes: https://git.openjdk.org/jdk/pull/25013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355962 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25013/head:pull/25013 PR: https://git.openjdk.org/jdk/pull/25013 From archie.cobbs at gmail.com Fri May 2 19:23:25 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Fri, 2 May 2025 14:23:25 -0500 Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Fri, May 2, 2025 at 2:04?PM Stuart Marks wrote: > There was a back-and-forth a while ago -- I think @bplb was involved -- > where there was similar wording about something being "equivalent to" or > "as if" foo() was called, and the person was insistent that this meant that > foo() should actually be called (and it was a bug that foo() was not > called). > For those who enjoy rehashing the past, here it is :) https://bugs.openjdk.org/browse/JDK-8307863 -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Fri May 2 19:31:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 2 May 2025 19:31:54 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. It looks like jpackage sign bundles in a way that they can not be notarized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847948330 From vromero at openjdk.org Fri May 2 19:32:32 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 May 2025 19:32:32 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v2] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updating test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/5e3acc92..1134ffee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From asemenyuk at openjdk.org Fri May 2 19:34:59 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 2 May 2025 19:34:59 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 22:30:06 GMT, Alexander Matveev wrote: >> - It is not clear on which macOS versions codesign fails if application bundle contains additional content. >> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. >> - This change is for macOS only. >> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. > > Closing this PR. This issue will be fixed under new PR https://github.com/openjdk/jdk/pull/21741. @sashamatveev can you comment? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847954657 From forax at openjdk.org Fri May 2 19:40:49 2025 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 2 May 2025 19:40:49 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <5e91fwQ-fvxomq2pltkLuT0EeVaJPH_L4ibc4u6O91c=.03f7a833-0dd2-4427-ab88-b1b88daa4d2a@github.com> On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test test/jdk/java/io/BufferedReader/ReadAll.java line 82: > 80: @AfterAll > 81: public static void cleanup() throws IOException { > 82: file.delete(); If the call to createTempFile() above fails with an exception, file will be null ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072068586 From vromero at openjdk.org Fri May 2 19:41:34 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 May 2025 19:41:34 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v3] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into JDK-8354556 - updating test - final adjustments - additional refactorings - removing unneeded changes - more refactorings - more refactorings and tests - refactoring - refactoring - covering more cases plus refactoring in order to simplify the code - ... and 13 more: https://git.openjdk.org/jdk/compare/60ba81d7...151908a2 ------------- Changes: https://git.openjdk.org/jdk/pull/24746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=02 Stats: 494 lines in 25 files changed: 468 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Fri May 2 19:44:31 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 May 2025 19:44:31 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v4] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: changes to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/151908a2..60f1f53b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From erikj at openjdk.org Fri May 2 19:54:44 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 May 2025 19:54:44 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25013#pullrequestreview-2812795358 From bpb at openjdk.org Fri May 2 20:39:45 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 May 2025 20:39:45 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: <1grEUdKcCxBPboSWy5obCUJJrdyJVX7diRJEEOMQqsk=.cce7b09c-336f-445b-abbc-694d46392d04@github.com> On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter wrote: >> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set I ran all tests in `open/test/jdk` and `HashedPasswordFileTest` was the only failure which did not appear to be spurious (there were four apparently spurious failures in `java/awt/print`). `HashedPasswordFileTest` was modified in 0fef478 and now passes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2848075890 From jlu at openjdk.org Fri May 2 20:55:54 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 May 2025 20:55:54 GMT Subject: RFR: 8356096: ISO 4217 Amendment 179 Update Message-ID: Please review this PR which implements ISO 4217 update 179. The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`). ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/25014/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25014&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356096 Stats: 11 lines in 4 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25014.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25014/head:pull/25014 PR: https://git.openjdk.org/jdk/pull/25014 From rriggs at openjdk.org Fri May 2 21:11:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 21:11:47 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> Message-ID: On Fri, 2 May 2025 17:42:40 GMT, Roger Riggs wrote: >> No, `echo.` is not an executable, this is a command of the Windows Command Processor. >> >> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo > > That sounds brittle. The "echo." usage is not specified, only shown as an example. > Under what command parsing rule does it run exactly the "echo" builtin? A bit more investigation and some trial and error. It appears that with `echo.`, cmd.com is searching for a file named "echo" and when it does not find it it reverts to the builtin. But it has already wasted time searching the %Path% for a non-existent file. A couple comments searching the internet suggested using either "/" or ":". Both are not part of file paths and are parsed differently. In my trial and error on Windows 10, I consistently get an error from `cmd /c echo.`, `'echo.' is not recognized as an internal or external command...` I'd propose to use `echo/` instead, the `/` will terminate the parsing of the command name and won't be interpreted as part of a file name and as an empty command option will be ignored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072151928 From liach at openjdk.org Fri May 2 21:34:46 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 21:34:46 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: <4Yq5q-QjlgK9ln9ICrwaQmH-_kwsbgz39_vi2eqP0pI=.85e4f24d-832f-4c90-af1f-28d90c805fa1@github.com> On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build If someone can verify this patch works - @caoman since you have tried to raise attention on this issue, can you test this patch for x86 to arm cross builds? Delegating integration as this seems in need. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25013#issuecomment-2848154785 From duke at openjdk.org Fri May 2 21:55:46 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Fri, 2 May 2025 21:55:46 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> Message-ID: On Fri, 2 May 2025 21:08:46 GMT, Roger Riggs wrote: >> That sounds brittle. The "echo." usage is not specified, only shown as an example. >> Under what command parsing rule does it run exactly the "echo" builtin? > > A bit more investigation and some trial and error. > It appears that with `echo.`, cmd.com is searching for a file named "echo" and when it does not find it it reverts to the builtin. But it has already wasted time searching the %Path% for a non-existent file. > A couple comments searching the internet suggested using either "/" or ":". Both are not part of file paths and are parsed differently. > In my trial and error on Windows 10, I consistently get an error from `cmd /c echo.`, > `'echo.' is not recognized as an internal or external command...` > > I'd propose to use `echo/` instead, the `/` will terminate the parsing of the command name and won't be interpreted as part of a file name and as an empty command option will be ignored. On the other hand, the test can be modified as follows: on Windows, pass an empty string as an argument to `echo` and expect two double quotes followed by a newline character as the valid result: String[] cmdp = Windows.is() ? new String[]{"cmd.exe", "/c", "echo", ""} : new String[]{"echo"}; String[] envp = {"Hello", "World"}; // Yuck! Process p = Runtime.getRuntime().exec(cmdp, envp); String expected = Windows.is() ? """\n" : "\n"; equal(commandOutput(p), expected); What do you prefer: the "echo/" variant or the "double quotes" variant? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072184014 From rriggs at openjdk.org Fri May 2 22:06:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 22:06:46 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> Message-ID: On Fri, 2 May 2025 21:52:46 GMT, Oleksii Sylichenko wrote: >> A bit more investigation and some trial and error. >> It appears that with `echo.`, cmd.com is searching for a file named "echo" and when it does not find it it reverts to the builtin. But it has already wasted time searching the %Path% for a non-existent file. >> A couple comments searching the internet suggested using either "/" or ":". Both are not part of file paths and are parsed differently. >> In my trial and error on Windows 10, I consistently get an error from `cmd /c echo.`, >> `'echo.' is not recognized as an internal or external command...` >> >> I'd propose to use `echo/` instead, the `/` will terminate the parsing of the command name and won't be interpreted as part of a file name and as an empty command option will be ignored. > > On the other hand, the test can be modified as follows: on Windows, pass an empty string as an argument to `echo` and expect two double quotes followed by a newline character as the valid result: > > > String[] cmdp = Windows.is() ? new String[]{"cmd.exe", "/c", "echo", ""} : new String[]{"echo"}; > String[] envp = {"Hello", "World"}; // Yuck! > Process p = Runtime.getRuntime().exec(cmdp, envp); > String expected = Windows.is() ? """\n" : "\n"; > equal(commandOutput(p), expected); > > > What do you prefer: the "echo/" variant or the "double quotes" variant? I'd use the 'echo/' version to keep the test simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072193051 From almatvee at openjdk.org Fri May 2 22:14:53 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 2 May 2025 22:14:53 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com> On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. Not sure what is going on. I tried generating app-image with signing modifying it and then generating DMG with --mac-sign and application image is signed correctly. I did not tried to notarize it. When DMG is mounted what is output of `codesign --display -vvvv /Volumes/JabRef-6.0_arm64.dmg/JabRef.app`? Also from provided logs: 2025-05-02T17:19:25.6911920Z /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app/Contents/runtime `buildres/mac/***.entitlements` -> "***" does not look right. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848202529 From duke at openjdk.org Fri May 2 22:31:00 2025 From: duke at openjdk.org (Mohamed Issa) Date: Fri, 2 May 2025 22:31:00 GMT Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v2] In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com> References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com> Message-ID: > The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. > > The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b15](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B15) as the baseline version. > > For performance data collected with the built in **cbrt** micro-benchmark, see the table below. Each result is the mean of 8 individual runs. Overall, the intrinsic provides a performance uplift of 41%. > > | Benchmark | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup | > | :----------------: | :----------------------------------: | :----------------------------------: | :---------: | > | MathBench.cbrt | 148242 | 209122 | 1.41x | > > Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes. Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'openjdk:master' into user/missa-prime/cbrt - Change coeff_table alignment from 4 bytes to 16 bytes to conform with movapd instruction - Merge branch 'master' into user/missa-prime/cbrt - x86_64 intrinsic for cbrt using libm ------------- Changes: https://git.openjdk.org/jdk/pull/24470/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=01 Stats: 466 lines in 26 files changed: 453 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24470.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24470/head:pull/24470 PR: https://git.openjdk.org/jdk/pull/24470 From asemenyuk at openjdk.org Fri May 2 22:34:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 2 May 2025 22:34:54 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com> References: <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com> Message-ID: On Fri, 2 May 2025 22:12:18 GMT, Alexander Matveev wrote: > "***" does not look right. This is just a mask to hide the real value. > I did not tried to notarize it. Well, the problem is with notarization. Signing in jpackage passed. But looks like it produces a bundle that can not be notarized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848222502 From manc at openjdk.org Fri May 2 22:36:49 2025 From: manc at openjdk.org (Man Cao) Date: Fri, 2 May 2025 22:36:49 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build Marked as reviewed by manc (Committer). Yes, I tested that this change fixes the failure for cross-compiling aarch64. ------------- PR Review: https://git.openjdk.org/jdk/pull/25013#pullrequestreview-2813005097 PR Comment: https://git.openjdk.org/jdk/pull/25013#issuecomment-2848222583 From liach at openjdk.org Fri May 2 22:36:50 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 22:36:50 GMT Subject: Integrated: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build This pull request has now been integrated. Changeset: 4d2d1298 Author: Chen Liang Committer: Man Cao URL: https://git.openjdk.org/jdk/commit/4d2d12987f8c1be64719a7d01276a789af245ee2 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod 8355962: RISCV64 cross build fails after 8354996 Reviewed-by: erikj, manc ------------- PR: https://git.openjdk.org/jdk/pull/25013 From mik3hall at gmail.com Fri May 2 22:52:00 2025 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 2 May 2025 17:52:00 -0500 Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com> Message-ID: <977460AD-488D-4455-9B0E-2ABBD2E2579A@gmail.com> > On May 2, 2025, at 5:34?PM, Alexey Semenyuk wrote: > > On Fri, 2 May 2025 22:12:18 GMT, Alexander Matveev wrote: > >> "***" does not look right. > > This is just a mask to hide the real value. > >> I did not tried to notarize it. > > Well, the problem is with notarization. Signing in jpackage passed. But looks like it produces a bundle that can not be notarized. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848222502 I had successfully notarized a jpackage app sometime back. As I remember it was a rather involved process where you had to be online to an Apple server? I still have it in the build for one application but offline it does always fail. This might be from when I did that https://developer.apple.com/forums/thread/124614 -------------- next part -------------- An HTML attachment was scrubbed... URL: From almatvee at openjdk.org Fri May 2 22:56:52 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 2 May 2025 22:56:52 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. It might be possible that "codesign --display -vvvv" does not check signature well enough as notarization. If I am reading issue correctly signed app-image is being generated, then it will be post-process and then it is used to generate DMG. See https://github.com/JabRef/jabref/pull/13032. In this case we will package app-image as is since we will assume it is signed. See [JDK-8293462](https://bugs.openjdk.org/browse/JDK-8293462). My suggestion is to generate unsigned image if post-processing is required or sign application image separately after it was modified. See [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848240659 From kbarrett at openjdk.org Sat May 3 00:38:47 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 3 May 2025 00:38:47 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v9] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 21:47:01 GMT, Brent Christian wrote: >> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures: >> >> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method >> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger` >> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded 'trappedCount' test/jdk/java/lang/ref/FinalizerHistogramTest.java line 78: > 76: refProResult = wb.waitForReferenceProcessing(); > 77: System.out.println("waitForReferenceProcessing returned: " + refProResult); > 78: } while (refProResult); Why the spammy output? Why not just while (wb.waitForReferenceProcessing()) {} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2072259958 From smarks at openjdk.org Sat May 3 01:02:19 2025 From: smarks at openjdk.org (Stuart Marks) Date: Sat, 3 May 2025 01:02:19 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test Archie Cobbs wrote: > For those who enjoy rehashing the past, here it is :) [JDK-8307863](https://bugs.openjdk.org/browse/JDK-8307863) Thanks for the pointer. I don't want to rehash the past, but looking at the previous discussion was informative. Holy cow that was two years ago already; I thought it was just a couple months ago. In any case, the effect I'm trying for here is to have the specification be able to use code or pseudo-code, which is sometimes the most intuitive way to specify something. Sometimes this _description_ involves another method (or methods) on the same class, but it doesn't want to _specify_ that the other method is actually called. The reason this is significant is that, if the other method is overridable by a subclass, the self-call is observable by the subclass and the subclass implementation can affect the behavior of this method. More concretely, suppose we have a method specification for the `foo()` method that is like this. (Intentionally vague wording). > This method behaves like `bar().length()`. ... where the `bar()` method on this class is overridable by a subclass. A reasonable person might think, ok, if I override `bar()` and change its behavior, then `foo()` will also be affected. Two questions are relevant here: 1. Do we want self-calls, or do we want to avoid self-calls? 2. What specification wording should be used to require self-calls or lack of self-calls? Note that I've omitted another option for 2 which is to leave it unspecified. Astute readers will note that leaving it unspecified eventually leads to the [fragile base class problem](https://en.wikipedia.org/wiki/Fragile_base_class). Java has suffered from this a fair amount over the years, and the way to avoid it is to be explicit in the specification about what self-calls are or are not made. That's a primary role of the `@implSpec` javadoc tag. (Sorry for lecturing here, but I want to make sure all readers are on the same page.) Here are my proposed answers to the questions. 1. In this case `Reader` is an abstract class, and therefore it relies on a subclass to provide _some_ implementation; so some self-calls are required. I observe that the only abstract methods on `Reader` are `close()` and `read(char[], int, int)`, and further that all the concrete methods are implemented in terms of this three-arg `read` method. Based on this, the new methods here should be implemented in terms of that three-arg `read` method, and also they should be specified to do so in an `@implSpec` clause. (In principle, the other concrete methods of `Reader` should also have `@implSpec` clauses that say they use the three-arg `read` method, but that can probably be handled separately.) 2. Since there will be specific self-calls, there needs to be an `@implSpec` that specifies that. I'd recommend something like this for `readAllChars()`: @implSpec The implementation in this class reads all the characters from the input by repeatedly calling the read(char[], int, int) method with a positive len argument until a call returns -1. There is still the matter of the wording to use for the non-self-call case, although that isn't operative here. Continuing the above example, I'd suggest something like "the result is as if `bar().length()` had been called." The use of the subjunctive mood hints reasonably strongly that `bar()` isn't _really_ called, though it is somewhat subtle. The JDK has used similar wording, sometimes "the effect is as if" but even "effect" is somewhat ambiguous, which is why I'm suggesting "result" here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2848332415 From liach at openjdk.org Sat May 3 01:08:17 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 3 May 2025 01:08:17 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v2] In-Reply-To: References: Message-ID: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com> > Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Don't need to update latestSupported later - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv - Add advanced testing for different latestSupported - 8355536: Create version constants to model preview language and vm features ------------- Changes: https://git.openjdk.org/jdk/pull/25017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=01 Stats: 1266 lines in 6 files changed: 1124 ins; 83 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/25017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017 PR: https://git.openjdk.org/jdk/pull/25017 From almatvee at openjdk.org Sat May 3 03:37:46 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 3 May 2025 03:37:46 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images In-Reply-To: References: Message-ID: <9lyJyHh_vUdTzUYNO4KVO-UHlEacl9B_8F76j8oCvMg=.4b7e9a1c-6bd3-49a6-915a-f8a19b510251@github.com> On Thu, 1 May 2025 21:23:38 GMT, Mikhail Yankelevich wrote: >> - Symbolic links will not be followed for `--app-content` on all platforms. >> - Added test to cover this case. >> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. > > test/jdk/tools/jpackage/share/AppContentTest.java line 57: > >> 55: */ >> 56: public class AppContentTest { >> 57: > > Nitpick: do you think it might be worth it to add a bug id to the `@test`? No. I do not see a need. This is a generic test and not something specific to particular JBS issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2072305435 From swen at openjdk.org Sat May 3 05:03:36 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 3 May 2025 05:03:36 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v4] In-Reply-To: References: Message-ID: > The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: use Unsafe::allocateUninitializedArray ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23353/files - new: https://git.openjdk.org/jdk/pull/23353/files/d6942080..549ff0f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=02-03 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23353/head:pull/23353 PR: https://git.openjdk.org/jdk/pull/23353 From duke at openjdk.org Sat May 3 07:27:49 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 3 May 2025 07:27:49 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com> On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test src/java.base/share/classes/java/io/Reader.java line 213: > 211: public String readAllChars() throws IOException { > 212: ensureOpen(); > 213: return cs.toString().substring(next); Your change implies creating a full-length string *first* (including cyoping and compression), just to strip it down to a smaller one *later*. It would be more efficient to *first* strip it down, and compression into a `String` *afterwards*. Imagine a huge `cs` with `next` being near to `length()`, and you see the difference in efficiency! ? `cs.subSequence(next, cs.length() - next).toString()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072340583 From duke at openjdk.org Sat May 3 08:34:53 2025 From: duke at openjdk.org (Christoph) Date: Sat, 3 May 2025 08:34:53 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. I managed to get it working now. 1. Build a signed app image with --mac-sign 2. Add the addtional content 3. re-sign the content manually with # Sign the final artifact codesign --force --deep --sign "Developer ID Application: JabRef e.V. (6792V39SK3)" \ --entitlements buildres/mac/jabref.entitlements \ --options runtime --timestamp build/distribution/JabRef.app 4. build a signed dmg/pkg 5. Notarization works now :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848520498 From duke at openjdk.org Sat May 3 09:17:49 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 3 May 2025 09:17:49 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <-wkmG1NP_OsBAU-a4HAJOLRM9KK8ccUxH02rlogXI8o=.3f30e760-fbc2-47c3-9e96-2de14781152c@github.com> On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test src/java.base/share/classes/java/io/Reader.java line 211: > 209: } > 210: > 211: public String readAllChars() throws IOException { The addition of this method effectively resolves [JDK-8309726](https://bugs.openjdk.org/browse/JDK-8309726), so I hope you don't mind me setting you as the assignee there, just to ensure we don't forget to close JDK-8309726 in turn once JDK-8354724 is closed? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072357390 From duke at openjdk.org Sat May 3 09:32:51 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 3 May 2025 09:32:51 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com> Message-ID: <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com> On Sat, 3 May 2025 07:25:09 GMT, Markus KARG wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test > > src/java.base/share/classes/java/io/Reader.java line 213: > >> 211: public String readAllChars() throws IOException { >> 212: ensureOpen(); >> 213: return cs.toString().substring(next); > > Your change implies creating a full-length string *first* (including cyoping and compression), just to strip it down to a smaller one *later*. It would be more efficient to *first* strip it down, and compression into a `String` *afterwards*. Imagine a huge `cs` with `next` being near to `length()`, and you see the difference in efficiency! ? > > `cs.subSequence(next, cs.length() - next).toString()` Oh, and we should set `next` afterwards, so the `Reader` knows that the end of the sequence is reached: public String readAllChars() throws IOException { ensureOpen(); var remainder = cs.subSequence(next, cs.length() - next); next = length(); return remainder.toString(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072359744 From duke at openjdk.org Sat May 3 09:37:48 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 3 May 2025 09:37:48 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test src/java.base/share/classes/java/io/Reader.java line 211: > 209: } > 210: > 211: public String readAllChars() throws IOException { Now that the method got renamed from `readString()` to `readAllChars()` I'd like to suggest that the return type should not be `String` anymore but `CharSequence`. This would open potential for more efficient implementations. For example, we can omit the final `.toString()` after `.subSequence()`, effectively preventing the *double* copy implied (the first copy already was created by `subSequence()`). *Iff* a caller essentially needs a `String` (for whatever reason), he can add a `.toString()` *in the calling code* easily. But unless that is the case, we should not *enforce* `String` for efficiency reasons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072360280 From duke at openjdk.org Sat May 3 11:46:03 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Sat, 3 May 2025 11:46:03 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v2] In-Reply-To: References: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com> Message-ID: On Fri, 2 May 2025 22:04:15 GMT, Roger Riggs wrote: >> On the other hand, the test can be modified as follows: on Windows, pass an empty string as an argument to `echo` and expect two double quotes followed by a newline character as the valid result: >> >> >> String[] cmdp = Windows.is() ? new String[]{"cmd.exe", "/c", "echo", ""} : new String[]{"echo"}; >> String[] envp = {"Hello", "World"}; // Yuck! >> Process p = Runtime.getRuntime().exec(cmdp, envp); >> String expected = Windows.is() ? """\n" : "\n"; >> equal(commandOutput(p), expected); >> >> >> What do you prefer: the "echo/" variant or the "double quotes" variant? > > I'd use the 'echo/' version to keep the test simpler. done: 61ab85f2cff6d35ba53f7538dcbca95e46d541cd ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072379429 From duke at openjdk.org Sat May 3 11:46:03 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Sat, 3 May 2025 11:46:03 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v2] In-Reply-To: References: Message-ID: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com> > This PR proposes three improvements to the `Basic.java` test: > > 1. Increase Timeout > - The current timeout is insufficient when running the test in IntelliJ IDEA. > - I propose increasing it by one minute. > - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. > > 2. Fix Incompatibility with Windows (Cygwin vs. Native) > - One of the tests executes the `echo` command. > - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). > - I propose replacing echo with `cmd /c echo.`, which produces the same output (a single newline) in Windows, ensuring compatibility. > > 3. Prevent Autorun Scripts in the `cmd /c set` Command > - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. > - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. > > These changes improve test reliability and ensure compatibility across different environments. > Testing: > - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. > - Confirmed that `cmd /c echo.` produces the expected output in Windows. > - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. > > # Detailed Description > > ## echo > The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) with envstrings without any `=' > //---------------------------------------------------------------- > > with following error: > > Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified > > > If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD). > > The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. > > See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo > > To ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c`, because Cygwin has its own executable `echo`. > > ## cmd.exe /c set > The following test fails in a Windows environment under specific conditi... Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision: 8353489: replace `echo.` with `echo/` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23933/files - new: https://git.openjdk.org/jdk/pull/23933/files/17109340..61ab85f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23933&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23933&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23933/head:pull/23933 PR: https://git.openjdk.org/jdk/pull/23933 From eirbjo at openjdk.org Sat May 3 12:22:45 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 3 May 2025 12:22:45 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v2] In-Reply-To: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com> References: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com> Message-ID: On Sat, 3 May 2025 11:46:03 GMT, Oleksii Sylichenko wrote: >> This PR proposes three improvements to the `Basic.java` test: >> >> 1. Increase Timeout >> - The current timeout is insufficient when running the test in IntelliJ IDEA. >> - I propose increasing it by one minute. >> - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. >> >> 2. Fix Incompatibility with Windows (Cygwin vs. Native) >> - One of the tests executes the `echo` command. >> - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). >> - I propose replacing echo with `cmd /c echo/`, which produces the same output (a single newline) in Windows, ensuring compatibility. >> >> 3. Prevent Autorun Scripts in the `cmd /c set` Command >> - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. >> - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. >> >> These changes improve test reliability and ensure compatibility across different environments. >> Testing: >> - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. >> - Confirmed that `cmd /c echo/` produces the expected output in Windows. >> - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. >> >> # Detailed Description >> >> ## echo >> The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): >> >> //---------------------------------------------------------------- >> // Test Runtime.exec(...envp...) with envstrings without any `=' >> //---------------------------------------------------------------- >> >> with following error: >> >> Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified >> >> >> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD). >> >> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues. >> >> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo >> >> To ensure that the `echo/` command is supported in Cygwin, we n... > > Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision: > > 8353489: replace `echo.` with `echo/` test/jdk/java/lang/ProcessBuilder/Basic.java line 1843: > 1841: //---------------------------------------------------------------- > 1842: try { > 1843: String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo/"} : new String[]{"echo"}; A future maintainer without intimate familiarity with Windows commands and syntax would probably appreciate a short comment explaining the command chosen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072384373 From duke at openjdk.org Sat May 3 12:46:46 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Sat, 3 May 2025 12:46:46 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v2] In-Reply-To: References: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com> Message-ID: On Sat, 3 May 2025 12:19:54 GMT, Eirik Bj?rsn?s wrote: >> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision: >> >> 8353489: replace `echo.` with `echo/` > > test/jdk/java/lang/ProcessBuilder/Basic.java line 1843: > >> 1841: //---------------------------------------------------------------- >> 1842: try { >> 1843: String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo/"} : new String[]{"echo"}; > > A future maintainer without intimate familiarity with Windows commands and syntax would probably appreciate a short comment explaining the command chosen. Would a comment with the following text be sufficient: In Windows CMD (`cmd.exe`), `echo/` outputs a newline (i.e., an empty line). Wrapping it with `cmd.exe /c` ensures compatibility in both native Windows and Cygwin environments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072388153 From eirbjo at openjdk.org Sat May 3 12:49:44 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 3 May 2025 12:49:44 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v2] In-Reply-To: References: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com> Message-ID: <05a4twZcz4u4KMieiir8xUxI60Q3zzysPvoZW1uk_H0=.622fa46b-84ff-41aa-b8d6-1b76898801ce@github.com> On Sat, 3 May 2025 12:44:08 GMT, Oleksii Sylichenko wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 1843: >> >>> 1841: //---------------------------------------------------------------- >>> 1842: try { >>> 1843: String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo/"} : new String[]{"echo"}; >> >> A future maintainer without intimate familiarity with Windows commands and syntax would probably appreciate a short comment explaining the command chosen. > > Would a comment with the following text be sufficient: > > In Windows CMD (`cmd.exe`), `echo/` outputs a newline (i.e., an empty line). > Wrapping it with `cmd.exe /c` ensures compatibility in both native Windows and Cygwin environments. Thanks, sounds fine to me! (Although I?m not an expert in the field, which is also why I thought a comment would be a nice addition here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072388535 From duke at openjdk.org Sat May 3 13:02:34 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Sat, 3 May 2025 13:02:34 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v3] In-Reply-To: References: Message-ID: > This PR proposes three improvements to the `Basic.java` test: > > 1. Increase Timeout > - The current timeout is insufficient when running the test in IntelliJ IDEA. > - I propose increasing it by one minute. > - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. > > 2. Fix Incompatibility with Windows (Cygwin vs. Native) > - One of the tests executes the `echo` command. > - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). > - I propose replacing echo with `cmd /c echo/`, which produces the same output (a single newline) in Windows, ensuring compatibility. > > 3. Prevent Autorun Scripts in the `cmd /c set` Command > - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. > - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. > > These changes improve test reliability and ensure compatibility across different environments. > Testing: > - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. > - Confirmed that `cmd /c echo/` produces the expected output in Windows. > - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. > > # Detailed Description > > ## echo > The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) with envstrings without any `=' > //---------------------------------------------------------------- > > with following error: > > Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified > > > If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD). > > The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues. > > See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo > > To ensure that the `echo/` command is supported in Cygwin, we need to invoke it via `cmd /c`, because Cygwin has its own executable "echo". > > ## cmd.e... Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision: 8353489: add comment about `echo/`; `cmd` -> `cmd.exe` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23933/files - new: https://git.openjdk.org/jdk/pull/23933/files/61ab85f2..90752f18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23933&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23933&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23933/head:pull/23933 PR: https://git.openjdk.org/jdk/pull/23933 From duke at openjdk.org Sat May 3 13:02:34 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Sat, 3 May 2025 13:02:34 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v2] In-Reply-To: <05a4twZcz4u4KMieiir8xUxI60Q3zzysPvoZW1uk_H0=.622fa46b-84ff-41aa-b8d6-1b76898801ce@github.com> References: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com> <05a4twZcz4u4KMieiir8xUxI60Q3zzysPvoZW1uk_H0=.622fa46b-84ff-41aa-b8d6-1b76898801ce@github.com> Message-ID: <2pTS3qae2y9KNS7zbpXkR8mmdbY7EMiAck5-tc4phA4=.64d21d4f-cab0-488c-a8f6-2728b8479ec0@github.com> On Sat, 3 May 2025 12:46:55 GMT, Eirik Bj?rsn?s wrote: >> Would a comment with the following text be sufficient: >> >> In Windows CMD (`cmd.exe`), `echo/` outputs a newline (i.e., an empty line). >> Wrapping it with `cmd.exe /c` ensures compatibility in both native Windows and Cygwin environments. > > Thanks, sounds fine to me! (Although I?m not an expert in the field, which is also why I thought a comment would be a nice addition here) done: 90752f181b1d8326c854bc06e2108a3751fa225e ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072390824 From mik3hall at gmail.com Sat May 3 15:10:46 2025 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 May 2025 10:10:46 -0500 Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: <90FE32DF-9C77-466C-A95C-5C96DE44083C@gmail.com> > 3. re-sign the content manually with > > # Sign the final artifact > codesign --force --deep --sign "Developer ID Application: JabRef e.V. (6792V39SK3)" \ > --entitlements buildres/mac/jabref.entitlements \ > --options runtime --timestamp build/distribution/JabRef.app > Possibly I missed something if this was the fix. I don?t remember any issues with the existing signing when I tried notarization. I do see? --deep (DEPRECATED for signing as of macOS 13.0) When I man codesign. I?m also a little curious how you came up with the ?options runtime. I?m not familiar and even after looking at the man I?m not quite sure what it's purpose is. Make the requirements extra strict exempted by entitlements maybe? Also why you decided to use ?timestamp? I looked to see if jpackage uses any options like this but verbose output only shows codesign being invoked, many times, and not with what parameters. If this is sufficient, or required, for a valid, notarizable application, maybe jpackage could be simplified to just do an invocation like yours at the end rather than the numerous invocations it appears to do. From duke at openjdk.org Sat May 3 15:33:52 2025 From: duke at openjdk.org (Christoph) Date: Sat, 3 May 2025 15:33:52 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. Jpackage does include the options as well from the logs: 2025-05-02T17:19:25.6907840Z [17:19:12.379] Preparing Info.plist: /Users/runner/work/***/***/jabgui/build/distribution/JabRef.app/Contents/Info.plist. 2025-05-02T17:19:25.6908750Z [17:19:12.383] Using custom package resource [Application Info.plist] (loaded from Info.plist). 2025-05-02T17:19:25.6909590Z [17:19:12.388] Using custom package resource [Java Runtime Info.plist] (loaded from Runtime-Info.plist). 2025-05-02T17:19:25.6910240Z [17:19:23.350] Running /usr/bin/codesign 2025-05-02T17:19:25.6910740Z [17:19:24.530] Command [PID: 6752]: 2025-05-02T17:19:25.6911920Z /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app/Contents/runtime 2025-05-02T17:19:25.6912950Z [17:19:24.530] Output: 2025-05-02T17:19:25.6914200Z build/distribution/JabRef.app/Contents/runtime: replacing existing signature 2025-05-02T17:19:25.6915140Z build/distribution/JabRef.app/Contents/runtime: signed bundle with Mach-O thin (arm64) [com.oracle.java.JabRef] 2025-05-02T17:19:25.6915990Z [17:19:24.530] Returned: 0 2025-05-02T17:19:25.6916510Z [17:19:24.530] Running /usr/bin/codesign 2025-05-02T17:19:25.6917100Z [17:19:25.655] Command [PID: 6759]: 2025-05-02T17:19:25.6918000Z /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app 2025-05-02T17:19:25.6918880Z [17:19:25.656] Output: 2025-05-02T17:19:25.6919430Z build/distribution/JabRef.app: replacing existing signature 2025-05-02T17:19:25.6920230Z build/distribution/JabRef.app: signed app bundle with Mach-O thin (arm64) [org.***JabRef] 2025-05-02T17:19:25.6920880Z [17:19:25.656] Returned: 0 2025-05-02T17:19:25.6921160Z 2025-05-02T17:19:25.6921510Z [17:19:25.656] Succeeded in building Mac Application Image package 2025-05-02T17:19:36.0557030Z Warning: Support for per-user configuration of the installed application will not be supported due to missing "build/distribution/JabRef.app/Contents/app/.package" in predefined signed application image. After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff **Runtime** options is for Hardened Runtime https://developer.apple.com/documentation/security/hardened-runtime which allows specifying exclusions like jit in the entitlements **Timestamp** is also required https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Include-a-secure-timestamp Otherwise, notarization fails with no timestamp or invalid timestamp. **Deep** is like going recursively through the files. But should be avoided. I will try without as well To upload a macOS app to be notarized, you must enable the Hardened Runtime capability. For more information about notarization, see [Notarizing macOS software before distribution](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848675876 From mik3hall at gmail.com Sat May 3 15:49:58 2025 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 May 2025 10:49:58 -0500 Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: > On May 3, 2025, at 10:33?AM, Christoph wrote: > > On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > >> - It is not clear on which macOS versions codesign fails if application bundle contains additional content. >> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. >> - This change is for macOS only. >> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. > > Jpackage does include the options as well from the logs: Not for me with ${PACKAGER} \ --verbose \ --jlink-options '--strip-debug --no-man-pages --no-header-files' \ --input input \ --icon GenericApp.icns \ --resource-dir resources \ --name HalfPipe \ --type "dmg" \ --main-jar halfpipe.jar \ --main-class us.hall.hp.common.LoaderLaunchStub \ --module-path '/Users/mjh/Documents/javafx-jmods-21.0.1:mods' \ --add-modules javafx.swing,javafx.graphics,javafx.controls,us.hall.eio,org.openjdk.nashorn,java.compiler,java.desktop,java.logging,java.management,jdk.management.agent,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.jdeps,jdk.jcmd,jdk.zipfs,jdk.jfr \ --java-options '-Xmx1024m -XX:+UnlockDiagnosticVMOptions --add-opens java.desktop/javax.swing.text=ALL-UNNAMED --enable-preview -Djdk.attach.allowAttachSelf=true -XX:+UseG1GC -XX:MaxGCPauseMillis=50 --enable-native-access=ALL-UNNAMED -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports java.base/java.lang=ALL-UNNAMED --add-exports org.openjdk.nashorn/org.openjdk.nashorn.tools=ALL-UNNAMED -Dapp.path=$APPDIR -Djava.security.policy=$APPDIR/all.policy -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe -Dconsole=pane' \ --mac-package-identifier "us.hall.HalfPipe" \ --mac-sign \ --mac-signing-key-user-name "$SIGNING_CERT" \ --mac-entitlements "entitlements.xml" \ --mac-dmg-content additional/src.zip,additional/Half-Pipe.pdf All I see are the [10:05:03.044] Running /usr/bin/codesign > > > After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff > > > **Runtime** options is for Hardened Runtime https://developer.apple.com/documentation/security/hardened-runtime > which allows specifying exclusions like jit in the entitlements > > **Timestamp** is also required https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Include-a-secure-timestamp > > Otherwise, notarization fails with no timestamp or invalid timestamp. > > **Deep** is like going recursively through the files. But should be avoided. I will try without as well > > To upload a macOS app to be notarized, you must enable the Hardened Runtime capability. For more information about notarization, see [Notarizing macOS software before distribution](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution). Hardened runtime sounds sort of familiar, it?s been a while. Other requirements might of changed. From mik3hall at gmail.com Sat May 3 15:53:10 2025 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 May 2025 10:53:10 -0500 Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: <7832C240-075F-4051-819E-2981E4AFE3B2@gmail.com> > On May 3, 2025, at 10:49?AM, Michael Hall wrote: > > > >> On May 3, 2025, at 10:33?AM, Christoph wrote: >> >> On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: >> >>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content. >>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. >>> - This change is for macOS only. >>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. >> >> Jpackage does include the options as well from the logs: > > Not for me with > Sorry missed it. /usr/bin/codesign -s Developer ID Application: Michael Hall (5X6BXQB3Q7) -vvvv --timestamp --options runtime --prefix us.hall.hp.common. --entitlements entitlements.xml --force /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8582845157994500039/images/image-17727033358038913514/HalfPipe.app -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat May 3 16:09:45 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 3 May 2025 16:09:45 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen wrote: > > > ```java > > > > char[] ca = new char[end - off]; > > > ``` > > > Your code here has a memory allocation, which may cause slowdown > > > > This is exactly what I wanted to express with my posting. > > I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars. I have performed a JMH Benchmark to compare the code with and without the optimization, and the result is surprising: Benchmark | (SIZE) | Mode | Cnt | Score | ? | Error | Units 25 (modified) | 2 | thrpt | 25 | 71277668 | ? | 5549555 | ops/s 25 (modified) | 128 | thrpt | 25 | 33916527 | ? | 2631800 | ops/s 25 (modified) | 1024 | thrpt | 25 | 4291498 | ? | 401636 | ops/s 25 (modified) | 8192 | thrpt | 25 | 419871 | ? | 63557 | ops/s ? Benchmark | (SIZE) | Mode | Cnt | Score | ? | Error | Units 25 (original) | 2 | thrpt | 25 | 159882761 | ? | 2900397 | ops/s 25 (original) | 128 | thrpt | 25 | 24093787 | ? | 1706259 | ops/s 25 (original) | 1024 | thrpt | 25 | 3794393 | ? | 28097 | ops/s 25 (original) | 8192 | thrpt | 25 | 491340 | ? | 5569 | ops/s Actually for appended lengths of 128...1024 characters, the modified case is faster. This means, the benefit of `StringUTF16::compress` in fact outperforms the penalty implied by `new char[]`! While for size 1024 chars the benefit is rather small, for size 128 it is huge: More than 40% gain in throughput! ? I will repeat the benchmark with more steps in the range 2...1024 to see where the break-even-point is, so we effectively can enable the optimization in a performance-wise "safe" range. Stay tuned! ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2848689948 From mik3hall at gmail.com Sat May 3 16:19:54 2025 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 May 2025 11:19:54 -0500 Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: <8FBCA716-7B12-43A5-A631-CA541AD3B1AF@gmail.com> > On May 3, 2025, at 10:49?AM, Michael Hall wrote: > >> **Deep** is like going recursively through the files. But should be avoided. I will try without as well There was something in the man about behavior when using deep in combination with force. I?m not sure what eliminating one will do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat May 3 18:33:48 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 3 May 2025 18:33:48 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v4] In-Reply-To: References: Message-ID: On Sat, 3 May 2025 05:03:36 GMT, Shaojin Wen wrote: >> The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > use Unsafe::allocateUninitializedArray public static String toString(int i) { int size = DecimalDigits.stringSize(i); byte coder = COMPACT_STRINGS ? LATIN1 : UTF16; byte[] buf = (byte[]) Unsafe.getUnsafe().allocateUninitializedArray(byte.class, size << coder); if (coder == LATIN1) { DecimalDigits.getCharsLatin1(i, size, buf); } else { DecimalDigits.getCharsUTF16(i, size, buf); } return new String(buf, coder); } This implementation has a smaller code size and the same performance, but it changes the code structure, so I did not use it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2848749465 From zuniquex at protonmail.com Sat May 3 20:07:22 2025 From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=) Date: Sat, 03 May 2025 20:07:22 +0000 Subject: Documentation fix in MethodHandles.Lookup Message-ID: Hello, I've found a small documentation inconvenience in the MethodHandles.Lookup class documentation. In the Lookup Factory Methods table the field types of the member and bytecode definitions for lookup.findGetter diverge: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#L503-L504. I'd propose to change the bytecode entry to (FT) this.f;. I'm a new contributor and don't have access to the JBS yet. I'd be grateful, if anyone would like to sponsor me here. Cheers, Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Sat May 3 20:37:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 3 May 2025 20:37:54 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Sat, 3 May 2025 15:51:39 GMT, Michael Hall wrote: > After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff Right, if you modify the app image, you need to resign it. I'm glad you figured out a workaround. But ideally, you should be able to pass additional content to jpackage with `--app-content`, and it should produce a notarizable signed app image without extra steps on the user's side. Unfortunately, it doesn't. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848798298 From asemenyuk at openjdk.org Sat May 3 20:58:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 3 May 2025 20:58:50 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. So the takeaway from this fruitful discussion is: - jpackage doesn't produce helpful verbose signing output. Filed [JDK-8356116](https://bugs.openjdk.org/browse/JDK-8356116) - jpackage doesn't produce a notarizable app image if `--app-content` is used. Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848805427 From mik3hall at gmail.com Sat May 3 21:14:45 2025 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 May 2025 16:14:45 -0500 Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: <54576F35-E74D-4D8B-80F4-D1BCEF2F913E@gmail.com> > On May 3, 2025, at 3:58?PM, Alexey Semenyuk wrote: > > On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > >> - It is not clear on which macOS versions codesign fails if application bundle contains additional content. >> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. >> - This change is for macOS only. >> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. > > So the takeaway from this fruitful discussion is: > - jpackage doesn't produce helpful verbose signing output. Filed [JDK-8356116](https://bugs.openjdk.org/browse/JDK-8356116) I was mistaken on this. The codesign parameters appear to be shown once. Then there are many messages indicating just that codesign is being run. If the same parameters are always used indicating the parameters for each message probably isn?t needed. > - jpackage doesn't produce a notarizable app image if `--app-content` is used. Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117) > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848805427 I may of missed this as well. I thought the original poster indicated that changing the signing parameters somehow gave them a fix. If so, and doing it only once works, all the additional codesign?s that jpackage seems to do might not be necessary? Although if his fix depended on using ?deep that currently shows as deprecated in the man page. I would think that only executable content would need signing? ?app-content I don?t think adds anything for that. If it doesn?t break signing, and I see there is a SigningOptionsTest that appears to include it, I wouldn?t think it would break notarization either. But I don?t know. Other than testing some time back I don?t notarize. From duke at openjdk.org Sat May 3 21:14:57 2025 From: duke at openjdk.org (Christoph) Date: Sat, 3 May 2025 21:14:57 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Sat, 3 May 2025 20:56:00 GMT, Alexey Semenyuk wrote: > jpackage doesn't produce a notarizable app image if --app-content is used. Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117) Actually, this is a regression as it worked in JDK23 where we just used it recently https://github.com/JabRef/jabref/blob/6d0d78716893cc09577a957d111d62ba2dfbefd0/.github/workflows/deployment-arm64.yml#L115-L126 Just changing from 23 to 24 led to this error as reported by @koppor earlier in this thread https://github.com/openjdk/jdk/pull/21698#issuecomment-2838481133 The binaries of the release were successfully notarized both on macOS13 and macOS14 (About dialog of JabRef shows the jdk version used as well, 23.0.1) https://github.com/JabRef/jabref/releases/tag/v6.0-alpha2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848810724 From bchristi at openjdk.org Sun May 4 03:52:50 2025 From: bchristi at openjdk.org (Brent Christian) Date: Sun, 4 May 2025 03:52:50 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v9] In-Reply-To: References: Message-ID: On Sat, 3 May 2025 00:35:44 GMT, Kim Barrett wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unneeded 'trappedCount' > > test/jdk/java/lang/ref/FinalizerHistogramTest.java line 78: > >> 76: refProResult = wb.waitForReferenceProcessing(); >> 77: System.out.println("waitForReferenceProcessing returned: " + refProResult); >> 78: } while (refProResult); > > Why the spammy output? Why not just > > while (wb.waitForReferenceProcessing()) {} Right now, the test just it prints a single line: `waitForReferenceProcessing returned: false` and I expect this to continue to be true. For intermittently failing tests, I'm inclined to add a little extra output as long as I'm fiddling with it anyway. That way, if the test ever starts failing again, we have some (hopefully useful) clues about what happened. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2072512987 From kbarrett at openjdk.org Sun May 4 04:07:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 4 May 2025 04:07:59 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v9] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 21:47:01 GMT, Brent Christian wrote: >> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures: >> >> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method >> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger` >> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded 'trappedCount' Marked as reviewed by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24143#pullrequestreview-2813356236 From kbarrett at openjdk.org Sun May 4 04:07:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 4 May 2025 04:07:59 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v9] In-Reply-To: References: Message-ID: On Sun, 4 May 2025 03:49:44 GMT, Brent Christian wrote: > Right now, the test just it prints a single line: `waitForReferenceProcessing returned: false` and I expect this to continue to be true. If reference processing is being slow because of load, that will be different. > For intermittently failing tests, I'm inclined to add a little extra output as long as I'm fiddling with it anyway. That way, if the test ever starts failing again, we have some (hopefully useful) clues about what happened. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2072514833 From chen.l.liang at oracle.com Sun May 4 04:33:58 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sun, 4 May 2025 04:33:58 +0000 Subject: Documentation fix in MethodHandles.Lookup In-Reply-To: References: Message-ID: I have created https://bugs.openjdk.org/browse/JDK-8356119 for you. You can proceed to create a patch. ________________________________ From: core-libs-dev on behalf of Steffen Nie?ing Sent: Saturday, May 3, 2025 3:07 PM To: core-libs-dev at openjdk.org Subject: Documentation fix in MethodHandles.Lookup Hello, I've found a small documentation inconvenience in the MethodHandles.Lookup class documentation. In the Lookup Factory Methods table the field types of the member and bytecode definitions for lookup.findGetter diverge: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#L503-L504. I'd propose to change the bytecode entry to (FT) this.f;. I'm a new contributor and don't have access to the JBS yet. I'd be grateful, if anyone would like to sponsor me here. Cheers, Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Sun May 4 05:12:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 4 May 2025 05:12:00 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com> <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com> Message-ID: On Sat, 3 May 2025 09:30:17 GMT, Markus KARG wrote: >> src/java.base/share/classes/java/io/Reader.java line 213: >> >>> 211: public String readAllChars() throws IOException { >>> 212: ensureOpen(); >>> 213: return cs.toString().substring(next); >> >> Your change implies creating a full-length string *first* (including cyoping and compression), just to strip it down to a smaller one *later*. It would be more efficient to *first* strip it down, and compression into a `String` *afterwards*. Imagine a huge `cs` with `next` being near to `length()`, and you see the difference in efficiency! ? >> >> `cs.subSequence(next, cs.length()).toString()` >> >> (Edited my proposal to be more correct.) > > Oh, and we should set `next` afterwards, so the `Reader` knows that the end of the sequence is reached: > > > public String readAllChars() throws IOException { > ensureOpen(); > var len = cs.length(); > var remainder = cs.subSequence(next, len); > next = len; > return remainder.toString(); > } > > > (Edited my proposal to be a bit more concurrency-friendly and correct.) Probably best to ignore the implementation details as the discussions on what methods to expose, and where, is still going on. It was probably a bit premature to create the PR without getting agreement on the API first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072521725 From lucy at openjdk.org Sun May 4 12:30:45 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Sun, 4 May 2025 12:30:45 GMT Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float divisions by zero on AIX In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken wrote: > Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero. > At least this is the case on AIX. > > (seen in the jtreg test java/lang/Math/PowTests.java ) LGTM. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24963#pullrequestreview-2813453676 From lucy at openjdk.org Sun May 4 12:30:46 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Sun, 4 May 2025 12:30:46 GMT Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float divisions by zero on AIX In-Reply-To: References: Message-ID: On Fri, 2 May 2025 08:11:05 GMT, Matthias Baesken wrote: >> src/hotspot/share/sanitizers/ub.hpp line 39: >> >>> 37: #define ATTRIBUTE_NO_UBSAN __attribute__((no_sanitize("undefined","float-divide-by-zero"))) >>> 38: #endif >>> 39: #if defined(__GNUC__) && !defined(__clang__) >> >> Maybe use `#elif`? > > Or should I try to set it for BOTH clang and gcc so that the added checks are not needed any more? If you change it to #elif, then please do it in both files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24963#discussion_r2072605220 From duke at openjdk.org Sun May 4 14:02:45 2025 From: duke at openjdk.org (Markus KARG) Date: Sun, 4 May 2025 14:02:45 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG wrote: > This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. > > A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. @liach How to proceed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849236880 From liach at openjdk.org Sun May 4 14:51:44 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 14:51:44 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG wrote: > This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. > > A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. I will raise attention to this to other Oracle's JDK core library reviewers. Meanwhile you can start drafting a CSR like that for `getChars` for `CharSequence`. One concern is that (See `HashMap.newHashMap` vs `HashMap.of`) `XxxWriter.of(StringBuilder)` now returns a basic `Writer` instead of `XxxWriter`, but since we already have that for `Reader.of` and the argument type is specific, I think this is not an issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849260129 From liach at openjdk.org Sun May 4 14:57:51 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 14:57:51 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG wrote: > This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. > > A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. src/java.base/share/classes/java/nio/X-Buffer.java.template line 2: > 1: /* > 2: * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved. Redundant change. test/jdk/java/io/Writer/Of.java line 45: > 43: @Override > 44: public String toString() { > 45: return id; // allows to identify config when test case fails I used the same strategy in junit tests; the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072637744 PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072638134 From duke at openjdk.org Sun May 4 16:21:41 2025 From: duke at openjdk.org (Markus KARG) Date: Sun, 4 May 2025 16:21:41 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: > This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. > > A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. Markus KARG has updated the pull request incrementally with two additional commits since the last revision: - Undone copyright update of otherwise unchanged file. - Update Of.java Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise." ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24469/files - new: https://git.openjdk.org/jdk/pull/24469/files/75efb7fd..ea435ed1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24469&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24469&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24469.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24469/head:pull/24469 PR: https://git.openjdk.org/jdk/pull/24469 From duke at openjdk.org Sun May 4 16:21:42 2025 From: duke at openjdk.org (Markus KARG) Date: Sun, 4 May 2025 16:21:42 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sun, 4 May 2025 14:52:39 GMT, Chen Liang wrote: >> Markus KARG has updated the pull request incrementally with two additional commits since the last revision: >> >> - Undone copyright update of otherwise unchanged file. >> - Update Of.java >> >> Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise." > > src/java.base/share/classes/java/nio/X-Buffer.java.template line 2: > >> 1: /* >> 2: * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved. > > Redundant change. Good catch! Undone copyright update in https://github.com/openjdk/jdk/pull/24469/commits/ea435ed1090d8f028262f5900baf0a00472726d9. > test/jdk/java/io/Writer/Of.java line 45: > >> 43: @Override >> 44: public String toString() { >> 45: return id; // allows to identify config when test case fails > > I used the same strategy in junit tests; the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise. Understood. Removed override in https://github.com/openjdk/jdk/pull/24469/commits/f48b99995723b6c4dd73014015f50b1047ff28cd. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072655279 PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072654985 From duke at openjdk.org Sun May 4 16:49:21 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Sun, 4 May 2025 16:49:21 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter Message-ID: This PR fixes a typo in the bytecode cast for Lookup.findGetter. ------------- Commit messages: - 8356119: Correct field type for bytecode cast Changes: https://git.openjdk.org/jdk/pull/25024/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356119 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25024/head:pull/25024 PR: https://git.openjdk.org/jdk/pull/25024 From duke at openjdk.org Sun May 4 17:03:48 2025 From: duke at openjdk.org (Markus KARG) Date: Sun, 4 May 2025 17:03:48 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sun, 4 May 2025 14:49:35 GMT, Chen Liang wrote: > ...you can start drafting a CSR like that for `getChars` for `CharSequence`. Done. Kindly asking your review for the CSR: https://bugs.openjdk.org/browse/JDK-8356123. > One concern is that (See `HashMap.newHashMap` vs `HashMap.of`) `XxxWriter.of(StringBuilder)` now returns a basic `Writer` instead of `XxxWriter`, but since we already have that for `Reader.of` and the argument type is specific, I think this is not an issue. The CSR indicates that `Writer.of()` is the *symmetric* API to `Reader.of()`, so I think it is understood why we have chosen that name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849314924 From liach at openjdk.org Sun May 4 17:04:53 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 17:04:53 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter In-Reply-To: References: Message-ID: On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing wrote: > This PR fixes a typo in the bytecode cast for Lookup.findGetter. Thanks for the mailing list communication and reply. Check out https://openjdk.org/guide/ for more steps. For example, a patch should usually wait 24 hours for sufficient reviews. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25024#pullrequestreview-2813514938 From eirbjo at openjdk.org Sun May 4 17:22:47 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 May 2025 17:22:47 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter In-Reply-To: References: Message-ID: On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing wrote: > This PR fixes a typo in the bytecode cast for Lookup.findGetter. Nit: Would be nice if the PR title/description made it clear for the casual reader that this is a documentation/Javadoc typo, as opposed to a code issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2849324307 From eirbjo at openjdk.org Sun May 4 17:28:45 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 May 2025 17:28:45 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter In-Reply-To: References: Message-ID: On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing wrote: > This PR fixes a typo in the bytecode cast for Lookup.findGetter. Just a tip for a newcomer: (Welcome!) It may be useful to flag this PR as ?trivial? and ?documentation-only? by saying something like ?Please review this trivial, documentation-only PR which..? This gives reviewers some feeling of the size/complexity of the PR without actually digging into the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2849327311 From asemenyuk at openjdk.org Sun May 4 17:32:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sun, 4 May 2025 17:32:55 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 11:35:29 GMT, Oliver Kopp wrote: >> - It is not clear on which macOS versions codesign fails if application bundle contains additional content. >> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. >> - This change is for macOS only. >> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. > > Google directed me here. We updated from JDK23 to JDK24 > > We have > > --app-content buildres/mac/jabrefHost.py > > JDK23: Without any issue > > JDK24: > > > "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step. > [10:08:52.963] Running /usr/bin/xcrun > [10:08:52.973] Command [PID: 9939]: > /usr/bin/xcrun --help > [10:08:52.973] Output: > Usage: xcrun [options] ... arguments ... > > Find and execute the named command line tool from the active developer > directory. > > The active developer directory can be set using `xcode-select`, or via the > DEVELOPER_DIR environment variable. See the xcrun and xcode-select manual > pages for more information. > > Options: > -h, --help show this help message and exit > --version show the xcrun version > -v, --verbose show verbose logging output > --sdk find the tool for the given SDK name > --toolchain find the tool for the given toolchain > -l, --log show commands to be executed (with --run) > -f, --find only find and print the tool path > -r, --run find and execute the tool (the default behavior) > -n, --no-cache do not use the lookup cache > -k, --kill-cache invalidate all existing cache entries > --show-sdk-path show selected SDK install path > --show-sdk-version show selected SDK version > --show-sdk-build-version show selected SDK build version > --show-sdk-platform-path show selected SDK platform path > --show-sdk-platform-version show selected SDK platform version > [10:08:52.974] Returned: 0 > > Error: "codesign" failed with following output: > /var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: replacing existing signature > /var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: code object is not signed at all > In subcomponent: /private/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166... > Just changing from 23 to 24 led to this error as reported by @koppor earlier in this thread https://github.com/openjdk/jdk/pull/21698#issuecomment-2838481133 This looks like a regression, but it is not. You use `--app-content buildres/mac/jabrefHost.py`, which will add the "jabrefHost.py" file to the "Contents" directory of the app image. "jabrefHost.py" file should not be at this location, regardless of the version of jpackage. Explanation - https://github.com/openjdk/jdk/pull/21698#issuecomment-2838942773. It should be in the "Contents/Resources" directory instead, so the app content arguments should be `--app-content buildres/mac/Resources/jabrefHost.py`. Can you please try it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849329249 From asemenyuk at openjdk.org Sun May 4 17:35:57 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sun, 4 May 2025 17:35:57 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: <54576F35-E74D-4D8B-80F4-D1BCEF2F913E@gmail.com> References: <54576F35-E74D-4D8B-80F4-D1BCEF2F913E@gmail.com> Message-ID: On Sat, 3 May 2025 21:16:39 GMT, Michael Hall wrote: > If the same parameters are always used indicating the parameters for each message probably isn?t needed. The same parameters don't need to be logged, but having the complete list of files signed by jpackage in the log would be good. We don't have it now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849330544 From duke at openjdk.org Sun May 4 17:55:46 2025 From: duke at openjdk.org (Luca Kellermann) Date: Sun, 4 May 2025 17:55:46 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe In-Reply-To: References: Message-ID: On Thu, 1 May 2025 19:05:50 GMT, Stuart Marks wrote: > Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: > > - overrides and adds locking to SequencedCollection methods; > - performs instance management of reversed synchronized views; > - adds test for race conditions and functional tests of synchronized wrappers. src/java.base/share/classes/java/util/Collections.java line 2837: > 2835: return reversedView; > 2836: } > 2837: } `SynchronizedRandomAccessList` overrides `subList`, should it also override `reversed`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2072672563 From duke at openjdk.org Sun May 4 18:12:57 2025 From: duke at openjdk.org (Christoph) Date: Sun, 4 May 2025 18:12:57 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. Just tried it with putting the additional files into the Resources folder. Same error as originally reported. Run: https://github.com/JabRef/jabref/actions/runs/14823769155/job/41614205909 Changes from PR: https://github.com/JabRef/jabref/pull/13032/files#diff-5a17873aec4eae6b52b00959d8f9e17672912858f63181d39de8c3a713e90018R135-R144 "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step. Error: "codesign" failed with following output: /var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app: replacing existing signature /var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app: code object is not signed at all In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py [17:58:51.622] java.io.IOException: Command [/usr/bin/codesign, -s, Developer ID Application: JabRef e.V. (6792V39SK3), -vvvv, --timestamp, --options, runtime, --prefix, org.***, --entitlements, buildres/mac/***.entitlements, --force, /var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app] exited with 1 code at jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:90) at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:125) at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.runCodesign(MacAppImageBuilder.java:740) at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.signAppBundle(MacAppImageBuilder.java:907) at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.doSigning(MacAppImageBuilder.java:414) at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.prepareApplicationFiles(MacAppImageBuilder.java:365) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createAppBundle(AppImageBundler.java:189) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.execute(AppImageBundler.java:93) at jdk.jpackage/jdk.jpackage.internal.MacBaseInstallerBundler.prepareAppBundle(MacBaseInstallerBundler.java:201) at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:83) at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:579) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:707) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:554) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:92) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849343813 From alanb at openjdk.org Sun May 4 18:41:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 4 May 2025 18:41:46 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sun, 4 May 2025 16:21:41 GMT, Markus KARG wrote: >> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. >> >> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Undone copyright update of otherwise unchanged file. > - Update Of.java > > Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise." Way too early to create a PR and CSR for this. I think close the PR for now, instead start a discussion on core-libs-dev to get input. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849357907 From duke at openjdk.org Sun May 4 19:00:52 2025 From: duke at openjdk.org (Luca Kellermann) Date: Sun, 4 May 2025 19:00:52 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v2] In-Reply-To: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com> References: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com> Message-ID: On Sat, 3 May 2025 01:08:17 GMT, Chen Liang wrote: >> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Don't need to update latestSupported later > > - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv > - Add advanced testing for different latestSupported > > - 8355536: Create version constants to model preview language and vm features src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413: > 411: * ensure the program is compatible with future Java SE releases. > 412: *

> 413: * This is a reflective preview API to allows tools running in Java runtime Suggestion: * This is a reflective preview API that allows tools running in Java runtime src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 419: > 417: * @see > 418: * JEP 456: Unnamed Variables & Patterns > 419: Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072682604 PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072683561 From duke at openjdk.org Sun May 4 19:41:55 2025 From: duke at openjdk.org (Luca Kellermann) Date: Sun, 4 May 2025 19:41:55 GMT Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall [v3] In-Reply-To: References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com> Message-ID: On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang wrote: >> Perf numbers for simple main: >> Linking of `Class::forName0` down from ~152 to ~83 >> >> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344: >> JNI: ~45 >> baseline panama: ~164 >> patch: ~103 >> >> Also see #24705. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms > - Use more simple function descriptor > - Simplify FFM linker warmup > - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms > - Wip work trying to speed up FFM src/java.base/share/classes/java/lang/foreign/Linker.java line 866: > 864: .map(CapturableState::forName) > 865: .mapToInt(state -> 1 << state.ordinal()) > 866: .sum(); Using `sum` means the result will be incorrect if `capturedState` contains a valid name multiple times: var option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("WSAGetLastError", "WSAGetLastError"); // will print [ERRNO] on Windows System.out.println(option.saved()); option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("errno", "errno"); // will throw IndexOutOfBoundsException on all platforms option.saved(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072694511 From duke at openjdk.org Sun May 4 19:41:55 2025 From: duke at openjdk.org (duke) Date: Sun, 4 May 2025 19:41:55 GMT Subject: Withdrawn: 8349241: Fix the concurrent execution JVM crash of StringBuilder::append(int/long) In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 18:51:20 GMT, Shaojin Wen wrote: > The following code can reproduce the problem, writing out of bounds causes JVM Crash > > > StringBuilder buf = new StringBuilder(); > buf.append('?'); > > Thread[] threads = new Thread[40]; > final CountDownLatch latch = new CountDownLatch(threads.length); > Runnable r = () -> { > for (int i = 0; i < 1000000; i++) { > buf.setLength(0); > buf.trimToSize(); > buf.append(123456789123456789L); > } > latch.countDown(); > }; > > for (int i = 0; i < threads.length; i++) { > threads[i] = new Thread(r); > } > for (Thread t : threads) { > t.start(); > } > latch.await(); > > > This problem can be avoided by using the value of ensureCapacityInternal directly. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23427 From duke at openjdk.org Sun May 4 19:45:56 2025 From: duke at openjdk.org (duke) Date: Sun, 4 May 2025 19:45:56 GMT Subject: Withdrawn: 8349189: Speed up DateTime parse & format via Class File API In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen wrote: > By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization. > > Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations: > > 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization. > > 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext. > > These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23384 From duke at openjdk.org Sun May 4 19:47:53 2025 From: duke at openjdk.org (duke) Date: Sun, 4 May 2025 19:47:53 GMT Subject: Withdrawn: 8315585: Optimization for decimal to string In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: On Sat, 25 Jan 2025 07:25:40 GMT, Shaojin Wen wrote: > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23310 From liach at openjdk.org Sun May 4 20:27:52 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 20:27:52 GMT Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall [v3] In-Reply-To: References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com> Message-ID: On Sun, 4 May 2025 19:35:15 GMT, Luca Kellermann wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms >> - Use more simple function descriptor >> - Simplify FFM linker warmup >> - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms >> - Wip work trying to speed up FFM > > src/java.base/share/classes/java/lang/foreign/Linker.java line 866: > >> 864: .map(CapturableState::forName) >> 865: .mapToInt(state -> 1 << state.ordinal()) >> 866: .sum(); > > Using `sum` means the result will be incorrect if `capturedState` contains a valid name multiple times: > > var option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("WSAGetLastError", "WSAGetLastError"); > > // will print [ERRNO] on Windows > System.out.println(option.saved()); > > > option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("errno", "errno"); > > // will throw IndexOutOfBoundsException on all platforms > option.saved(); Hmm, I intentionally checked `toSet` does not reject duplicates but forgot about this part. Anyways this stream code is problematic; will fix this in a patch that removes this stream code wholesale. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072703688 From liach at openjdk.org Sun May 4 20:29:02 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 20:29:02 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v3] In-Reply-To: References: Message-ID: <9iHgapUiP3vcKCr2JX3m0ZI0PjYe6OKnJvtL4ujo3oI=.97814213-5bd1-486b-bafc-743c2d5666d2@github.com> > Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Co-authored-by: Luca Kellermann ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25017/files - new: https://git.openjdk.org/jdk/pull/25017/files/d0ff022f..0a3f3896 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017 PR: https://git.openjdk.org/jdk/pull/25017 From liach at openjdk.org Sun May 4 20:31:45 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 20:31:45 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v2] In-Reply-To: References: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com> Message-ID: On Sun, 4 May 2025 18:46:02 GMT, Luca Kellermann 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 four commits: >> >> - Don't need to update latestSupported later >> >> - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv >> - Add advanced testing for different latestSupported >> >> - 8355536: Create version constants to model preview language and vm features > > src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413: > >> 411: * ensure the program is compatible with future Java SE releases. >> 412: *

>> 413: * This is a reflective preview API to allows tools running in Java runtime > > Suggestion: > > * This is a reflective preview API that allows tools running in Java runtime Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072704486 From duke at openjdk.org Sun May 4 20:35:53 2025 From: duke at openjdk.org (Luca Kellermann) Date: Sun, 4 May 2025 20:35:53 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v2] In-Reply-To: References: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com> Message-ID: On Sun, 4 May 2025 20:29:18 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413: >> >>> 411: * ensure the program is compatible with future Java SE releases. >>> 412: *

>>> 413: * This is a reflective preview API to allows tools running in Java runtime >> >> Suggestion: >> >> * This is a reflective preview API that allows tools running in Java runtime > > Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release. It sounded wrong, maybe "to allow" (without 's') would be better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072705126 From liach at openjdk.org Sun May 4 20:38:47 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 20:38:47 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: <5mpZGPWGnNshcE30YOHry52vhvYWzdz3sOpsxOIu_nU=.2efc76c8-72c6-4938-91be-b68af5c90223@github.com> On Sun, 4 May 2025 18:39:24 GMT, Alan Bateman wrote: > start a discussion on core-libs-dev Threads about this topic have been started multiple times but failed to attract any attention on this topic, not even a rejection: - https://mail.openjdk.org/pipermail/core-libs-dev/2024-December/thread.html#137807 - https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/thread.html#141272 In this situation, how can we ensure a renewed discussion will actually attract attention? I think our guide should suggest a solution to this, like "prmopting a thread after 2 weeks of no reply"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849406747 From liach at openjdk.org Sun May 4 21:37:26 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 21:37:26 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v4] In-Reply-To: References: Message-ID: <_MkrZWV7SnFd_3CgOvpa_gER0ie2syWXAEhvS47jHLs=.29f9f5a1-ab2f-4be3-8b5d-bb3184ab77ab@github.com> > Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25017/files - new: https://git.openjdk.org/jdk/pull/25017/files/0a3f3896..c1a175ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017 PR: https://git.openjdk.org/jdk/pull/25017 From liach at openjdk.org Sun May 4 21:37:26 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 21:37:26 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v2] In-Reply-To: References: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com> Message-ID: On Sun, 4 May 2025 20:33:36 GMT, Luca Kellermann wrote: >> Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release. > > It sounded wrong, maybe "to allow" (without 's') would be better. Suggestion: * This is a reflective preview API to allow tools running in Java runtime ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072719721 From liach at openjdk.org Sun May 4 21:46:50 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 21:46:50 GMT Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall [v3] In-Reply-To: References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com> Message-ID: On Sun, 4 May 2025 20:25:02 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/foreign/Linker.java line 866: >> >>> 864: .map(CapturableState::forName) >>> 865: .mapToInt(state -> 1 << state.ordinal()) >>> 866: .sum(); >> >> Using `sum` means the result will be incorrect if `capturedState` contains a valid name multiple times: >> >> var option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("WSAGetLastError", "WSAGetLastError"); >> >> // will print [ERRNO] on Windows >> System.out.println(option.saved()); >> >> >> option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("errno", "errno"); >> >> // will throw IndexOutOfBoundsException on all platforms >> option.saved(); > > Hmm, I intentionally checked `toSet` does not reject duplicates but forgot about this part. Anyways this stream code is problematic; will fix this in a patch that removes this stream code wholesale. I created an issue to revisit CapturableState https://bugs.openjdk.org/browse/JDK-8356126 and will fix these problem with new unit test ensuring the toString message and nonexistent/duplicate behaviors, also removing redundant stream usage. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072721337 From liach at openjdk.org Sun May 4 22:40:52 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 22:40:52 GMT Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall [v3] In-Reply-To: References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com> Message-ID: On Sun, 4 May 2025 21:43:40 GMT, Chen Liang wrote: >> Hmm, I intentionally checked `toSet` does not reject duplicates but forgot about this part. Anyways this stream code is problematic; will fix this in a patch that removes this stream code wholesale. > > I created an issue to revisit CapturableState https://bugs.openjdk.org/browse/JDK-8356126 and will fix these problem with new unit test ensuring the toString message and nonexistent/duplicate behaviors, also removing redundant stream usage. See #25025, which includes a regression test that should prevent such duplicate arg mishandling or toString message missing user-friendly names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072730363 From liach at openjdk.org Sun May 4 22:41:54 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 22:41:54 GMT Subject: RFR: 8356126: Revisit CaptureCallState Message-ID: Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) Testing: jdk/lang/foreign, tier 1-3 in progress. ------------- Commit messages: - Bugid - 8356126: Revisit CaptureCallState Changes: https://git.openjdk.org/jdk/pull/25025/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356126 Stats: 129 lines in 7 files changed: 48 ins; 42 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From mik3hall at gmail.com Sun May 4 22:54:25 2025 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 4 May 2025 17:54:25 -0500 Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: <9A5706EA-EC7A-41BE-8518-4C7BF68868A9@gmail.com> > On May 4, 2025, at 1:12?PM, Christoph wrote: > > In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py If this is the current error log the file ***Host.py (? Strange file name.) doesn?t seem to be in the resource directory but the Contents directory still? But I?ve been off on this a couple times already. Still curious do all the codesign running messages in verbose output indicate multiple invocations or are they the status for a single running process? -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun May 4 23:13:49 2025 From: duke at openjdk.org (Luca Kellermann) Date: Sun, 4 May 2025 23:13:49 GMT Subject: RFR: 8356126: Revisit CaptureCallState In-Reply-To: References: Message-ID: On Sun, 4 May 2025 22:37:21 GMT, Chen Liang wrote: > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 63: > 61: stateLayouts[i++] = supported.layout; > 62: } > 63: LAYOUT = MemoryLayout.structLayout(stateLayouts); Does it matter that the order is not deterministic here? This question can also be asked for the exception in `forName` and result of `displayString`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072732592 From asemenyuk at openjdk.org Sun May 4 23:18:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sun, 4 May 2025 23:18:53 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. In the log: In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py The command line: jpackage \ ... --app-content buildres/mac/Resources/***Host.py \ --app-content buildres/mac/Resources/native-messaging-host \ `--app-content` values are wrong. My bad, I gave you incorrect instructions. It should be a single "--app-content buildres/mac" option. This way, jpackage will copy both the "jabrefHost.py" file and the "native-messaging-host" directory into the "Contents/Resources" directory in the app bundle. This should make codesign work. You can have multiple `--app-content` on the jpackage command line, but on macOS, the value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the app bundle). Otherwise, codesign will keep failing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849491184 From liach at openjdk.org Sun May 4 23:32:43 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 4 May 2025 23:32:43 GMT Subject: RFR: 8356126: Revisit CaptureCallState In-Reply-To: References: Message-ID: On Sun, 4 May 2025 22:51:21 GMT, Luca Kellermann wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 63: > >> 61: stateLayouts[i++] = supported.layout; >> 62: } >> 63: LAYOUT = MemoryLayout.structLayout(stateLayouts); > > Does it matter that the order is not deterministic here? This question can also be asked for the exception in `forName` and result of `displayString`. After all, this should not be an enum when the entries differ by platform. We need to convert this to records. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072740841 From iklam at openjdk.org Mon May 5 00:29:19 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 00:29:19 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics Message-ID: This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" - Added processing of the `AOT_TOOL_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. Examples: # Create an AOT cache with a single command: $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld Hello World Temporary AOTConfiguration recorded: foo.aot.config Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot AOTCache creation is complete: foo.aot 10240000 bytes # Create logging file for the AOT cache assembly phase $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). ------------- Commit messages: - Remove %t restriction - Added %p substitution; clean up - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - fixed typo - added comment that was removed in previous commit - Refactored code to enfore the order of argument parsing - 8355798: Implement JEP-JDK-8350022: Ahead-of-time Command Line Ergonomics Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355798 Stats: 1776 lines in 17 files changed: 1298 ins; 439 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From kvn at openjdk.org Mon May 5 00:29:20 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 00:29:20 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 04:50:42 GMT, Ioi Lam wrote: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `AOT_TOOL_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Few comments. JEP and CSR call env var :`JAVA_AOT_OPTIONS`. This description and changes call it `AOT_TOOL_OPTIONS`. Please, fix. src/hotspot/share/cds/metaspaceShared.cpp line 1068: > 1066: } > 1067: > 1068: // Pass all arguments. These include those from JAVA_TOOL_OPTIONS and _JAVA_OPTIONS. `_JAVA_OPTIONS`. Do you mean `JAVA_AOT_OPTIONS`? src/hotspot/share/cds/metaspaceShared.cpp line 1071: > 1069: for (int i = 0; i < Arguments::num_jvm_args(); i++) { > 1070: const char* arg = Arguments::jvm_args_array()[i]; > 1071: if (strncmp("-XX:AOTMode", arg, 11) == 0) { In arguments.cpp you do `strncmp("-XX:AOTMode=", arg, 12) == 0`. I think you need to be consistent. src/java.base/share/classes/jdk/internal/misc/CDS.java line 510: > 508: > 509: Map env = pb.environment(); > 510: env.put("JAVA_TOOL_OPTIONS", sb.toString()); What about `JAVA_AOT_OPTIONS`? ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2804218715 PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2839405664 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066881980 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066888741 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066892210 From iklam at openjdk.org Mon May 5 00:38:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 00:38:13 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v2] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/acba394e..5e51e8fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=00-01 Stats: 305 lines in 5 files changed: 142 ins; 140 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Mon May 5 01:00:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 01:00:31 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @vnkozlov comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/5e51e8fe..0eb8b545 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=01-02 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Mon May 5 01:00:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 01:00:31 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 15:48:12 GMT, Vladimir Kozlov wrote: > JEP and CSR call env var :`JAVA_AOT_OPTIONS`. This description and changes call it `AOT_TOOL_OPTIONS`. Please, fix. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2849668130 From iklam at openjdk.org Mon May 5 01:00:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 01:00:31 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 15:56:59 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @vnkozlov comments > > src/hotspot/share/cds/metaspaceShared.cpp line 1068: > >> 1066: } >> 1067: >> 1068: // Pass all arguments. These include those from JAVA_TOOL_OPTIONS and _JAVA_OPTIONS. > > `_JAVA_OPTIONS`. Do you mean `JAVA_AOT_OPTIONS`? `JAVA_AOT_OPTIONS` is not parsed here. I added comments. > src/hotspot/share/cds/metaspaceShared.cpp line 1071: > >> 1069: for (int i = 0; i < Arguments::num_jvm_args(); i++) { >> 1070: const char* arg = Arguments::jvm_args_array()[i]; >> 1071: if (strncmp("-XX:AOTMode", arg, 11) == 0) { > > In arguments.cpp you do `strncmp("-XX:AOTMode=", arg, 12) == 0`. I think you need to be consistent. Fixed. > src/java.base/share/classes/jdk/internal/misc/CDS.java line 510: > >> 508: >> 509: Map env = pb.environment(); >> 510: env.put("JAVA_TOOL_OPTIONS", sb.toString()); > > What about `JAVA_AOT_OPTIONS`? This method doesn't not touch `JAVA_AOT_OPTIONS`, which will be inherited by the child process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761734 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761745 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761767 From liach at openjdk.org Mon May 5 03:13:35 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 03:13:35 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v2] In-Reply-To: References: Message-ID: > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Further revamp, remove unnecessary instances on irrelevant platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/94fca4b4..106ad252 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=00-01 Stats: 30 lines in 1 file changed: 12 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From liach at openjdk.org Mon May 5 03:32:45 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 03:32:45 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v3] In-Reply-To: References: Message-ID: > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Unchecked ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/106ad252..fc3e7a80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From liach at openjdk.org Mon May 5 04:50:30 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 04:50:30 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v4] In-Reply-To: References: Message-ID: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: No env to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/fc3e7a80..806d307b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From duke at openjdk.org Mon May 5 05:40:47 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 5 May 2025 05:40:47 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v4] In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: On Mon, 5 May 2025 04:50:30 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > No env to test Note?that the?use of?the?unsequenced `Map.of(?)` results?in the?return value of?`CapturableState?.displayString(?)` to?no?longer be?ordered by?the?mask?bits. To?fix?this, simply?add a?`private?static List`[^1] for?storing the?supported?values: [^1]: And/or?introduce and?use unmodifiable `SequencedMap.of(?)` and?`SequencedSet.of(?)` factory?methods. src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55: > 53: } else { > 54: supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2)); > 55: } Suggestion: private static final List SUPPORTED; static { final List supported; if (OperatingSystem.isWindows()) { supported = List.of( new CapturableState("GetLastError", JAVA_INT, 1 << 0), new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1), new CapturableState("errno", JAVA_INT, 1 << 2) ); } else { supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2)); } SUPPORTED = supported; src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 96: > 94: public static String displayString(int mask) { > 95: var displayList = new ArrayList<>(); > 96: for (var e : LOOKUP.values()) { Suggestion: for (var e : SUPPORTED) { ------------- PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2813828585 PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072860691 PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072860830 From alanb at openjdk.org Mon May 5 06:35:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 May 2025 06:35:46 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: <5mpZGPWGnNshcE30YOHry52vhvYWzdz3sOpsxOIu_nU=.2efc76c8-72c6-4938-91be-b68af5c90223@github.com> References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> <5mpZGPWGnNshcE30YOHry52vhvYWzdz3sOpsxOIu_nU=.2efc76c8-72c6-4938-91be-b68af5c90223@github.com> Message-ID: On Sun, 4 May 2025 20:36:07 GMT, Chen Liang wrote: > In this situation, how can we ensure a renewed discussion will actually attract attention? I think our guide should suggest a solution to this, like "prmopting a thread after 2 weeks of no reply"? The mailing list is the right place to get agreement on what the problem is and what the solution/API might be if it progresses to that. Lack of engagement should not be interpreted as supporting the proposal. The lack of engagement might be better interpreted as people are busy or maybe that the problem isn't compelling or high priority enough to spend time on right now. The dev guide should not put a deadline on getting responses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2850034687 From turbanoff at gmail.com Mon May 5 07:54:04 2025 From: turbanoff at gmail.com (Andrey Turbanov) Date: Mon, 5 May 2025 10:54:04 +0300 Subject: StringIndexOutOfBoundsException is thrown from String.concat Message-ID: Hello. I noticed that String.concat can throw StringIndexOutOfBoundsException: String r1 = "-".repeat(Integer.MAX_VALUE - 10); String r2 = "?".repeat((Integer.MAX_VALUE - 10) / 2); System.out.println(r1.concat(r2)); On JDK 24 it gives: Exception in thread "main" java.lang.StringIndexOutOfBoundsException: Range [0, 0 + 2147483637) out of bounds for length 1073741807 at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55) at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52) at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213) at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210) at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromIndexSize(Preconditions.java:118) at java.base/jdk.internal.util.Preconditions.checkFromIndexSize(Preconditions.java:397) at java.base/java.lang.String.checkBoundsOffCount(String.java:4938) at java.base/java.lang.StringUTF16.checkBoundsOffCount(StringUTF16.java:1789) at java.base/java.lang.StringUTF16.inflate(StringUTF16.java:1616) at java.base/java.lang.StringLatin1.inflate(StringLatin1.java:875) at java.base/java.lang.String.getBytes(String.java:4812) at java.base/java.lang.StringConcatHelper.doConcat(StringConcatHelper.java:434) at java.base/java.lang.String.concat(String.java:2977) On JDK 23 it results in expected OOM: Exception in thread "main" java.lang.OutOfMemoryError: Overflow: String length out of range at java.base/java.lang.StringConcatHelper.checkOverflow(StringConcatHelper.java:66) at java.base/java.lang.StringConcatHelper.mix(StringConcatHelper.java:125) at java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:374) at java.base/java.lang.String.concat(String.java:2990) Andrey Turbanov From aturbanov at openjdk.org Mon May 5 07:58:56 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 5 May 2025 07:58:56 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> References: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> Message-ID: On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > reduce change Looks like this changes regressed behavior on long Strings: String r1 = "-".repeat(Integer.MAX_VALUE - 10); String r2 = "?".repeat((Integer.MAX_VALUE - 10) / 2); System.out.println(r1.concat(r2)); This code now throws `StringIndexOutOfBoundsException` instead of `OutOfMemoryError` ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2850196722 From alan.bateman at oracle.com Mon May 5 08:06:34 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 5 May 2025 09:06:34 +0100 Subject: StringIndexOutOfBoundsException is thrown from String.concat In-Reply-To: References: Message-ID: <796f797f-238a-42fb-a498-2c62e4525e82@oracle.com> Can you create a bug in JBS to track this? -Alan On 05/05/2025 08:54, Andrey Turbanov wrote: > Hello. > I noticed that String.concat can throw StringIndexOutOfBoundsException: > > String r1 = "-".repeat(Integer.MAX_VALUE - 10); > String r2 = "?".repeat((Integer.MAX_VALUE - 10) / 2); > System.out.println(r1.concat(r2)); > > On JDK 24 it gives: > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: > Range [0, 0 + 2147483637) out of bounds for length 1073741807 > at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55) > at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52) > at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213) > at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210) > at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98) > at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromIndexSize(Preconditions.java:118) > at java.base/jdk.internal.util.Preconditions.checkFromIndexSize(Preconditions.java:397) > at java.base/java.lang.String.checkBoundsOffCount(String.java:4938) > at java.base/java.lang.StringUTF16.checkBoundsOffCount(StringUTF16.java:1789) > at java.base/java.lang.StringUTF16.inflate(StringUTF16.java:1616) > at java.base/java.lang.StringLatin1.inflate(StringLatin1.java:875) > at java.base/java.lang.String.getBytes(String.java:4812) > at java.base/java.lang.StringConcatHelper.doConcat(StringConcatHelper.java:434) > at java.base/java.lang.String.concat(String.java:2977) > > On JDK 23 it results in expected OOM: > > Exception in thread "main" java.lang.OutOfMemoryError: Overflow: > String length out of range > at java.base/java.lang.StringConcatHelper.checkOverflow(StringConcatHelper.java:66) > at java.base/java.lang.StringConcatHelper.mix(StringConcatHelper.java:125) > at java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:374) > at java.base/java.lang.String.concat(String.java:2990) > > Andrey Turbanov From jpai at openjdk.org Mon May 5 08:18:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 May 2025 08:18:46 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v4] In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: On Mon, 5 May 2025 04:50:30 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > No env to test src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 139: > 137: */ > 138: private static OperatingSystem initOS() { > 139: // Called lazily, valueOf has overhead Hello Chen, in context of this bug fix, what kind of overhead does `valueOf()` have? The (pre-existing) comment on this `initOS()` method sets an expectation that it will be called from the static initializer of this `OperatingSystem` class and thus it expects an `ExceptionInInitializerError` to be thrown by the static initiliazer, if the operating system name isn't recognized. Any access to `OperatingSystem` class would then have resulted in a `NoClassDefFoundError`. With this proposed change, the callers of `OperatingSystem.current()` would now start seeing an `IllegalArgumentException` if for any reason the operating system name isn't recognized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2073026614 From jpai at openjdk.org Mon May 5 08:22:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 May 2025 08:22:48 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v4] In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: On Mon, 5 May 2025 04:50:30 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > No env to test On a general note, I think the title of the JBS issue needs to better state what this change is about. From what I understand, this is a bug fix which addresses an issue in `jdk.internal.foreign.abi.LinkerOptions.capturedCallState()` method where it could have returned an incorrect value. I think the issue type also should be changed to Bug instead of Sub-task. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2850249386 From duke at openjdk.org Mon May 5 08:25:29 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Mon, 5 May 2025 08:25:29 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps Message-ID: The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 ------------- Commit messages: - Use the same syntax as for --mac-dmg-content - Correct documentation for --linux-package-deps Changes: https://git.openjdk.org/jdk/pull/23638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23638&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356128 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23638/head:pull/23638 PR: https://git.openjdk.org/jdk/pull/23638 From duke at openjdk.org Mon May 5 08:25:29 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Mon, 5 May 2025 08:25:29 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 15:01:35 GMT, Stefan Lobbenmeier wrote: > The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space > > You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 See also https://github.com/JetBrains/compose-multiplatform/pull/5227 for a discussion if this option has an argument Just gonna try /signed again, but I didn?t get any more information from oracle a new comment I guess the action also suggests that i should first create a Jira issue Cannot do that, but I could create a but to oracle jdk so I used that review id ------------- PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2659596573 PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2725595104 PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2844799049 PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2844822926 From duke at openjdk.org Mon May 5 08:28:56 2025 From: duke at openjdk.org (Christoph) Date: Mon, 5 May 2025 08:28:56 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. Thanks all for your support, with a single app-content parameter and the resource directory this worked with codesign and even notarization worked on both macOS13 and macOS14 (arm) It would be great if you document this in the manual/help ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2850262585 From jwaters at openjdk.org Mon May 5 09:20:45 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 May 2025 09:20:45 GMT Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code. Ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/24868#issuecomment-2850392890 From yzheng at openjdk.org Mon May 5 09:42:47 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Mon, 5 May 2025 09:42:47 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:44:31 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > changes to test src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669: > 667: > 668: public boolean isValueBased() { > 669: return (tsym.flags_field & VALUE_BASED) != 0; We have encountered a NPE in javac: java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669) at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915) ... It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073144717 From jpai at openjdk.org Mon May 5 10:34:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 May 2025 10:34:48 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: <-ljVhLq1eqiX7jZaQ_k4IBTLAu1iDbrTLljF8_wdq2Y=.300f3c0d-58a1-40af-9e21-e31afa1ade12@github.com> References: <-ljVhLq1eqiX7jZaQ_k4IBTLAu1iDbrTLljF8_wdq2Y=.300f3c0d-58a1-40af-9e21-e31afa1ade12@github.com> Message-ID: On Fri, 2 May 2025 19:06:58 GMT, Shaojin Wen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Lance's review - update code comment in the test > > src/java.base/share/classes/java/util/zip/ZipFile.java line 1240: > >> 1238: entries[index] = hash; >> 1239: entries[index + 1] = next; >> 1240: entries[index + 2] = pos; > > Suggestion: > > entries[index ] = hash; > entries[index + 1] = next; > entries[index + 2] = pos; > > Aligned code is more readable Hello Shaojin, leaving one or more spaces before a closing `]` bracket of array access contradicts the style that I've seen used often in the code. At least it's not a common style used in this area of the code in the JDK. I think it's fine in the current form and changing it to align with subsequent lines isn't necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2073207272 From eirbjo at openjdk.org Mon May 5 10:51:48 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 5 May 2025 10:51:48 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test Great work, I have no further input. Reviewing this part of ZipFile reminds me that this codes begs for some refactoring. Neither the RandomAccessFile nor the CEN bytes change between different charsets so I believe there may be potential for some untangling and simplification here. But that?s for another PR :) ------------- Marked as reviewed by eirbjo (Committer). PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2814432670 From lancea at openjdk.org Mon May 5 11:05:49 2025 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 5 May 2025 11:05:49 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test Thank you for the efforts on this Jai. The changes look good ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2814459946 From rehn at openjdk.org Mon May 5 11:46:55 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 5 May 2025 11:46:55 GMT Subject: Integrated: 8352730: RISC-V: Disable tests in qemu-user In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn wrote: > Hi, for you to consider. > > These tests constantly fails in qemu-user. > Either the require host to be same arch explicit or implicit (sysroot). > E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests. > > From bug: >> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that). >> We add this uarch to CPU feature string. >> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user. > > Relevant qemu code: > https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29 > > Relevant hotspot code: > https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250 > > Tested that the require only filters out tests in qemu+riscv64. > > Thanks! > > /Robbin This pull request has now been integrated. Changeset: 02647976 Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/026479767c011227b63e7fdb8a38f61977782249 Stats: 71 lines in 64 files changed: 71 ins; 0 del; 0 mod 8352730: RISC-V: Disable tests in qemu-user Reviewed-by: fyang, mli ------------- PR: https://git.openjdk.org/jdk/pull/24229 From rgiulietti at openjdk.org Mon May 5 13:13:39 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 13:13:39 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException Message-ID: A fix to throw `OutOfMemoryError`, as done in releases ? 23. ------------- Commit messages: - 8356152: String.concat can throw StringIndexOutOfBoundsException Changes: https://git.openjdk.org/jdk/pull/25038/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356152 Stats: 85 lines in 2 files changed: 84 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25038/head:pull/25038 PR: https://git.openjdk.org/jdk/pull/25038 From rgiulietti at openjdk.org Mon May 5 13:36:05 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 13:36:05 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: > A fix to throw `OutOfMemoryError`, as done in releases ? 23. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Simplified test slightly. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25038/files - new: https://git.openjdk.org/jdk/pull/25038/files/a70ccd20..900a0b8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=00-01 Stats: 23 lines in 1 file changed: 2 ins; 13 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25038/head:pull/25038 PR: https://git.openjdk.org/jdk/pull/25038 From liach at openjdk.org Mon May 5 13:41:47 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 13:41:47 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 13:36:05 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Simplified test slightly. Looks good. So the problem was when `s1.length() + s2.length()` overflows to be negative, `<< coder` can make it positive and bypass the check in `newLength` - a weird scenario indeed. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2814854242 From jpai at openjdk.org Mon May 5 13:53:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 May 2025 13:53:48 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 13:36:05 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Simplified test slightly. test/jdk/java/lang/String/concat/HugeConcatTest.java line 29: > 27: * @summary Check that huge concatenations throw OutOfMemoryError > 28: * @run junit/othervm -Xmx6G -XX:+CompactStrings -Dcompact=true HugeConcatTest > 29: * @run junit/othervm -Xmx6G -XX:-CompactStrings -Dcompact=false HugeConcatTest Hello Raffaello, some other tests that require such large heap sizes use a: `@requires os.maxMemory > 6G` to prevent failure to launch `java`. I think we should add it here too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073491401 From asemenyuk at openjdk.org Mon May 5 14:01:57 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 5 May 2025 14:01:57 GMT Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: <309qivCCj1axCGqcU_y57X27CX4KNZj71CYYjwuAsxo=.b0833f4f-1f29-43c7-a536-a952f45b3022@github.com> On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code. Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24868#pullrequestreview-2814913682 From rgiulietti at openjdk.org Mon May 5 14:06:27 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 14:06:27 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v3] In-Reply-To: References: Message-ID: > A fix to throw `OutOfMemoryError`, as done in releases ? 23. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Added '@requires' to test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25038/files - new: https://git.openjdk.org/jdk/pull/25038/files/900a0b8d..1207556c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25038/head:pull/25038 PR: https://git.openjdk.org/jdk/pull/25038 From rgiulietti at openjdk.org Mon May 5 14:06:27 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 14:06:27 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 13:51:13 GMT, Jaikiran Pai wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplified test slightly. > > test/jdk/java/lang/String/concat/HugeConcatTest.java line 29: > >> 27: * @summary Check that huge concatenations throw OutOfMemoryError >> 28: * @run junit/othervm -Xmx6G -XX:+CompactStrings -Dcompact=true HugeConcatTest >> 29: * @run junit/othervm -Xmx6G -XX:-CompactStrings -Dcompact=false HugeConcatTest > > Hello Raffaello, some other tests that require such large heap sizes use a: > > `@requires os.maxMemory > 6G` > > to prevent failure to launch `java`. I think we should add it here too. Thanks Jai ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073512927 From aturbanov at openjdk.org Mon May 5 14:25:46 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 5 May 2025 14:25:46 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:06:27 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Added '@requires' to test. test/jdk/java/lang/String/concat/HugeConcatTest.java line 38: > 36: import static org.junit.Assert.assertThrows; > 37: > 38: public class HugeConcatTest { The same issue is reproduced with simple `+` concatenation. String r1 = "-".repeat(Integer.MAX_VALUE - 10); String r2 = "?".repeat((Integer.MAX_VALUE - 10) / 2); System.out.println(r1 + r2); I think it makes sense to add related test for it too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073551759 From rgiulietti at openjdk.org Mon May 5 14:38:05 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 14:38:05 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v4] In-Reply-To: References: Message-ID: > A fix to throw `OutOfMemoryError`, as done in releases ? 23. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Added language concat + to test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25038/files - new: https://git.openjdk.org/jdk/pull/25038/files/1207556c..f0c75b95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=02-03 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25038/head:pull/25038 PR: https://git.openjdk.org/jdk/pull/25038 From rgiulietti at openjdk.org Mon May 5 14:38:06 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 14:38:06 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:23:11 GMT, Andrey Turbanov wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Added '@requires' to test. > > test/jdk/java/lang/String/concat/HugeConcatTest.java line 38: > >> 36: import static org.junit.Assert.assertThrows; >> 37: >> 38: public class HugeConcatTest { > > The same issue is reproduced with simple `+` concatenation. > > String r1 = "-".repeat(Integer.MAX_VALUE - 10); > String r2 = "?".repeat((Integer.MAX_VALUE - 10) / 2); > System.out.println(r1 + r2); > > I think it makes sense to add related test for it too. @turbanoff I addressed your note. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073576074 From vromero at openjdk.org Mon May 5 14:46:48 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 5 May 2025 14:46:48 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v4] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 09:40:16 GMT, Yudi Zheng wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> changes to test > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669: > >> 667: >> 668: public boolean isValueBased() { >> 669: return (tsym.flags_field & VALUE_BASED) != 0; > > We have encountered a NPE in javac: > > java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null > at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669) > at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915) > ... > > It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519 thanks for the report I will update the PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073595845 From liach at openjdk.org Mon May 5 15:05:48 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 15:05:48 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:24:06 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Optimize StringUTF16.putCharsAt a bit. > Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1856: > 1854: > 1855: // Package access for String and StringBuffer. > 1856: final boolean isLatin1() { I recommend inlining the Stirng usage of this method too like for all other sites in ASB. Then this is only used by serialization of StringBuffer/Builder, and arguably those can move to use the plain version too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073607977 From ihse at openjdk.org Mon May 5 15:08:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 May 2025 15:08:52 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: <7unkKqs4wV5Iy9XF-iKuz0PU9VNXMyWS740Gn93H8B0=.d0c238fc-8ca3-42ad-a7a8-b43af17f1cb2@github.com> On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck Build changes look good. @ alexeysemenyukoracle Can you review the jpackage test change? ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2815147219 From liach at openjdk.org Mon May 5 15:55:51 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 15:55:51 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v4] In-Reply-To: References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: On Mon, 5 May 2025 05:31:33 GMT, ExE Boss wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> No env to test > > src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 96: > >> 94: public static String displayString(int mask) { >> 95: var displayList = new ArrayList<>(); >> 96: for (var e : LOOKUP.values()) { > > Suggestion: > > for (var e : SUPPORTED) { Good point, however this is display only. To fix this I should add a comment to displayList. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2073708594 From liach at openjdk.org Mon May 5 15:55:52 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 15:55:52 GMT Subject: RFR: 8356126: Revisit CaptureCallState [v4] In-Reply-To: References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: On Mon, 5 May 2025 08:16:31 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> No env to test > > src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 139: > >> 137: */ >> 138: private static OperatingSystem initOS() { >> 139: // Called lazily, valueOf has overhead > > Hello Chen, in context of this bug fix, what kind of overhead does `valueOf()` have? > The (pre-existing) comment on this `initOS()` method sets an expectation that it will be called from the static initializer of this `OperatingSystem` class and thus it expects an `ExceptionInInitializerError` to be thrown by the static initiliazer, if the operating system name isn't recognized. Any access to `OperatingSystem` class would then have resulted in a `NoClassDefFoundError`. With this proposed change, the callers of `OperatingSystem.current()` would now start seeing an `IllegalArgumentException` if for any reason the operating system name isn't recognized. Enum.valueOf -> Class.enumConstantDirectory -> Class.getEnumConstantsShared -> Method.invoke -> MethodHandleAccessorFactory.makeSpecializedTarget(isStatic = true) -> MethodHandles.dropArguments -> LambdaForm.editor -> bytecode generation and loading because this currently cannot be pregenerated by CDS archive. If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2073707472 From liach at openjdk.org Mon May 5 16:11:23 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 16:11:23 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v5] In-Reply-To: References: Message-ID: <_YoWvD7qNQzOVYH7nGma3s_D1k8Blh3D-AyUOqY7DxQ=.d7012548-d463-45aa-be82-5de8d89b2cb1@github.com> > Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version. 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: - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Co-authored-by: Luca Kellermann - Don't need to update latestSupported later - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512 - Add advanced testing for different latestSupported - 8355536: Create version constants to model preview language and vm features ------------- Changes: https://git.openjdk.org/jdk/pull/25017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=04 Stats: 1265 lines in 6 files changed: 1123 ins; 83 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/25017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017 PR: https://git.openjdk.org/jdk/pull/25017 From kvn at openjdk.org Mon May 5 16:21:46 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 16:21:46 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: <7xQPMF73IAIbB7vGPS8ipjIiaimA6O4Jmm8XqqMgN4I=.f6084b06-65d6-453e-a8c6-f455ccc7a15a@github.com> On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments src/hotspot/share/cds/metaspaceShared.cpp line 1018: > 1016: CDSConfig::disable_dumping_aot_code(); > 1017: } > 1018: Is this from merge form mainline? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2073756831 From kvn at openjdk.org Mon May 5 16:24:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 16:24:48 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments src/hotspot/share/cds/cdsConfig.cpp line 412: > 410: log_debug(aot,codecache,init)("AOTCache is not specified - AOTAdapterCaching is ignored"); > 411: } > 412: Also from merge? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2073760775 From vromero at openjdk.org Mon May 5 16:30:27 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 5 May 2025 16:30:27 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v5] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/60f1f53b..ad7f617d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=03-04 Stats: 8 lines in 3 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From liach at openjdk.org Mon May 5 16:44:02 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 16:44:02 GMT Subject: RFR: 8356126: Duplicaton handling and optimization of CaptureCallState [v5] In-Reply-To: References: Message-ID: > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Review remarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/806d307b..d1598afa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From liach at openjdk.org Mon May 5 16:44:02 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 16:44:02 GMT Subject: RFR: 8356126: Duplicaton handling and optimization of CaptureCallState [v4] In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: On Mon, 5 May 2025 04:50:30 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > No env to test Thanks for the remarks. I have addressed them; feel free to review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2851601489 From jlu at openjdk.org Mon May 5 16:45:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 5 May 2025 16:45:51 GMT Subject: Integrated: 8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out In-Reply-To: References: Message-ID: On Fri, 2 May 2025 15:49:03 GMT, Justin Lu wrote: > Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`. > > This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster. > > Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`. This pull request has now been integrated. Changeset: 32f67a3e Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/32f67a3e38be807164435ea0841c01d2b7c73652 Stats: 133 lines in 1 file changed: 64 ins; 48 del; 21 mod 8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/25009 From pminborg at openjdk.org Mon May 5 16:53:56 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 5 May 2025 16:53:56 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. >> >> >> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac): >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail avgt 30 24.330 ? 0.820 ns/op >> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess avgt 30 8.257 ? 0.117 ns/op >> CaptureStateUtilBench.OfVirtual.explicitAllocationFail avgt 30 41.415 ? 1.013 ns/op >> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess avgt 30 21.720 ? 0.463 ns/op >> CaptureStateUtilBench.OfVirtual.tlAllocationFail avgt 30 23.636 ? 0.182 ns/op >> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess avgt 30 8.234 ? 0.156 ns/op >> CaptureStateUtilBench.adaptedSysCallFail avgt 30 23.918 ? 0.487 ns/op >> CaptureStateUtilBench.adaptedSysCallSuccess avgt 30 4.946 ? 0.089 ns/op >> CaptureStateUtilBench.explicitAllocationFail avgt 30 42.280 ? 1.128 ns/op >> CaptureStateUtilBench.explicitAllocationSuccess avgt 30 21.809 ? 0.413 ns/op >> CaptureStateUtilBench.tlAllocationFail avgt 30 24.422 ? 0.673 ns/op >> CaptureStateUtilBench.tlAllocationSuccess avgt 30 5.182 ? 0.152 ns/op >> >> >> Adapted system call: >> >> return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool >> ``` >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> ``` >> Thread Local allocation: >> >> try (var arena = POOLS.take()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool >> } >> ``` >> The adapted system call exhibits a ~4x performance improvement ove... > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add hashCode/equals to record to improve startup time I will close this PR and create a new one against the bug report using the newly integrated `BufferStack` and Stable Values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23765#issuecomment-2851629378 From pminborg at openjdk.org Mon May 5 16:59:02 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 5 May 2025 16:59:02 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno Message-ID: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. ------------- Commit messages: - Use stable values - Merge branch 'master' into errno-util3b - Add hashCode/equals to record to improve startup time - Revert change to ArenaImpl - Merge master - Merge master - Add test for woven allocation - Merge branch 'master' into errno-util3 - Use lazy initialization of method handles - Clean up visibility - ... and 29 more: https://git.openjdk.org/jdk/compare/1501a5e4...04dc6d3e Changes: https://git.openjdk.org/jdk/pull/25043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347408 Stats: 818 lines in 9 files changed: 805 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Mon May 5 17:09:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 5 May 2025 17:09:03 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v2] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: <3SdR6_UBmgwF4FYVHVc0NVWtcJP109kPfKCd9m1u6Dk=.a18f4c75-757c-44d5-b0a4-a2078d88c828@github.com> > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Reformat more - Reformat ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/04dc6d3e..29441123 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Mon May 5 17:09:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 5 May 2025 17:09:03 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: <2XpgMtckMkT6IA6hNlOajEN56B0v8pxSL6pAHRof-pQ=.d76066ce-881d-4fef-b2f4-76a0f19f9c43@github.com> On Mon, 5 May 2025 16:53:58 GMT, Per Minborg wrote: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. The current benchmarks (M1 macOS): ~/Applications/brr --build --build-microbenchmarks -w CaptureStateUtilBench Benchmark Mode Cnt Score Error Units CaptureStateUtilBench.OfVirtual.adaptedSysCallFail avgt 30 34.372 ? 0.221 ns/op CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess avgt 30 12.694 ? 0.251 ns/op CaptureStateUtilBench.OfVirtual.explicitAllocationFail avgt 30 40.470 ? 0.529 ns/op CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess avgt 30 21.680 ? 0.339 ns/op CaptureStateUtilBench.adaptedSysCallFail avgt 30 31.054 ? 0.575 ns/op CaptureStateUtilBench.adaptedSysCallSuccess avgt 30 5.029 ? 0.088 ns/op CaptureStateUtilBench.explicitAllocationFail avgt 30 40.338 ? 0.586 ns/op CaptureStateUtilBench.explicitAllocationSuccess avgt 30 21.769 ? 0.552 ns/op Passes `tier1` on multiple platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25043#issuecomment-2851658924 From pminborg at openjdk.org Mon May 5 17:13:02 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 5 May 2025 17:13:02 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with three additional commits since the last revision: - Fix empty line at the end of a third file - Fix empty line at the end of another file - Fix empty line at the end of a file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/29441123..07a39db9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From aturbanov at openjdk.org Mon May 5 17:14:47 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 5 May 2025 17:14:47 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v4] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:38:05 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Added language concat + to test. test/jdk/java/lang/String/concat/HugeConcatTest.java line 38: > 36: import static org.junit.Assert.assertThrows; > 37: > 38: public class HugeConcatTest { I've tried to execute the test with reverting changes in `StringConcatHelper` - it doesn't fail. Added logging and actually OOM happened due to heap size: Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range Reall got OOM: java.lang.OutOfMemoryError: Java heap space Reall got OOM: java.lang.OutOfMemoryError: Java heap space Reall got OOM: java.lang.OutOfMemoryError: Java heap space Reall got OOM: java.lang.OutOfMemoryError: Java heap space Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range ----------System.err:(13/854)---------- STARTED HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' SUCCESSFUL HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' [9ms] STARTED HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' SUCCESSFUL HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' [657ms] STARTED HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' SUCCESSFUL HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' [52ms] STARTED HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' SUCCESSFUL HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' [1ms] I think we should validate error message too. Not only fact that it was thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073833500 From aturbanov at openjdk.org Mon May 5 17:14:47 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 5 May 2025 17:14:47 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v4] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 17:09:37 GMT, Andrey Turbanov wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Added language concat + to test. > > test/jdk/java/lang/String/concat/HugeConcatTest.java line 38: > >> 36: import static org.junit.Assert.assertThrows; >> 37: >> 38: public class HugeConcatTest { > > I've tried to execute the test with reverting changes in `StringConcatHelper` - it doesn't fail. > Added logging and actually OOM happened due to heap size: > > Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range > Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range > Reall got OOM: java.lang.OutOfMemoryError: Java heap space > Reall got OOM: java.lang.OutOfMemoryError: Java heap space > Reall got OOM: java.lang.OutOfMemoryError: Java heap space > Reall got OOM: java.lang.OutOfMemoryError: Java heap space > Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range > Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range > ----------System.err:(13/854)---------- > STARTED HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' > SUCCESSFUL HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' [9ms] > STARTED HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' > SUCCESSFUL HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' [657ms] > STARTED HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' > SUCCESSFUL HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' [52ms] > STARTED HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' > SUCCESSFUL HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' [1ms] > > > I think we should validate error message too. Not only fact that it was thrown. _Really_ fails with Xmx7G ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073836326 From rriggs at openjdk.org Mon May 5 17:18:33 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 May 2025 17:18:33 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v4] In-Reply-To: References: Message-ID: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Applied suggestion to use StringUTF16.compress in append() for copying char[]. Added similar improvement to putCharsAt. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/d2261cd6..ff3d841f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=02-03 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From naoto at openjdk.org Mon May 5 17:22:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 May 2025 17:22:45 GMT Subject: RFR: 8356096: ISO 4217 Amendment 179 Update In-Reply-To: References: Message-ID: On Fri, 2 May 2025 20:51:31 GMT, Justin Lu wrote: > Please review this PR which implements ISO 4217 update 179. > > The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`). LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25014#pullrequestreview-2815515425 From rgiulietti at openjdk.org Mon May 5 17:29:33 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 17:29:33 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: Message-ID: > A fix to throw `OutOfMemoryError`, as done in releases ? 23. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Increased min heap size to 8G. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25038/files - new: https://git.openjdk.org/jdk/pull/25038/files/f0c75b95..0ca5b653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25038&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25038/head:pull/25038 PR: https://git.openjdk.org/jdk/pull/25038 From iris at openjdk.org Mon May 5 17:31:45 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 5 May 2025 17:31:45 GMT Subject: RFR: 8356096: ISO 4217 Amendment 179 Update In-Reply-To: References: Message-ID: On Fri, 2 May 2025 20:51:31 GMT, Justin Lu wrote: > Please review this PR which implements ISO 4217 update 179. > > The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`). Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25014#pullrequestreview-2815543817 From rriggs at openjdk.org Mon May 5 17:32:19 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 May 2025 17:32:19 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: References: Message-ID: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/ff3d841f..80992a20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From jpai at openjdk.org Mon May 5 17:37:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 May 2025 17:37:47 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/StringUTF16.java line 1531: > 1529: } > 1530: > 1531: public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) { Hello Roger, can this (pre-existing) method and the other `putCharsAt` that we are changing here, be changed to package private instead of `public`? As far as I can see, these 2 are only accessed from `java.lang.AbstractStringBuilder` which resides in the same package as this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073878460 From liach at openjdk.org Mon May 5 17:41:48 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 17:41:48 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:34:43 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. > > src/java.base/share/classes/java/lang/StringUTF16.java line 1531: > >> 1529: } >> 1530: >> 1531: public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) { > > Hello Roger, can this (pre-existing) method and the other `putCharsAt` that we are changing here, be changed to package private instead of `public`? As far as I can see, these 2 are only accessed from `java.lang.AbstractStringBuilder` which resides in the same package as this class. In fact, `StringUTF16` and `StringLatin1` are both package-private, so technically all their method access modifiers should either be package-private or private. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073887894 From rgiulietti at openjdk.org Mon May 5 17:49:47 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 May 2025 17:49:47 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v4] In-Reply-To: References: Message-ID: <6vv_RfftsMHItY1Fd1m4WFUraAwfYiNui815ORAQL7k=.4e685520-cfc2-49ac-9808-7ed197941fb7@github.com> On Mon, 5 May 2025 17:11:46 GMT, Andrey Turbanov wrote: >> test/jdk/java/lang/String/concat/HugeConcatTest.java line 38: >> >>> 36: import static org.junit.Assert.assertThrows; >>> 37: >>> 38: public class HugeConcatTest { >> >> I've tried to execute the test with reverting changes in `StringConcatHelper` - it doesn't fail. >> Added logging and actually OOM happened due to heap size: >> >> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range >> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range >> Reall got OOM: java.lang.OutOfMemoryError: Java heap space >> Reall got OOM: java.lang.OutOfMemoryError: Java heap space >> Reall got OOM: java.lang.OutOfMemoryError: Java heap space >> Reall got OOM: java.lang.OutOfMemoryError: Java heap space >> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range >> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range >> ----------System.err:(13/854)---------- >> STARTED HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' >> SUCCESSFUL HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' [9ms] >> STARTED HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' >> SUCCESSFUL HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' [657ms] >> STARTED HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' >> SUCCESSFUL HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' [52ms] >> STARTED HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' >> SUCCESSFUL HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' [1ms] >> >> >> I think we should validate error message too. Not only fact that it was thrown. > > _Really_ fails with Xmx7G Yes, the required heap size was not enough for the reverted variant to throw a non-OOME exception/error. Just out of curiosity, is JDK-8356152 a real-world issue you stumbled upon, or did you encounter it during some testing of yours? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073899613 From rriggs at openjdk.org Mon May 5 18:02:50 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 May 2025 18:02:50 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:38:55 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/StringUTF16.java line 1531: >> >>> 1529: } >>> 1530: >>> 1531: public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) { >> >> Hello Roger, can this (pre-existing) method and the other `putCharsAt` that we are changing here, be changed to package private instead of `public`? As far as I can see, these 2 are only accessed from `java.lang.AbstractStringBuilder` which resides in the same package as this class. > > In fact, `StringUTF16` and `StringLatin1` are both package-private, so technically all their method access modifiers should either be package-private or private. How about in another PR. None of the `public static ` methods in StringUTF16 or StringLatin1 need to be public. But it will make this PR very noisy for the wrong reasons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073917061 From jpai at openjdk.org Mon May 5 18:02:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 May 2025 18:02:51 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:58:09 GMT, Roger Riggs wrote: >> In fact, `StringUTF16` and `StringLatin1` are both package-private, so technically all their method access modifiers should either be package-private or private. > > How about in another PR. None of the `public static ` methods in StringUTF16 or StringLatin1 need to be public. But it will make this PR very noisy for the wrong reasons. Doing that in a separate issue/PR sounds good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073921127 From cushon at openjdk.org Mon May 5 18:04:51 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 5 May 2025 18:04:51 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v10] In-Reply-To: References: <95_0h5qpY-WYbzFlfMqyETLmw3YkiBqh-MltS5-bpMU=.c7020e2e-e322-4b3e-b5d5-919304234e25@github.com> Message-ID: <-WZAftWUFTVZDfqq2bhaMr48JBHkMXy9FWwLNuZBGng=.92e3258e-e8b9-41b9-bc88-54b0d5f29bf8@github.com> On Sat, 26 Apr 2025 04:09:03 GMT, Chen Liang wrote: > I think our next steps are: In early 26, if a corpus search proved no definitive incompatibility, integrate this change and post a message to quality-discuss. Same for #15614. If any incompatibility surfaces, we have sufficient time to rollback. What do you think? That sounds OK to me. I have applied this change to Google's build of OpenJDK and it has been released, we have continued to see no impact to real-world code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2851883053 From rriggs at openjdk.org Mon May 5 18:22:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 May 2025 18:22:47 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:49:20 GMT, Shaojin Wen wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimize StringUTF16.putCharsAt a bit. >> Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt. > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1970: > >> 1968: private static byte[] appendChars(byte[] value, byte coder, int count, char[] s, int off, int end) { >> 1969: if (isLatin1(coder)) { >> 1970: for (int i = off, j = count; i < end; i++) { > > Suggestion: > > int compressed = StringUTF16.compress(s, off, value, count, end - off); > for (int i = compressed + off, j = count + compressed; i < end; i++) { > > Refer to PR #24773, adding StringUTF16.compress preprocessing here will improve the performance of java.io.BufferedReader::readLine method. > > Should it be done at once or separately for PR #24773 to make changes? I rolled this suggestion into ff3d841; and fixed a second occurence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073947019 From duke at openjdk.org Mon May 5 18:28:47 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 5 May 2025 18:28:47 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with three additional commits since the last revision: > > - Fix empty line at the end of a third file > - Fix empty line at the end of another file > - Fix empty line at the end of a file src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 176: > 174: @ForceInline > 175: @Override > 176: public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) { This?probably also?needs `@SuppressWarnings("restricted")`: Suggestion: @ForceInline @Override @SuppressWarnings("restricted") public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) { src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 85: > 83: // specific "basic handle" in the `BASIC_HANDLE_CACHE`. > 84: // returnType in {int.class | long.class} > 85: // stateName can be anything non-null but should be in {"GetLastError" | "WSAGetLastError"} | "errno")} Suggestion: // stateName can be anything non-null but should be in {"GetLastError" | "WSAGetLastError" | "errno"} src/java.base/share/classes/jdk/internal/invoke/MhUtil.java line 88: > 86: public static MethodHandle findStatic(MethodHandles.Lookup lookup, > 87: String name, > 88: MethodType type) { Suggestion: String name, MethodType type) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2073948786 PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2073955345 PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2073949485 From rriggs at openjdk.org Mon May 5 18:38:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 May 2025 18:38:54 GMT Subject: Integrated: 8354334: Remove @ValueBased from ProcessHandle In-Reply-To: References: Message-ID: <9vPLNeBORaD8SOejGUr-cSqD6qf0n6edbgToOSm5YuQ=.06c2e977-ca92-4ae4-96b0-861c49639c18@github.com> On Thu, 1 May 2025 13:36:13 GMT, Roger Riggs wrote: > Remove internal ValueBased annotation from the ProcessHandle interface declaration. > The implementation remains value based as described in the javadoc. > Remove unnecessary "public" keyword in interfaces and cleanup javadoc. This pull request has now been integrated. Changeset: 65f188f2 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/65f188f29f1e9fe0f73d730a4c6029a7742c6d15 Stats: 16 lines in 1 file changed: 0 ins; 3 del; 13 mod 8354334: Remove @ValueBased from ProcessHandle Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/24986 From rriggs at openjdk.org Mon May 5 18:39:51 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 May 2025 18:39:51 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v3] In-Reply-To: References: Message-ID: On Sat, 3 May 2025 13:02:34 GMT, Oleksii Sylichenko wrote: >> This PR proposes three improvements to the `Basic.java` test: >> >> 1. Increase Timeout >> - The current timeout is insufficient when running the test in IntelliJ IDEA. >> - I propose increasing it by one minute. >> - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. >> >> 2. Fix Incompatibility with Windows (Cygwin vs. Native) >> - One of the tests executes the `echo` command. >> - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). >> - I propose replacing echo with `cmd /c echo/`, which produces the same output (a single newline) in Windows, ensuring compatibility. >> >> 3. Prevent Autorun Scripts in the `cmd /c set` Command >> - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. >> - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. >> >> These changes improve test reliability and ensure compatibility across different environments. >> Testing: >> - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. >> - Confirmed that `cmd /c echo/` produces the expected output in Windows. >> - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. >> >> # Detailed Description >> >> ## echo >> The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): >> >> //---------------------------------------------------------------- >> // Test Runtime.exec(...envp...) with envstrings without any `=' >> //---------------------------------------------------------------- >> >> with following error: >> >> Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified >> >> >> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD). >> >> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues. >> >> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo >> >> To ensure that the `echo/` command is supported in Cygwin, we n... > > Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision: > > 8353489: add comment about `echo/`; `cmd` -> `cmd.exe` Looks good, thanks for the update. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23933#pullrequestreview-2815730121 From aturbanov at openjdk.org Mon May 5 18:42:45 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 5 May 2025 18:42:45 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v4] In-Reply-To: <6vv_RfftsMHItY1Fd1m4WFUraAwfYiNui815ORAQL7k=.4e685520-cfc2-49ac-9808-7ed197941fb7@github.com> References: <6vv_RfftsMHItY1Fd1m4WFUraAwfYiNui815ORAQL7k=.4e685520-cfc2-49ac-9808-7ed197941fb7@github.com> Message-ID: On Mon, 5 May 2025 17:47:02 GMT, Raffaello Giulietti wrote: >> _Really_ fails with Xmx7G > > Yes, the required heap size was not enough for the reverted variant to throw a non-OOME exception/error. > > Just out of curiosity, is JDK-8356152 a real-world issue you stumbled upon, or did you encounter it during some testing of yours? I just stumbled at the code, while reviewing other patches. Not a real-world issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073977237 From duke at openjdk.org Mon May 5 18:52:49 2025 From: duke at openjdk.org (duke) Date: Mon, 5 May 2025 18:52:49 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java [v3] In-Reply-To: References: Message-ID: On Sat, 3 May 2025 13:02:34 GMT, Oleksii Sylichenko wrote: >> This PR proposes three improvements to the `Basic.java` test: >> >> 1. Increase Timeout >> - The current timeout is insufficient when running the test in IntelliJ IDEA. >> - I propose increasing it by one minute. >> - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. >> >> 2. Fix Incompatibility with Windows (Cygwin vs. Native) >> - One of the tests executes the `echo` command. >> - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). >> - I propose replacing echo with `cmd /c echo/`, which produces the same output (a single newline) in Windows, ensuring compatibility. >> >> 3. Prevent Autorun Scripts in the `cmd /c set` Command >> - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. >> - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. >> >> These changes improve test reliability and ensure compatibility across different environments. >> Testing: >> - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. >> - Confirmed that `cmd /c echo/` produces the expected output in Windows. >> - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. >> >> # Detailed Description >> >> ## echo >> The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): >> >> //---------------------------------------------------------------- >> // Test Runtime.exec(...envp...) with envstrings without any `=' >> //---------------------------------------------------------------- >> >> with following error: >> >> Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified >> >> >> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD). >> >> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues. >> >> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo >> >> To ensure that the `echo/` command is supported in Cygwin, we n... > > Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision: > > 8353489: add comment about `echo/`; `cmd` -> `cmd.exe` @asilichenko Your change (at version 90752f181b1d8326c854bc06e2108a3751fa225e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23933#issuecomment-2852006051 From duke at openjdk.org Mon May 5 18:59:29 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Mon, 5 May 2025 18:59:29 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2] In-Reply-To: References: Message-ID: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> > JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter. Steffen Nie?ing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8356119 - 8356119: Correct field type for bytecode cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25024/files - new: https://git.openjdk.org/jdk/pull/25024/files/14148dd1..020b062f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25024&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25024&range=00-01 Stats: 1336 lines in 105 files changed: 1096 ins; 102 del; 138 mod Patch: https://git.openjdk.org/jdk/pull/25024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25024/head:pull/25024 PR: https://git.openjdk.org/jdk/pull/25024 From duke at openjdk.org Mon May 5 18:59:29 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Mon, 5 May 2025 18:59:29 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter In-Reply-To: References: Message-ID: On Sun, 4 May 2025 17:20:29 GMT, Eirik Bj?rsn?s wrote: > Nit: Would be nice if the PR title/description made it clear for the casual reader that this is a documentation/Javadoc typo, as opposed to a code issue. Thanks for the hint. I've updated the PR accordingly. > This gives reviewers some feeling of the size/complexity of the PR without actually digging into the code. I've tried to make that clear now. Thanks for the feedback and the nice welcome here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852013683 From duke at openjdk.org Mon May 5 18:59:50 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Mon, 5 May 2025 18:59:50 GMT Subject: Integrated: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 13:34:07 GMT, Oleksii Sylichenko wrote: > This PR proposes three improvements to the `Basic.java` test: > > 1. Increase Timeout > - The current timeout is insufficient when running the test in IntelliJ IDEA. > - I propose increasing it by one minute. > - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. > > 2. Fix Incompatibility with Windows (Cygwin vs. Native) > - One of the tests executes the `echo` command. > - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). > - I propose replacing echo with `cmd /c echo/`, which produces the same output (a single newline) in Windows, ensuring compatibility. > > 3. Prevent Autorun Scripts in the `cmd /c set` Command > - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. > - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. > > These changes improve test reliability and ensure compatibility across different environments. > Testing: > - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. > - Confirmed that `cmd /c echo/` produces the expected output in Windows. > - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. > > # Detailed Description > > ## echo > The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) with envstrings without any `=' > //---------------------------------------------------------------- > > with following error: > > Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified > > > If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD). > > The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues. > > See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo > > To ensure that the `echo/` command is supported in Cygwin, we need to invoke it via `cmd /c`, because Cygwin has its own executable "echo". > > ## cmd.e... This pull request has now been integrated. Changeset: 6bcbc3b0 Author: Oleksii Sylichenko Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/6bcbc3b0a21687504b07a0a405d824a448aea872 Stats: 8 lines in 1 file changed: 2 ins; 1 del; 5 mod 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/23933 From duke at openjdk.org Mon May 5 19:39:44 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Mon, 5 May 2025 19:39:44 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2] In-Reply-To: References: Message-ID: <_WKhVsp3ndefx8j0ngh02e0yvLC9VkN2HPAQTG6tz3I=.64317be2-0b98-4278-9280-25d65c7aaf8c@github.com> On Sun, 4 May 2025 17:01:54 GMT, Chen Liang wrote: > Thanks for the mailing list communication and reply. > > Check out https://openjdk.org/guide/ for more steps. For example, a patch should usually wait 24 hours for sufficient reviews. @liach Thanks for the fast review and the creation of the backing JBS issue. I've updated the PR and checked the tests. As this change is fairly trivial, I think the 24 hours should be enough review time for this one. If you're fine with it, I'd appreciate your sponsor approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852132095 From zuniquex at protonmail.com Mon May 5 20:05:06 2025 From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=) Date: Mon, 05 May 2025 20:05:06 +0000 Subject: JavaDoc: NPE in java.net.http.HttpHeaders Message-ID: Hello, recently I've discovered that the JavaDoc of the instance methods of java.net.http.HttpHeaders lacks the throws declarations for NullPointerExceptions. The static creator method `of` contains such a declaration. So the snippet `HttpHeaders.of(null, null)` is documented to throw an NPE, while the snippet `HttpHeaders.of(Map.of(), (k, v) -> true).firstValue(null)` currently isn't. I'd propose to add the missing JavaDoc throws declarations to the #allValues(String), #firstValueAsLong(String) and #firstValue(String) methods as they all can throw an NPE through `requireNonNull(name);` in the allValues method. If there's interest in this change, I'd appreciate if anyone would like to sponsor me on this one. Cheers, Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.org Mon May 5 20:07:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 5 May 2025 20:07:52 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fine tuning debug log and exception message test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8331008 Should we add 8353888 to all the tests? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074112296 From bpb at openjdk.org Mon May 5 20:13:47 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 May 2025 20:13:47 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <_2ekooJ1JCePIMHLkbFsQRNCkKXXKvAS3dRvOpcLfnA=.6795990f-8a75-4763-902c-8c9f0250ceb0@github.com> On Fri, 2 May 2025 19:00:42 GMT, Stuart Marks wrote: > I think it's still ambiguous. [...] Without addressing the specific comments, I would simply like to point out that "as if" and "equivalent" is common phrasing in this area, e.g., - [File.toPath](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#toPath()) - [Files.newBufferedReader](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#newBufferedReader(java.nio.file.Path)) - etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2074120906 From liach at openjdk.org Mon May 5 20:39:46 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 20:39:46 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Increased min heap size to 8G. Test updates look helpful. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2816032703 From liach at openjdk.org Mon May 5 20:39:46 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 20:39:46 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2] In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> References: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> Message-ID: On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing wrote: >> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter. > > Steffen Nie?ing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8356119 > - 8356119: Correct field type for bytecode cast FYI to integrate, you need to type the `/integrate` command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852273712 From bpb at openjdk.org Mon May 5 20:45:50 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 May 2025 20:45:50 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <7-F1vCVNup1tOkC8CLcuVB9f5aYydrRJMw0fNWFjriE=.60ffa2e0-0aec-4e76-b4a0-6e18506a0333@github.com> On Thu, 1 May 2025 18:00:54 GMT, Stuart Marks wrote: > I'd suggest not having this method's implementation depend on an overridable method. I'm jumping the gun here by referring to an implementation detail, but the overridable method problem could be circumvented using an approach taken in other classes in `java.io`: if (getClass() == BufferedReader.class) { try { return lines().toList(); } catch (UncheckedIOException ue) { // the cause cannot be null throw ue.getCause(); } } else { return super.readAllLines(); } This would not need to be mentioned in the specification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2074159396 From duke at openjdk.org Mon May 5 20:46:46 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Mon, 5 May 2025 20:46:46 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2] In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> References: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> Message-ID: On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing wrote: >> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter. > > Steffen Nie?ing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8356119 > - 8356119: Correct field type for bytecode cast Okay, thanks. From the guide I thought you'd have to enter the `/sponsor` command first before I can `/integrate`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852289475 From duke at openjdk.org Mon May 5 20:49:49 2025 From: duke at openjdk.org (duke) Date: Mon, 5 May 2025 20:49:49 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2] In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> References: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> Message-ID: On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing wrote: >> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter. > > Steffen Nie?ing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8356119 > - 8356119: Correct field type for bytecode cast @zUniQueX Your change (at version 020b062fe8fa544eb5ac37163e82d0aa1db50dfe) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852295782 From duke at openjdk.org Mon May 5 20:54:56 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Mon, 5 May 2025 20:54:56 GMT Subject: Integrated: 8356119: Typo in bytecode behavior for Lookup.findGetter In-Reply-To: References: Message-ID: On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing wrote: > JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter. This pull request has now been integrated. Changeset: 2a4f37cc Author: Steffen Nie?ing Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/2a4f37cc169e0e876b0b463261f84594af4e7569 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8356119: Typo in bytecode behavior for Lookup.findGetter Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/25024 From liach at openjdk.org Mon May 5 20:54:56 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 20:54:56 GMT Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2] In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> References: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com> Message-ID: On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing wrote: >> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter. > > Steffen Nie?ing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8356119 > - 8356119: Correct field type for bytecode cast Thanks for this fix! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852305117 From bpb at openjdk.org Mon May 5 21:00:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 May 2025 21:00:12 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v15] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <4rFHYWIzukqYmTr6jvev9uUpbL1iLUg4OE-JI3oThM0=.22ba7232-9c4f-4399-a6a8-39410bb2d89b@github.com> > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Fix potential NPE in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/dc84bd1b..db338317 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=13-14 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From bpb at openjdk.org Mon May 5 21:00:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 May 2025 21:00:12 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: <5e91fwQ-fvxomq2pltkLuT0EeVaJPH_L4ibc4u6O91c=.03f7a833-0dd2-4427-ab88-b1b88daa4d2a@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <5e91fwQ-fvxomq2pltkLuT0EeVaJPH_L4ibc4u6O91c=.03f7a833-0dd2-4427-ab88-b1b88daa4d2a@github.com> Message-ID: On Fri, 2 May 2025 19:38:11 GMT, R?mi Forax wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test > > test/jdk/java/io/BufferedReader/ReadAll.java line 82: > >> 80: @AfterAll >> 81: public static void cleanup() throws IOException { >> 82: file.delete(); > > If the call to createTempFile() above fails with an exception, file will be null Thanks. Fixed in [db33831](https://github.com/openjdk/jdk/pull/24728/commits/db338317439703e106f06f963eb67f06bf150d28). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2074192348 From aturbanov at openjdk.org Mon May 5 21:01:59 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 5 May 2025 21:01:59 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Increased min heap size to 8G. Marked as reviewed by aturbanov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2816095371 From weijun at openjdk.org Mon May 5 21:03:48 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 May 2025 21:03:48 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 20:04:46 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fine tuning debug log and exception message > > test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 8331008 > > Should we add 8353888 to all the tests? The Virtual Threads JEP didn't. https://github.com/openjdk/jdk/commit/2586f36120317cd206464b1e79d3906f711487cb#diff-35150e3bfd3304405ec403aa29cbea7aaa05c7bab3e28ac92e8162683114746a. I assume we don't either. Bug ids should match changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074195043 From asemenyuk at openjdk.org Mon May 5 21:14:01 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 5 May 2025 21:14:01 GMT Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev wrote: > - It is not clear on which macOS versions codesign fails if application bundle contains additional content. > - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content. > - This change is for macOS only. > - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not. Filed [JDK-8356218](https://bugs.openjdk.org/browse/JDK-8356218) to follow up with the documentation ------------- PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2852348515 From bchristi at openjdk.org Mon May 5 21:37:48 2025 From: bchristi at openjdk.org (Brent Christian) Date: Mon, 5 May 2025 21:37:48 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 335: > 333: * > 334: * @param minCapacity the desired minimum capacity > 335: * @throws OutOfMemoryError if minCapacity is less than zero or new `@params` for added arguments? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074232727 From chen.l.liang at oracle.com Mon May 5 21:46:13 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 5 May 2025 21:46:13 +0000 Subject: JavaDoc: NPE in java.net.http.HttpHeaders In-Reply-To: References: Message-ID: Hello Steffen, I think this is fine. In the package summary of java.net.http, the last sentence says: Unless otherwise stated, null parameter values will cause methods of all classes in this package to throw NullPointerException. The method you mentioned in particular does mention NPE, but that clause aims to cover the edge cases where the headerMap contains null keys, null values, or one of its value List contains null. I think a potential improvement here is to update the package summary to indicate NPE for any nested collection; this is what Class-File API does for java.lang.classfile and the subpackages. Regards, Chen Liang ________________________________ From: core-libs-dev on behalf of Steffen Nie?ing Sent: Monday, May 5, 2025 3:05 PM To: core-libs-dev at openjdk.org Subject: JavaDoc: NPE in java.net.http.HttpHeaders Hello, recently I've discovered that the JavaDoc of the instance methods of java.net.http.HttpHeaders lacks the throws declarations for NullPointerExceptions. The static creator method `of` contains such a declaration. So the snippet `HttpHeaders.of(null, null)` is documented to throw an NPE, while the snippet `HttpHeaders.of(Map.of(), (k, v) -> true).firstValue(null)` currently isn't. I'd propose to add the missing JavaDoc throws declarations to the #allValues(String), #firstValueAsLong(String) and #firstValue(String) methods as they all can throw an NPE through `requireNonNull(name);` in the allValues method. If there's interest in this change, I'd appreciate if anyone would like to sponsor me on this one. Cheers, Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From almatvee at openjdk.org Mon May 5 22:31:48 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 5 May 2025 22:31:48 GMT Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code. src/jdk.jpackage/windows/native/common/MsiUtils.h line 35: > 33: #include > 34: #include > 35: #include Why this include was added? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24868#discussion_r2074290056 From valeriep at openjdk.org Mon May 5 23:10:21 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 5 May 2025 23:10:21 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fine tuning debug log and exception message Looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2816353093 From smarks at openjdk.org Mon May 5 23:36:35 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 5 May 2025 23:36:35 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2] In-Reply-To: References: Message-ID: > Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: > > - overrides and adds locking to SequencedCollection methods; > - performs instance management of reversed synchronized views; > - adds test for race conditions and functional tests of synchronized wrappers. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Reversed view of SynchronizedRandomAccessList should also be RandomAccess. Add tests to ensure RandomAccess is preserved when reversing. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24990/files - new: https://git.openjdk.org/jdk/pull/24990/files/fe351510..1750bb20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=00-01 Stats: 33 lines in 2 files changed: 33 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24990.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24990/head:pull/24990 PR: https://git.openjdk.org/jdk/pull/24990 From smarks at openjdk.org Mon May 5 23:36:36 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 5 May 2025 23:36:36 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2] In-Reply-To: References: Message-ID: On Sun, 4 May 2025 17:51:48 GMT, Luca Kellermann wrote: >> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: >> >> Reversed view of SynchronizedRandomAccessList should also be RandomAccess. >> Add tests to ensure RandomAccess is preserved when reversing. > > src/java.base/share/classes/java/util/Collections.java line 2837: > >> 2835: return reversedView; >> 2836: } >> 2837: } > > `SynchronizedRandomAccessList` overrides `subList`, should it also override `reversed`? Good point, yes it should! At least, it should ensure that the reversed view of a random access synchronized list should also be random access -- which the current code doesn't do. Overriding reversed() in the RA subclass is probably the clearest way to do that. I'll also take the opportunity to expand test coverage, as I don't think the reversed-view-of-RA-is-also-RA is covered anywhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2074366852 From iklam at openjdk.org Mon May 5 23:44:14 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 23:44:14 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes In-Reply-To: <5vOdChaItphSz0dAvDqdniRjHRAAzeUBu2e7rxMkS54=.05079043-e02a-4853-891e-c7d34919af8d@github.com> References: <5vOdChaItphSz0dAvDqdniRjHRAAzeUBu2e7rxMkS54=.05079043-e02a-4853-891e-c7d34919af8d@github.com> Message-ID: On Thu, 1 May 2025 18:52:22 GMT, Andrew Dinn wrote: > @iklam We have seen this problem with Red Hat deployments in jdk24 as well as jdk25-ea. > > I'm saying that mostly for information. However, I do have to ask: If this is fixed for jdk25 is there any question of also fixing it in jdk24? I would be content to receive a no answer -- a similar issue with patch that could be backported from jdk26 -> jdk25 might be something to think about a bit more? Backporting this to jdk 24 would require a lot of effort. I think it might be easier to update CDSHeapVerifier to add more rules to filter out the false positives. CDSHeapVerifier is too conservative and reports error for things that are actually OK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24956#issuecomment-2852698208 From iklam at openjdk.org Mon May 5 23:50:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 23:50:31 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes [v2] In-Reply-To: References: Message-ID: > This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). > > AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues) > > In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table. > > I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Comments from @liach and @ExE-Boss ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24956/files - new: https://git.openjdk.org/jdk/pull/24956/files/0f6a2e0a..a1e3743b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24956&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24956&range=00-01 Stats: 8 lines in 3 files changed: 5 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24956/head:pull/24956 PR: https://git.openjdk.org/jdk/pull/24956 From liach at openjdk.org Mon May 5 23:53:17 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 May 2025 23:53:17 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 23:50:31 GMT, Ioi Lam wrote: >> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). >> >> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues) >> >> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table. >> >> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Comments from @liach and @ExE-Boss The Java code change and the BSM coverage looks good to me. Requiring another reviewer for hotspot changes. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24956#pullrequestreview-2816431978 From iklam at openjdk.org Tue May 6 00:00:22 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 6 May 2025 00:00:22 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 16:21:56 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @vnkozlov comments > > src/hotspot/share/cds/cdsConfig.cpp line 412: > >> 410: log_debug(aot,codecache,init)("AOTCache is not specified - AOTAdapterCaching is ignored"); >> 411: } >> 412: > > Also from merge? That's from the merge. This block doesn't show up when you select "show all commits". > src/hotspot/share/cds/metaspaceShared.cpp line 1018: > >> 1016: CDSConfig::disable_dumping_aot_code(); >> 1017: } >> 1018: > > Is this from merge form mainline? That's from the merge. This block doesn't show up when you select "show all commits". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2074421751 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2074419749 From darcy at openjdk.org Tue May 6 00:04:19 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 May 2025 00:04:19 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v2] In-Reply-To: References: <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com> Message-ID: <8qOP7ec0_eA9d8fV3KdnwM7aTMPis5H_wgr-rc5kxxw=.f6ffced2-54f3-4550-be25-1c2640fe9118@github.com> On Fri, 2 May 2025 17:49:54 GMT, Raffaello Giulietti wrote: > Yes, I'm familiar with both this Java code and the intrinsic code. > > Compare this with the much simpler proposed code. The checked multiplication `unsignedMultiplyExact` apparently performs two 64x64->64 multiplications, but on some architectures it might end up in a single 64x64->128 multiplication and one check. So the proposed code performs 6 such multiplications if the method returns + 5 ordinary multiplications in the worst case. > > As a general rule, the simpler the code, the better the outcome of the optimizing compiler. > > Again, to me there's no point in failing fast at the expense of the successful case. Yes; we can always try to make simpler code faster if the need or interest arises. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2074441059 From kvn at openjdk.org Tue May 6 00:06:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 6 May 2025 00:06:14 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2816460660 From swen at openjdk.org Tue May 6 00:47:16 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 00:47:16 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 185: > 183: if (coder == another.coder) { > 184: return isLatin1(coder) ? StringLatin1.compareTo(val1, val2, count1, count2) > 185: : StringUTF16.compareTo(val1, val2, count1, count2); Suggestion: return isLatin1(coder) ? StringLatin1.compareTo(val1, val2, count1, count2) : StringUTF16.compareTo(val1, val2, count1, count2); As before, align the code src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 188: > 186: } > 187: return isLatin1(coder) ? StringLatin1.compareToUTF16(val1, val2, count1, count2) > 188: : StringUTF16.compareToLatin1(val1, val2, count1, count2); Suggestion: return isLatin1(coder) ? StringLatin1.compareToUTF16(val1, val2, count1, count2) : StringUTF16.compareToLatin1(val1, val2, count1, count2); As before, align the code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074477815 PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074478089 From jwaters at openjdk.org Tue May 6 00:52:12 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 6 May 2025 00:52:12 GMT Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: On Mon, 5 May 2025 22:23:04 GMT, Alexander Matveev wrote: >> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code. > > src/jdk.jpackage/windows/native/common/MsiUtils.h line 35: > >> 33: #include >> 34: #include >> 35: #include > > Why this include was added? It seemed to be needed to compile successfully back when I removed the kludge header (I couldn't figure out why). I can try again without the memory include using GitHub Actions to test instead if that is preferred. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24868#discussion_r2074480472 From jpai at openjdk.org Tue May 6 01:22:13 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 01:22:13 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 238: > 236: * {@return true if the byte array should be replaced due to increased capacity or coder change} > 237: *

    > 238: *
  • The new coder is the different thn the old coder Nit - typo, `thn` should have been `than` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074495916 From jpai at openjdk.org Tue May 6 01:27:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 01:27:14 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: <2fxlcQiP04IDV6Pau09mVCW2D9CVA8VxKPORPIm9zgQ=.c964cb3c-00ec-4316-a71b-6f0e0ac66895@github.com> On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 240: > 238: *
  • The new coder is the different thn the old coder > 239: *
  • The new length is greater than to the current length > 240: *
  • The new length is non-negative, as it might have overflowed due to an increment I think this is a typo too and `non-negative` should have been `negative`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074505941 From asemenyuk at openjdk.org Tue May 6 01:29:15 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 01:29:15 GMT Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect location in the app image Message-ID: - Refactor PathGroup - Add test cases to PathGroupTest - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package - Refactor UsrTreeTest to use JPackageCommand assert functions ------------- Commit messages: - Make JPackageCommand.assertFileInAppImage() public. Test location of the "libapplauncher.so" - Fix bug in PathGroup that resulted in copying "libapplauncher.so" in wrong location Changes: https://git.openjdk.org/jdk/pull/25051/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25051&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356219 Stats: 814 lines in 6 files changed: 641 ins; 64 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/25051.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25051/head:pull/25051 PR: https://git.openjdk.org/jdk/pull/25051 From asemenyuk at openjdk.org Tue May 6 01:29:15 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 01:29:15 GMT Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect location in the app image In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:44:36 GMT, Alexey Semenyuk wrote: > - Refactor PathGroup > - Add test cases to PathGroupTest > - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package > - Refactor UsrTreeTest to use JPackageCommand assert functions @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/25051#issuecomment-2852936934 From almatvee at openjdk.org Tue May 6 01:38:16 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 May 2025 01:38:16 GMT Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: On Tue, 6 May 2025 00:49:35 GMT, Julian Waters wrote: >> src/jdk.jpackage/windows/native/common/MsiUtils.h line 35: >> >>> 33: #include >>> 34: #include >>> 35: #include >> >> Why this include was added? > > It seemed to be needed to compile successfully back when I removed the kludge header (I couldn't figure out why). I can try again without the memory include using GitHub Actions to test instead if that is preferred. I think it is required for `std::unique_ptr` in this file. Strange that it did compiled before. Maybe it was included indirectly somehow. Looks fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24868#discussion_r2074537642 From almatvee at openjdk.org Tue May 6 01:38:15 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 May 2025 01:38:15 GMT Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code. Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24868#pullrequestreview-2816572454 From jpai at openjdk.org Tue May 6 01:41:23 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 01:41:23 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 277: > 275: // copy all bytes to new larger buffer > 276: value = Arrays.copyOf(value, > 277: newCapacity(value, newCoder, minimumCapacity) << newCoder); Would this benefit with an `assert` to verify that the new buffer length being proposed is not lesser than the current buffer's length (thus truncating content). Something like: // copy all bytes to new larger buffer int newLen = newCapacity(value, newCoder, minimumCapacity) << newCoder; assert newLen >= value.length : "bad new length " + newLen + " for buffer's length " + value.length; value = Arrays.copyOf(value, newLen); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074546636 From jpai at openjdk.org Tue May 6 01:53:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 01:53:14 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 309: > 307: if (minimumCapacity - oldCapacity > 0) { > 308: value = Arrays.copyOf(value, > 309: newCapacity(value, coder, minimumCapacity) << coder); Same question about whether we should assert that the new length we determine for the buffer is not lesser than the current buffer length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074579962 From jpai at openjdk.org Tue May 6 02:04:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 02:04:18 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 08:45:06 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? Hello Markus, it's been a while since this PR was merged with latest master branch in mainline. Could you update the PR to do that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2853053662 From darcy at openjdk.org Tue May 6 02:24:17 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 May 2025 02:24:17 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com> Message-ID: <5FwC5VTxPYBUNMq8nPPyFxYQ4BMZzaiVxbm1CW9Zbi8=.1b4c9d8f-642b-4666-9961-d77841e39f8e@github.com> On Thu, 1 May 2025 17:18:07 GMT, Markus KARG wrote: >> There are subtleties and perhaps surprises in `@inheritDoc`, but that doesn't necessarily imply the current behavior is buggy. > > So it is actually *wanted* behavior that in one situation the text *is* inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual. > So it is actually _wanted_ behavior that in one situation the text _is_ inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual. The inheritDoc functionality of javadoc was reworked relatively recently so I would assume the current behavior is intentional, even if not documented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2074634715 From almatvee at openjdk.org Tue May 6 02:48:15 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 May 2025 02:48:15 GMT Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect location in the app image In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:44:36 GMT, Alexey Semenyuk wrote: > - Refactor PathGroup > - Add test cases to PathGroupTest > - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package > - Refactor UsrTreeTest to use JPackageCommand assert functions Looks good with minor comment. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/ApplicationLayout.java line 32: > 30: public record ApplicationLayout(Path launchersDirectory, Path appDirectory, > 31: Path runtimeDirectory, Path runtimeHomeDirectory, Path appModsDirectory, > 32: Path destktopIntegrationDirectory, Path contentDirectory, Path libapplauncher) { `destktop` -> `desktop` ------------- PR Review: https://git.openjdk.org/jdk/pull/25051#pullrequestreview-2816721573 PR Review Comment: https://git.openjdk.org/jdk/pull/25051#discussion_r2074650278 From vlivanov at openjdk.org Tue May 6 02:48:16 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 May 2025 02:48:16 GMT Subject: RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786 In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> Message-ID: <1dojSNtcbxGAxR2KWo_bqJficSV_QsTcWU2xlo3kxE8=.8c9902eb-017b-4aba-a1ae-9b4fb88ba18f@github.com> On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation. > But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime. > > This change the behaviour of existing jdk, and it should not throw exception anyway. > > @iwanowww @RealFYang > > Thanks! Thanks, Li. I think I have a better understanding now how it all works across platforms. I agree with Andrew that it's highly undesireable to have divergence across JDK builds, but I don't have a good understanding how mature toolchain support is when it comes to vector intrinsics SLEEF library relies on. As of now, producing empty native library is the only way to communicate that a vector math library isn't properly built. So, 2 problems to address: (1) JDK build may produce an empty vector math library (and no build failures); (2) vector math library is built unconditionally (there's no way to configure JDK build to skip it). Speaking of SVML, it requires GCC 4.9+ and MSVC 2017. According to JDK build documentation [1], newer toolchain versions are required for JDK build. So, it should be fine to remove GCC version checks. (JDK-8355656 is reported for a JDK build using Clang. I have no idea whether Clang can build SVML stubs or not.) So, the stop-the-gap fix for JDK-8355698 is to disable SLEEF build when toolchain doesn't have proper support. Alternatively, VectorMathLibrary can probe the library to ensure it is not empty [2]. [1] https://github.com/openjdk/jdk/blob/master/doc/building.md [2] diff --git a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java index 4729235e2d9..9f0abb9afa1 100644 --- a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java +++ b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java @@ -189,6 +189,16 @@ public boolean isSupported(Operator op, VectorSpecies vspecies) { private static class SLEEF implements Library { static { VectorSupport.loadNativeLibrary("sleef"); + ensureValidLibrary(); + } + + private static void ensureValidLibrary() { + // Probe an arbitrary entry point to ensure the library is not empty. + // JDK build of SLEEF-based vector math library may produce an empty library when + // proper toolchain support is absent. Until it is fixed, ensure the corresponding + // native library is not empty. + // Throws an exception on lookup failure which triggers a switch to Java-based implementation. + LOOKUP.findOrThrow(LIBRARY.symbolName(VectorOperators.SIN, FloatVector.SPECIES_64)); } private static String suffix(VectorShape vshape, boolean isShapeAgnostic) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2853122819 From asemenyuk at openjdk.org Tue May 6 03:25:07 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 03:25:07 GMT Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect location in the app image [v2] In-Reply-To: References: Message-ID: <2qiByi-Qtb91lGRl1Bv21y6r-kIdsYU3EGMcqRK5qNU=.f138fa2f-e7a1-45cb-8f8e-658df628213c@github.com> > - Refactor PathGroup > - Add test cases to PathGroupTest > - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package > - Refactor UsrTreeTest to use JPackageCommand assert functions Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year - Fix a typo in ApplicationLayout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25051/files - new: https://git.openjdk.org/jdk/pull/25051/files/fa35bfbc..2ef2f889 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25051&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25051&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25051.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25051/head:pull/25051 PR: https://git.openjdk.org/jdk/pull/25051 From asemenyuk at openjdk.org Tue May 6 03:25:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 03:25:08 GMT Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect location in the app image [v2] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 02:36:27 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year >> - Fix a typo in ApplicationLayout > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/ApplicationLayout.java line 32: > >> 30: public record ApplicationLayout(Path launchersDirectory, Path appDirectory, >> 31: Path runtimeDirectory, Path runtimeHomeDirectory, Path appModsDirectory, >> 32: Path destktopIntegrationDirectory, Path contentDirectory, Path libapplauncher) { > > `destktop` -> `desktop` Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25051#discussion_r2074670384 From duke at openjdk.org Tue May 6 03:49:18 2025 From: duke at openjdk.org (duke) Date: Tue, 6 May 2025 03:49:18 GMT Subject: Withdrawn: 8349543: LinkedBlockingDeque does not immediately throw InterrruptedException in put/take In-Reply-To: References: Message-ID: <8pU2ZhgpJaeMTk5IQWbq9CcTNQc402BXIfAjX5T9CFg=.cbc90bd5-0cf7-4a7b-9d87-dce9ba429051@github.com> On Wed, 5 Feb 2025 15:36:15 GMT, kabutz wrote: > The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23464 From duke at openjdk.org Tue May 6 04:25:26 2025 From: duke at openjdk.org (duke) Date: Tue, 6 May 2025 04:25:26 GMT Subject: Withdrawn: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20317 From alan.bateman at oracle.com Tue May 6 06:03:48 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 6 May 2025 07:03:48 +0100 Subject: JavaDoc: NPE in java.net.http.HttpHeaders In-Reply-To: References: Message-ID: On 05/05/2025 21:05, Steffen Nie?ing wrote: > Hello, > > recently I've discovered that the JavaDoc of the instance methods of > java.net.http.HttpHeaders lacks the throws declarations for > NullPointerExceptions. The static creator method `of` contains such a > declaration. So the snippet `HttpHeaders.of(null, null)` is documented > to throw an NPE, while the snippet `HttpHeaders.of(Map.of(), (k, v) -> > true).firstValue(null)` currently isn't. > > I'd propose to add the missing JavaDoc throws declarations to the > #allValues(String), #firstValueAsLong(String) and #firstValue(String) > methods as they all can throw an NPE through `requireNonNull(name);` > in the allValues method. > > If there's interest in this change, I'd appreciate if anyone would > like to sponsor me on this one. > Can you bring this to net-dev to discuss? net-dev is where the networking API and the HTTP client are maintained. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Tue May 6 06:39:13 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 06:39:13 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v4] In-Reply-To: References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: On Mon, 5 May 2025 15:52:38 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 139: >> >>> 137: */ >>> 138: private static OperatingSystem initOS() { >>> 139: // Called lazily, valueOf has overhead >> >> Hello Chen, in context of this bug fix, what kind of overhead does `valueOf()` have? >> The (pre-existing) comment on this `initOS()` method sets an expectation that it will be called from the static initializer of this `OperatingSystem` class and thus it expects an `ExceptionInInitializerError` to be thrown by the static initiliazer, if the operating system name isn't recognized. Any access to `OperatingSystem` class would then have resulted in a `NoClassDefFoundError`. With this proposed change, the callers of `OperatingSystem.current()` would now start seeing an `IllegalArgumentException` if for any reason the operating system name isn't recognized. > > Enum.valueOf -> Class.enumConstantDirectory -> Class.getEnumConstantsShared -> Method.invoke -> MethodHandleAccessorFactory.makeSpecializedTarget(isStatic = true) -> MethodHandles.dropArguments -> LambdaForm.editor -> bytecode generation and loading because this currently cannot be pregenerated by CDS archive. > > If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here. Thank you Chen for updating the issue type of bug. > If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here. The current bug fix I think should just address the incorrect result from `captureCallState()`. If the change to OperatingSystem class has practical improvements to the startup performance, then I think it's worth proposing. I suggest we do it in a separate and independent PR and the discussion and review for that change would have to take into account the existing comment in that class and see if it is no longer necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2074814448 From redestad at openjdk.org Tue May 6 07:47:16 2025 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 6 May 2025 07:47:16 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: Message-ID: <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com> On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Increased min heap size to 8G. LGTM src/java.base/share/classes/java/lang/StringConcatHelper.java line 435: > 433: static String doConcat(String s1, String s2) { > 434: byte coder = (byte) (s1.coder() | s2.coder()); > 435: int newLength = checkOverflow(s1.length() + s2.length()) << coder; Might be mildly inefficient for this case since `checkOverflow` is designed for the compound length+coder `long`. Since this is only used in the simple path it should be easy for JITs to optimize, though. ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2817218650 PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2074907577 From cstein at openjdk.org Tue May 6 08:07:24 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 6 May 2025 08:07:24 GMT Subject: RFR: 8354260: Launcher help text is wrong for -Xms Message-ID: Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage. Copied from the issue: > The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size. > > ```` > $ java -X > ... > -Xms set initial Java heap size > ```` > > From the manpage: > ```` > `-Xms` *size* > : Sets the minimum and the initial size (in bytes) of the heap. This value > must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or > `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G` > to indicate gigabytes. The following examples show how to set the size of > allocated memory to 6 MB using various units: > ```` ------------- Commit messages: - 8354260: Launcher help text is wrong for -Xms Changes: https://git.openjdk.org/jdk/pull/25058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354260 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25058/head:pull/25058 PR: https://git.openjdk.org/jdk/pull/25058 From jwilhelm at openjdk.org Tue May 6 08:13:21 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 6 May 2025 08:13:21 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sun, 4 May 2025 16:21:41 GMT, Markus KARG wrote: >> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. >> >> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Undone copyright update of otherwise unchanged file. > - Update Of.java > > Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise." There is some wording around this topic in the guide already: _In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists](https://openjdk.org/guide/#mailing-lists). Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code._ I've added the suggested text to clarify this paragraph: https://github.com/openjdk/guide/pull/150 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2853649815 From jsikstro at openjdk.org Tue May 6 08:18:12 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 6 May 2025 08:18:12 GMT Subject: RFR: 8354260: Launcher help text is wrong for -Xms In-Reply-To: References: Message-ID: <20rwAIBCR6mR5Jta7t9j54b_GBK8vDJt26816MUjOvs=.92d66219-83fa-405d-be90-ab9a187ed769@github.com> On Tue, 6 May 2025 08:02:21 GMT, Christian Stein wrote: > Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage. > > Copied from the issue: >> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size. >> >> ```` >> $ java -X >> ... >> -Xms set initial Java heap size >> ```` >> >> From the manpage: >> ```` >> `-Xms` *size* >> : Sets the minimum and the initial size (in bytes) of the heap. This value >> must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or >> `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G` >> to indicate gigabytes. The following examples show how to set the size of >> allocated memory to 6 MB using various units: >> ```` Not really my area but I think this is good. Are the localized texts (in `launcher_.properties`) updated at a later time? ------------- Marked as reviewed by jsikstro (Committer). PR Review: https://git.openjdk.org/jdk/pull/25058#pullrequestreview-2817313879 From swen at openjdk.org Tue May 6 08:25:19 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 08:25:19 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com> References: <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com> Message-ID: On Tue, 6 May 2025 07:44:29 GMT, Claes Redestad wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Increased min heap size to 8G. > > src/java.base/share/classes/java/lang/StringConcatHelper.java line 435: > >> 433: static String doConcat(String s1, String s2) { >> 434: byte coder = (byte) (s1.coder() | s2.coder()); >> 435: int newLength = checkOverflow(s1.length() + s2.length()) << coder; > > Might be mildly inefficient for this case since `checkOverflow` is designed for the compound length+coder `long`. Since this is only used in the simple path it should be easy for JITs to optimize, though. @ForceInline static int checkOverflow(int value) { if (value >= 0) { return value; } throw new OutOfMemoryError("Overflow: String length out of range"); } private static long checkOverflow(long lengthCoder) { if ((int)lengthCoder >= 0) { return lengthCoder; } throw new OutOfMemoryError("Overflow: String length out of range"); } @cl4es There are two checkOverflow methods ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2074971917 From swen at openjdk.org Tue May 6 08:44:24 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 08:44:24 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: <5SoKycpAXGw1Z_svDIsGwNXFM25YTooOvASFZjI38xY=.663b5878-597e-437d-b077-80aed0880cde@github.com> On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with three additional commits since the last revision: > > - Fix empty line at the end of a third file > - Fix empty line at the end of another file > - Fix empty line at the end of a file src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 74: > 72: // The Cartesian product : (int.class, long.class) x ("errno", ...) > 73: // Do not use Streams in order to enable "early" use in the init sequence. > 74: for (Class c : List.of(int.class, long.class)) { Suggestion: for (Class c : new Class[] {int.class, long.class}) { Isn't this safer to use during early initialization? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075003232 From rgiulietti at openjdk.org Tue May 6 08:47:14 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 6 May 2025 08:47:14 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com> Message-ID: On Tue, 6 May 2025 08:22:51 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/StringConcatHelper.java line 435: >> >>> 433: static String doConcat(String s1, String s2) { >>> 434: byte coder = (byte) (s1.coder() | s2.coder()); >>> 435: int newLength = checkOverflow(s1.length() + s2.length()) << coder; >> >> Might be mildly inefficient for this case since `checkOverflow` is designed for the compound length+coder `long`. Since this is only used in the simple path it should be easy for JITs to optimize, though. > > @ForceInline > static int checkOverflow(int value) { > if (value >= 0) { > return value; > } > throw new OutOfMemoryError("Overflow: String length out of range"); > } > > private static long checkOverflow(long lengthCoder) { > if ((int)lengthCoder >= 0) { > return lengthCoder; > } > throw new OutOfMemoryError("Overflow: String length out of range"); > } > > @cl4es There are two checkOverflow methods Exactly. The one used here is the (int) variant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2075011584 From swen at openjdk.org Tue May 6 08:50:15 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 08:50:15 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with three additional commits since the last revision: > > - Fix empty line at the end of a third file > - Fix empty line at the end of another file > - Fix empty line at the end of a file src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 390: > 388: return MhUtil.findVirtual(LOOKUP, Arena.class, "close", > 389: MethodType.methodType(void.class)); > 390: } Suggestion: return switch (index) { case NON_NEGATIVE_INT -> MhUtil.findStatic(LOOKUP, "nonNegative", MethodType.methodType(boolean.class, int.class)); case SUCCESS_INT -> MhUtil.findStatic(LOOKUP, "success", MethodType.methodType(int.class, int.class, MemorySegment.class)); case ERROR_INT -> MhUtil.findStatic(LOOKUP, "error", MethodType.methodType(int.class, MethodHandle.class, int.class, MemorySegment.class)); case NON_NEGATIVE_LONG -> MhUtil.findStatic(LOOKUP, "nonNegative", MethodType.methodType(boolean.class, long.class)); case SUCCESS_LONG -> MhUtil.findStatic(LOOKUP, "success", MethodType.methodType(long.class, long.class, MemorySegment.class)); case ERROR_LONG -> MhUtil.findStatic(LOOKUP, "error", MethodType.methodType(long.class, MethodHandle.class, long.class, MemorySegment.class)); case ACQUIRE_ARENA -> MhUtil.findStatic(LOOKUP, "acquireArena", MethodType.methodType(Arena.class)); case ALLOCATE -> MhUtil.findStatic(LOOKUP, "allocate", MethodType.methodType(MemorySegment.class, Arena.class)); case ARENA_CLOSE -> MhUtil.findVirtual(LOOKUP, Arena.class, "close", MethodType.methodType(void.class)); default -> throw new InternalError("Unknown index: " + index); }; Switch statement can be replaced with enhanced 'switch' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075016584 From cstein at openjdk.org Tue May 6 08:59:20 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 6 May 2025 08:59:20 GMT Subject: RFR: 8354260: Launcher help text is wrong for -Xms In-Reply-To: <20rwAIBCR6mR5Jta7t9j54b_GBK8vDJt26816MUjOvs=.92d66219-83fa-405d-be90-ab9a187ed769@github.com> References: <20rwAIBCR6mR5Jta7t9j54b_GBK8vDJt26816MUjOvs=.92d66219-83fa-405d-be90-ab9a187ed769@github.com> Message-ID: On Tue, 6 May 2025 08:15:16 GMT, Joel Sikstr?m wrote: > Are the localized texts (in launcher_.properties) updated at a later time? Yes. We only update the English variant without the `_` classifier; the rest will be translated and updated in pre-release step. See for example "[8347498: JDK 24 RDP2 L10n resource files update](https://bugs.openjdk.org/browse/JDK-8347498)" and the related commit: https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea ------------- PR Comment: https://git.openjdk.org/jdk/pull/25058#issuecomment-2853775647 From pminborg at openjdk.org Tue May 6 09:03:32 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 09:03:32 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values Message-ID: This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. Unfortunately, this PR shows the total commit history for stable values. ------------- Commit messages: - Merge branch 'master' into jep502-followup - Update src/java.base/share/classes/java/lang/StableValue.java - Simplify furhter - Address comments in PR - Merge master - Remove unused method and add comment - Address comments - Merge branch 'master' into jep502-followup - Update link in docs - Remove forgotten line - ... and 372 more: https://git.openjdk.org/jdk/compare/1501a5e4...116ce16c Changes: https://git.openjdk.org/jdk/pull/25004/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356080 Stats: 328 lines in 13 files changed: 211 ins; 46 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/25004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004 PR: https://git.openjdk.org/jdk/pull/25004 From duke at openjdk.org Tue May 6 09:03:34 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 6 May 2025 09:03:34 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values In-Reply-To: References: Message-ID: On Fri, 2 May 2025 13:56:19 GMT, Shaojin Wen wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Unfortunately, this PR shows the total commit history for stable values. > > src/java.base/share/classes/jdk/internal/lang/stable/StableSupplier.java line 62: > >> 60: public String toString() { >> 61: final Object t = delegate.wrappedContentsAcquire(); >> 62: return t == this ? "(this StableSupplier)" : StableValueImpl.renderWrapped(t); > > Suggestion: > > return delegate.wrappedContentsAcquire() == this > ? "(this StableSupplier)" > : StableValueImpl.renderWrapped(t); > > Same as above, simplifying the code by removing local variables that are only used once The?`t`?variable is?used?again in?the?`else` branch?of the?ternary?operator. > src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 108: > >> 106: if (t == null) { >> 107: throw new NoSuchElementException("No contents set"); >> 108: } > > Suggestion: > > if (wrappedContentsAcquire() == null) { > throw new NoSuchElementException("No contents set"); > } > > Same as above, simplifying the code by removing local variables that are only used once `t`?is?passed to?`unwrap` on?the?next?line: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071820465 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071822154 From liach at openjdk.org Tue May 6 09:03:33 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 09:03:33 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values In-Reply-To: References: Message-ID: <7QymLvAbuk2tnG0hkN73Sqmk7RngVqVdbZ4mbeKudQE=.ae0379c8-b362-4a99-92b4-e6049f271c95@github.com> On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote: > This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. > > Unfortunately, this PR shows the total commit history for stable values. src/java.base/share/classes/java/lang/StableValue.java line 387: > 385: * The method {@link #orElseSet(Supplier)} guarantees that the provided > 386: * {@linkplain Supplier} is invoked successfully at most once, even under race. > 387: * Invocations of {@link #orElseSet(Supplier)} (Object)} form a total order of zero or Suggestion: * Invocations of {@link #orElseSet(Supplier)} form a total order of zero or ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2072270481 From swen at openjdk.org Tue May 6 09:03:33 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 09:03:33 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote: > This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. > > Unfortunately, this PR shows the total commit history for stable values. src/java.base/share/classes/java/util/ImmutableCollections.java line 895: > 893: public List subList(int fromIndex, int toIndex) { > 894: int size = size(); > 895: subListRangeCheck(fromIndex, toIndex, size); Suggestion: subListRangeCheck(fromIndex, toIndex, size()); size is only used once, can it be simplified like this? src/java.base/share/classes/java/util/ImmutableCollections.java line 905: > 903: // Todo: Provide a copy free solution > 904: final StableValueImpl[] reversed = Arrays.copyOfRange(delegates, this.offset, this.size - offset); > 905: return StableUtil.renderElements(this, "StableCollection", reversed); Suggestion: return StableUtil.renderElements(this, "StableCollection", Arrays.copyOfRange(deepRoot(root).delegates, this.offset, this.size - offset)); The three local variables `deepRoot/delegates/reversed` are only used once. Can they be simplified like this? src/java.base/share/classes/java/util/ImmutableCollections.java line 932: > 930: final StableValueImpl[] reversed = ArraysSupport.reverse( > 931: Arrays.copyOf(delegates, delegates.length)); > 932: return StableUtil.renderElements(this, "Collection", reversed); Suggestion: final StableValueImpl[] delegates = deepRoot(base).delegates; // Todo: Provide a copy free solution return StableUtil.renderElements(this, "Collection", ArraysSupport.reverse(Arrays.copyOf(delegates, delegates.length))); Same as above, simplifying the code by removing local variables that are only used once src/java.base/share/classes/jdk/internal/lang/stable/StableSupplier.java line 62: > 60: public String toString() { > 61: final Object t = delegate.wrappedContentsAcquire(); > 62: return t == this ? "(this StableSupplier)" : StableValueImpl.renderWrapped(t); Suggestion: return delegate.wrappedContentsAcquire() == this ? "(this StableSupplier)" : StableValueImpl.renderWrapped(t); Same as above, simplifying the code by removing local variables that are only used once src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 54: > 52: // Unsafe offsets for direct field access > 53: > 54: private static final long CONTENT_OFFSET = It should be CONTENTS_OFFSET, right? src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 108: > 106: if (t == null) { > 107: throw new NoSuchElementException("No contents set"); > 108: } Suggestion: if (wrappedContentsAcquire() == null) { throw new NoSuchElementException("No contents set"); } Same as above, simplifying the code by removing local variables that are only used once ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071635586 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071642599 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071648603 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071651874 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071654313 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071656349 From stuefe at openjdk.org Tue May 6 09:06:24 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 6 May 2025 09:06:24 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: On Wed, 30 Apr 2025 17:26:09 GMT, Aleksey Shipilev wrote: > @tstuefe -- I know you love `jspawnhelper` bugs, want to take a look? Love is a strong word :-) I missed this one. I will take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2853797278 From swen at openjdk.org Tue May 6 09:24:23 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 09:24:23 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with three additional commits since the last revision: > > - Fix empty line at the end of a third file > - Fix empty line at the end of another file > - Fix empty line at the end of a file src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 306: > 304: @ForceInline > 305: private static int success(int value, > 306: MemorySegment segment) { Suggestion: private static long success(long value, MemorySegment segment) { Newline separation is not necessary here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075073938 From swen at openjdk.org Tue May 6 09:28:13 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 09:28:13 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Mon, 5 May 2025 17:13:02 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with three additional commits since the last revision: > > - Fix empty line at the end of a third file > - Fix empty line at the end of another file > - Fix empty line at the end of a file src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 103: > 101: } > 102: return returnType; > 103: } Suggestion: static Class returnType(MethodHandle target) { // Implicit null check final MethodType type = target.type(); final Class returnType = type.returnType(); if (!(returnType.equals(int.class) || returnType.equals(long.class))) { throw illegalArgDoesNot(target, "return an int or a long"); } if (type.parameterCount() == 0 || type.parameterType(0) != MemorySegment.class) { throw illegalArgDoesNot(target, "have a MemorySegment as the first parameter"); } return returnType; } If returnType uses a local variable, type also uses a local variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075081366 From swen at openjdk.org Tue May 6 09:38:15 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 09:38:15 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 16:44:02 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review remarks src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 59: > 57: MemoryLayout[] stateLayouts = new MemoryLayout[supported.size()]; > 58: @SuppressWarnings({"unchecked", "rawtypes"}) > 59: Map.Entry[] entries = new Map.Entry[supported.size()]; Suggestion: CapturableState[] supported; if (OperatingSystem.isWindows()) { supported = new CapturableState[] { new CapturableState("GetLastError", JAVA_INT, 1 << 0), new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1), new CapturableState("errno", JAVA_INT, 1 << 2) }; } else { supported = new CapturableState[] {new CapturableState("errno", JAVA_INT, 1 << 2)}; } MemoryLayout[] stateLayouts = new MemoryLayout[supported.length]; @SuppressWarnings({"unchecked", "rawtypes"}) Map.Entry[] entries = new Map.Entry[supported.length]; Here it might be better to replace List with an array src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 84: > 82: if (ret == null) { > 83: throw new IllegalArgumentException( > 84: "Unknown name: " + name +", must be one of: " Suggestion: "Unknown name: " + name + ", must be one of: " space ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075096871 PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075097771 From redestad at openjdk.org Tue May 6 10:09:13 2025 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 6 May 2025 10:09:13 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com> Message-ID: On Tue, 6 May 2025 08:44:56 GMT, Raffaello Giulietti wrote: >> @ForceInline >> static int checkOverflow(int value) { >> if (value >= 0) { >> return value; >> } >> throw new OutOfMemoryError("Overflow: String length out of range"); >> } >> >> private static long checkOverflow(long lengthCoder) { >> if ((int)lengthCoder >= 0) { >> return lengthCoder; >> } >> throw new OutOfMemoryError("Overflow: String length out of range"); >> } >> >> @cl4es There are two checkOverflow methods > > Exactly. The one used here is the (int) variant. D'oh, missed that it's been added since it's not co-located in the source. Sorry for the noise! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2075147358 From vklang at openjdk.org Tue May 6 10:21:21 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 6 May 2025 10:21:21 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v4] In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 03:22:28 GMT, He-Pin(kerr) wrote: >> Motivation: >> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. >> >> Modification: >> Add detail error messages. >> >> Result: >> Helpful messages. > > He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision: > > chore: fix test error with the help of klang src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java line 158: > 156: private T doInvokeAny(Collection> tasks, > 157: boolean timed, long nanos) > 158: throws InterruptedException, ExecutionException, TimeoutException, NullPointerException { NullPointerException is a RuntimeException Suggestion: throws InterruptedException, ExecutionException, TimeoutException { src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java line 264: > 262: @Override > 263: public List> invokeAll(Collection> tasks) > 264: throws InterruptedException , NullPointerException { NullPointerException is a RuntimeException Suggestion: throws InterruptedException { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r2075163173 PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r2075163888 From redestad at openjdk.org Tue May 6 11:06:20 2025 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 6 May 2025 11:06:20 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: <8KfOLnQ42AcdAR0mP0ileW5-4LOnUniljRRdZq3zB7o=.1d7338a6-deb9-4b35-bec5-7bc225611d72@github.com> On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test Changes LGTM While this PR fixes the bug reported in JDK-8355975 I'm not sure how the changes in JDK-8243254 are to blame for that particular bug. This since no aspect of the charset was part of `Key` before. The provided test case fails in an unrelated way (unmappable character) when I try building and testing on JDK 8 and 11, though. It would be good to make sure this is not an issue on older JDKs? ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2817852104 From jpai at openjdk.org Tue May 6 11:16:17 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 11:16:17 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test Hello Claes, thank you for the review. > While this PR fixes the bug reported in JDK-8355975 I'm not sure how the changes in JDK-8243254 are to blame for that particular bug. This since no aspect of the charset was part of Key before. You are right and I've updated the JBS issue to correct myself that 8355975 isn't the cause for this and it likely exists even in older versions. I overlooked that even though 8355975 introduced the charset to be part of the `Key`, the underlying issue relates to considering two `ZipFile` instances opened with different `Charset`s as having the same entry names. > The provided test case fails in an unrelated way (unmappable character) when I try building and testing on JDK 8 and 11, though. It would be good to make sure this is not an issue on older JDKs? I will take a look at why it fails with that error on those versions and see if the test can be adjusted (outside of this PR) for those releases. Thank you everyone for the reviews and the inputs. Alan had started reviewing this last week, so I'll wait for his review before integrating this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2854182588 From jpai at openjdk.org Tue May 6 11:23:20 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 11:23:20 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test Hello Eirik, > Neither the RandomAccessFile nor the CEN bytes change between different charsets so I believe there may be potential for some untangling and simplification here. ... > But that?s for another PR :) You are right and I noticed that and a few other related things when working on this change. Given the role this ZIP/JAR parsing code plays in the JDK and various historical iterations it has gone through, doing any refactoring would be better done in independent and reasonably sized chunks if possible. I haven't however done a thorough analysis of whether it's feasible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2854200203 From duke at openjdk.org Tue May 6 11:25:20 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 11:25:20 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: <5FwC5VTxPYBUNMq8nPPyFxYQ4BMZzaiVxbm1CW9Zbi8=.1b4c9d8f-642b-4666-9961-d77841e39f8e@github.com> References: <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com> <5FwC5VTxPYBUNMq8nPPyFxYQ4BMZzaiVxbm1CW9Zbi8=.1b4c9d8f-642b-4666-9961-d77841e39f8e@github.com> Message-ID: On Tue, 6 May 2025 02:21:20 GMT, Joe Darcy wrote: >> So it is actually *wanted* behavior that in one situation the text *is* inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual. > >> So it is actually _wanted_ behavior that in one situation the text _is_ inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual. > > The inheritDoc functionality of javadoc was reworked relatively recently so I would assume the current behavior is intentional, even if not documented. Understood. Thank you for clarifying, Joe! :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2075255586 From duke at openjdk.org Tue May 6 11:25:19 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 11:25:19 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 02:01:24 GMT, Jaikiran Pai wrote: > Hello Markus, it's been a while since this PR was merged with latest master branch in mainline. Could you update the PR to do that? As rebasing is not wanted in OpenJDK, do you mean merging `master` branch into *this* branch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2854207317 From jpai at openjdk.org Tue May 6 11:33:23 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 11:33:23 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com> On Tue, 6 May 2025 11:23:01 GMT, Markus KARG wrote: > do you mean merging master branch into this branch? Yes, that's correct. That should then run the GitHub actions job against this PR against a more relevant state of this PR. Since things have settled and the CSR approved, I'll also run this PR against our CI to verify nothing fails unexpectedly. I will anyway be doing the merge against master locally before submitting for tier testing, but it's always a good practice to keep the PR updated with latest master changes, when the master branch has seen too many commits since the PR was opened. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2854228917 From pminborg at openjdk.org Tue May 6 11:48:13 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 11:48:13 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations Message-ID: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. ------------- Commit messages: - Address comments - Document field alignment assumption - Add unhecked call test - Move raw factories into inner class Raw - Add copyright header and revert unintended change - Add examples to doc and fix tests - Add @Stable for URI and add benchmark - Rename classes - Initial commit Changes: https://git.openjdk.org/jdk/pull/25040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356255 Stats: 904 lines in 10 files changed: 868 ins; 26 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From pminborg at openjdk.org Tue May 6 11:48:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 11:48:15 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Mon, 5 May 2025 13:41:22 GMT, Per Minborg wrote: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Benchmarks: Benchmark Mode Cnt Score Error Units StableUpdatersBenchmark.base avgt 10 0.715 ? 0.026 ns/op StableUpdatersBenchmark.updater avgt 10 0.716 ? 0.079 ns/op Which shows the updater has the same performance as imperative code which is good. Updated benchmarks: Benchmark Mode Cnt Score Error Units StableUpdatersBenchmark.base avgt 10 0.838 ? 0.041 ns/op StableUpdatersBenchmark.baseStatic avgt 10 0.759 ? 0.088 ns/op StableUpdatersBenchmark.updater avgt 10 0.888 ? 0.086 ns/op StableUpdatersBenchmark.updaterStatic avgt 10 0.753 ? 0.017 ns/op StableUpdatersBenchmark.uri avgt 10 0.781 ? 0.206 ns/op StableUpdatersBenchmark.uriStatic avgt 10 0.724 ? 0.048 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2851073331 PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2853800652 From liach at openjdk.org Tue May 6 11:48:14 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 11:48:14 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Mon, 5 May 2025 13:41:22 GMT, Per Minborg wrote: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Changes requested by liach (Reviewer). src/java.base/share/classes/java/lang/reflect/Method.java line 101: > 99: > 100: private static final ToIntFunction HASH_UPDATER = > 101: StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction() { If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)? ------------- PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2815145097 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2073631615 From pminborg at openjdk.org Tue May 6 11:48:16 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 11:48:16 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Mon, 5 May 2025 15:04:54 GMT, Chen Liang wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > src/java.base/share/classes/java/lang/reflect/Method.java line 101: > >> 99: >> 100: private static final ToIntFunction HASH_UPDATER = >> 101: StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction() { > > If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)? Do you mean for interacting with the field or computing the hash? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075052972 From liach at openjdk.org Tue May 6 11:48:17 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 11:48:17 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com> On Tue, 6 May 2025 09:09:50 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/lang/reflect/Method.java line 101: >> >>> 99: >>> 100: private static final ToIntFunction HASH_UPDATER = >>> 101: StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction() { >> >> If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)? > > Do you mean for interacting with the field or computing the hash? Calling the method that computes hash. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075217957 From pminborg at openjdk.org Tue May 6 11:48:17 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 11:48:17 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com> Message-ID: On Tue, 6 May 2025 10:55:22 GMT, Chen Liang wrote: >> Do you mean for interacting with the field or computing the hash? > > Calling the method that computes hash. This would require another implementation to be written. Maybe we can add that later? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075271947 From swen at openjdk.org Tue May 6 11:48:19 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 11:48:19 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Mon, 5 May 2025 13:41:22 GMT, Per Minborg wrote: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. src/java.base/share/classes/java/lang/reflect/Method.java line 105: > 103: public int applyAsInt(Method method) { > 104: return method.getDeclaringClass().getName().hashCode() ^ method.getName() > 105: .hashCode(); Suggestion: return method.getDeclaringClass().getName().hashCode() ^ method.getName().hashCode(); code indentation alignment src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 330: > 328: throw illegalField("non final fields", field); > 329: } > 330: sun.reflect.misc.ReflectUtil.ensureMemberAccess( Why not use import here but use the full path? src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 350: > 348: } > 349: final Field[] fields = holderType.getDeclaredFields(); > 350: for (Field f : fields) { Suggestion: for (Field f : holderType.getDeclaredFields()) { The local variable fields is only used once and can be simplified test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 132: > 130: Objects.equals(this.bar, that.bar) && > 131: Objects.equals(this.baz, that.baz); > 132: } Suggestion: public boolean equals(Object o) { return o instanceof Foo that && Objects.equals(this.bar, that.bar) && Objects.equals(this.baz, that.baz); } In most cases in JDK code, the operator `&&` is placed in front. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075244737 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075229805 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075234183 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075239678 From pminborg at openjdk.org Tue May 6 11:58:14 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 11:58:14 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: References: Message-ID: <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com> On Mon, 5 May 2025 16:44:02 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review remarks src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 81: > 79: > 80: public static CapturableState forName(String name) { > 81: var ret = LOOKUP.get(name); As we usually have just one element (and for Windows three elements) it might be both less memory consuming and faster to just search a `@Stable` array linearly rather than having a Map. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075308234 From pminborg at openjdk.org Tue May 6 12:02:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 12:02:15 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 16:44:02 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review remarks src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 88: > 86: > 87: // The current OperatingSystem > 88: private static @Stable OperatingSystem CURRENT_OS; Could this be a `StableValue.supplier()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075313499 From stuefe at openjdk.org Tue May 6 12:03:26 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 6 May 2025 12:03:26 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev wrote: >> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. >> >> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. >> >> I am very open to bike-shedding about the actual message :) >> >> Additional testing: >> - [x] Ad-hoc experiments with breaking jspawnhelper >> - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` > > 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 six additional commits since the last revision: > > - Add bug ID > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Pull message into a field > - Test cases > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Initial fix > > Good spawnhelper failure message > > Trying tests > > Print helper message on all IOExceptions > > Final Makes sense. I recently looked into this because of signal handling issues. I planned to add logging to jspawnhelper. I had done similar work at SAP, and we found it really useful. My very pragmatic plan was to define an environment variable that would name the name of a file; the variable's existence would then signal logging=on to jspawnhelper and it would log into this file. Since we can have process trees, every file name would get the pid of the process attached. Of course, care must be taken around exec (close the file before exec as to not inherit it; re-open it for some last logging after exec errors) and when passing around this variable (must be excluded from any environment var cleansing we do). Bit tricky but no rocket science. I will do it when I find the time. Of course, all of that does not help customers who don't contact support; for them, the exception text is the sole info. This would be more of a tool for us than for them. src/java.base/unix/native/libjava/ProcessImpl_md.c line 346: > 344: if (ret != EINVAL) > 345: detail = tmpbuf; > 346: } Pre-existing, possibly as follow-up: I wonder whether we can do more. I don't like how we either only print out the errno string, or only print out the "Default" detail (I don't like the "default" prefix since it's really useful context information about this errno). For a problem on this side, we mostly pass in errno, then swallow the "defaultdetail". E.g. for posix_spawn failure, we'd print e.g. "12:Out of memory\nPossible reasons: ... " (or whatever localized string strerror returns). For errors that happen inside the jspawnhelper (see line 790ff where we pass 0 for the errno), we print out "0:Bad code from spawn helper\nPossible reasons: ... ", so we swallow the errno we got from the jspawnhelper. Could we print out instead the default, then the errno string, then the Possible reasons text? E.g. "posix_spawn failed (12:Out of memory)\nPossible reasons: ..." or "Bad code from spawn helper (12:Out of memory)\nPossible reasons: ..." There is an issue of errnum values from the far side possibly intersecting with valid errno. Could be solved simply by assigning negative values to ERR_MALLOC, ERR_PIPE and ERR_ARGS. I am not aware of any errno values being negative. The errno printing would need to recognise these three values in addition to errno values. We also could remove the +3 workaround in the test. The only argument I see against is some vague form of backward compatibility, in case people get confused about the new information, or that existing tools parse this output. src/java.base/unix/native/libjava/ProcessImpl_md.c line 348: > 346: } > 347: /* ASCII Decimal representation uses 2.4 times as many bits as binary. */ > 348: fmtsize = sizeof(IOE_FORMAT) + strlen(internalErrorDetail) + strlen(detail) + 3 * sizeof(errnum); Suggestion: fmtsize = sizeof(IOE_FORMAT) + 3 * sizeof(errnum) + strlen(detail) + strlen(internalErrorDetail) + 1; ... just to appease my OCD. src/java.base/unix/native/libjava/ProcessImpl_md.c line 351: > 349: errmsg = NEW(char, fmtsize); > 350: if (errmsg == NULL) > 351: return; Preexisting: seems to be weird to just quietly swallow the allocation error. src/java.base/unix/native/libjava/ProcessImpl_md.c line 377: > 375: throwIOExceptionImpl(env, errnum, defaultDetail, ""); > 376: } > 377: } Why only for POSIX_SPAWN? We use jspawnhelper also for fork/vfork+exec. ------------- PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2817819896 PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075257935 PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075220275 PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075224053 PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075211949 From liach at openjdk.org Tue May 6 12:10:14 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 12:10:14 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 11:59:29 GMT, Per Minborg wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Review remarks > > src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 88: > >> 86: >> 87: // The current OperatingSystem >> 88: private static @Stable OperatingSystem CURRENT_OS; > > Could this be a `StableValue.supplier()`? I would rather optimize MethodHandleAccessorFactory than defining a new class for this... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075326990 From pminborg at openjdk.org Tue May 6 12:20:16 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 12:20:16 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Mon, 5 May 2025 18:21:44 GMT, ExE Boss wrote: >> Per Minborg has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fix empty line at the end of a third file >> - Fix empty line at the end of another file >> - Fix empty line at the end of a file > > src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 176: > >> 174: @ForceInline >> 175: @Override >> 176: public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) { > > This?probably also?needs `@SuppressWarnings("restricted")`: > Suggestion: > > @ForceInline > @Override > @SuppressWarnings("restricted") > public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) { I can't see why that is needed? Which restricted method is called by this method? What did I miss? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075344707 From pminborg at openjdk.org Tue May 6 12:24:17 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 12:24:17 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Tue, 6 May 2025 09:21:24 GMT, Shaojin Wen wrote: >> Per Minborg has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fix empty line at the end of a third file >> - Fix empty line at the end of another file >> - Fix empty line at the end of a file > > src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 306: > >> 304: @ForceInline >> 305: private static int success(int value, >> 306: MemorySegment segment) { > > Suggestion: > > private static long success(long value, MemorySegment segment) { > > Newline separation is not necessary here I've taken the approach to always separate parameters in this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075353554 From liach at openjdk.org Tue May 6 12:26:13 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 12:26:13 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com> Message-ID: On Tue, 6 May 2025 11:33:27 GMT, Per Minborg wrote: >> Calling the method that computes hash. > > This would require another implementation to be written. Maybe we can add that later? I feel like declaring a function is declaring redundant classes when we can just reuse a DirectMethodHandle pointing to an actual method. Also the zero alternative should be handled by the provided computing function/method instead of handled by this utility. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075357802 From pminborg at openjdk.org Tue May 6 12:32:38 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 12:32:38 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v4] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/07a39db9..6b26ef6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=02-03 Stats: 17 lines in 3 files changed: 10 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Tue May 6 12:32:39 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 12:32:39 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Tue, 6 May 2025 08:47:54 GMT, Shaojin Wen wrote: >> Per Minborg has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fix empty line at the end of a third file >> - Fix empty line at the end of another file >> - Fix empty line at the end of a file > > src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 390: > >> 388: return MhUtil.findVirtual(LOOKUP, Arena.class, "close", >> 389: MethodType.methodType(void.class)); >> 390: } > > Suggestion: > > return switch (index) { > case NON_NEGATIVE_INT -> MhUtil.findStatic(LOOKUP, "nonNegative", > MethodType.methodType(boolean.class, int.class)); > case SUCCESS_INT -> MhUtil.findStatic(LOOKUP, "success", > MethodType.methodType(int.class, int.class, MemorySegment.class)); > case ERROR_INT -> MhUtil.findStatic(LOOKUP, "error", > MethodType.methodType(int.class, MethodHandle.class, int.class, MemorySegment.class)); > case NON_NEGATIVE_LONG -> MhUtil.findStatic(LOOKUP, "nonNegative", > MethodType.methodType(boolean.class, long.class)); > case SUCCESS_LONG -> MhUtil.findStatic(LOOKUP, "success", > MethodType.methodType(long.class, long.class, MemorySegment.class)); > case ERROR_LONG -> MhUtil.findStatic(LOOKUP, "error", > MethodType.methodType(long.class, MethodHandle.class, long.class, MemorySegment.class)); > case ACQUIRE_ARENA -> MhUtil.findStatic(LOOKUP, "acquireArena", > MethodType.methodType(Arena.class)); > case ALLOCATE -> MhUtil.findStatic(LOOKUP, "allocate", > MethodType.methodType(MemorySegment.class, Arena.class)); > case ARENA_CLOSE -> MhUtil.findVirtual(LOOKUP, Arena.class, "close", > MethodType.methodType(void.class)); > default -> throw new InternalError("Unknown index: " + index); > }; > > Switch statement can be replaced with enhanced 'switch' I have the old switch format in anticipation of faster startup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075368639 From jpai at openjdk.org Tue May 6 13:06:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 13:06:14 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com> On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. I see that in the proposed changes, we are now using the same names for these local variables and method parameters as the field names. Would using different names for these local variables be better? To avoid shadowing the field names (`value`, `coder` and `count`)? I think that could help prevent future (accidental) refactoring changes that end up unintentionally accessing fields instead of local variables. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2854499902 From jpai at openjdk.org Tue May 6 13:47:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 13:47:15 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1867: > 1865: * {@return Return the buffer containing the composed string and inserted characters} > 1866: * If the buffer coder needs to support UTF16 and does not, it is inflated and a different > 1867: * buffer is returned. TThe caller is responsible for setting the coder and updating the value ref Typo - Should have been `The` instead of `TThe` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075514598 From jpai at openjdk.org Tue May 6 13:58:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 13:58:15 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: <5eu74f7XoVq24VDlPHV92U-sEq3R5Wz6SbZ53_tg5TE=.18913c00-cf54-4724-b916-adcb5e40dc04@github.com> On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. test/jdk/java/lang/StringBuilder/StressSBTest.java line 76: > 74: * > 75: * @param numThreads the number of threads > 76: * @param duration a Duratio, typically a few seconds Typo - should have been `a Duration, ...` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075538136 From jpai at openjdk.org Tue May 6 14:03:25 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 14:03:25 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. Some of the files will need a copyright year update. test/jdk/java/lang/StringBuilder/StressSBTest.java line 72: > 70: /** > 71: * Stress test using a number of platform threads for a duration. > 72: * Success is marked by a lack of exceptions. If I'm reading the test correctly, then the exceptions that happen in the launched thread are merely logged and thus the test will never throw any exceptions and will never fail? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2854691855 PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075546963 From duke at openjdk.org Tue May 6 14:15:15 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 6 May 2025 14:15:15 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Mon, 5 May 2025 13:41:22 GMT, Per Minborg wrote: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 214: > 212: } > 213: Objects.requireNonNull(underlying); > 214: return new StableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement); This?should probably?construct `TearingStableLongFieldUpdater` on?32?bit?platforms: Suggestion: if (Architecture.is64bit()) { // We are also relying on the fact that the VM will not place 64-bit // instance fields that can cross cache lines. return new StableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement); } else { return new TearingStableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075572314 From ihse at openjdk.org Tue May 6 14:16:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 14:16:32 GMT Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3] In-Reply-To: References: Message-ID: > As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII. Magnus Ihse Bursie 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 restore-more-ascii - Remove incorrectly copied "?anchor" - 8354273: Restore even more pointless unicode characters to ASCII ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24567/files - new: https://git.openjdk.org/jdk/pull/24567/files/876708c2..a07ef96d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24567&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24567&range=01-02 Stats: 273049 lines in 2453 files changed: 80961 ins; 183018 del; 9070 mod Patch: https://git.openjdk.org/jdk/pull/24567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24567/head:pull/24567 PR: https://git.openjdk.org/jdk/pull/24567 From mbaesken at openjdk.org Tue May 6 14:18:25 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 May 2025 14:18:25 GMT Subject: Integrated: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float divisions by zero on AIX In-Reply-To: References: Message-ID: <6wqzprQ0jouL5AXs6K7EYvgMQbr_BawkG6fB5oO2kG0=.1720fa45-21a9-4de9-8758-d52bb510e8ac@github.com> On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken wrote: > Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero. > At least this is the case on AIX. > > (seen in the jtreg test java/lang/Math/PowTests.java ) This pull request has now been integrated. Changeset: 088825ed Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/088825ed889551e6067d46bf77fe4d30a3972da1 Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float divisions by zero on AIX Reviewed-by: jkern, lucy ------------- PR: https://git.openjdk.org/jdk/pull/24963 From liach at openjdk.org Tue May 6 14:36:03 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 14:36:03 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v6] In-Reply-To: References: Message-ID: > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states - rollback OS - Review remarks - No env to test - Unchecked - Further revamp, remove unnecessary instances on irrelevant platforms - Bugid - 8356126: Revisit CaptureCallState ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/d1598afa..2ead9d6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=04-05 Stats: 2943 lines in 162 files changed: 2315 ins; 163 del; 465 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From rriggs at openjdk.org Tue May 6 14:38:21 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 May 2025 14:38:21 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti wrote: >> A fix to throw `OutOfMemoryError`, as done in releases ? 23. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Increased min heap size to 8G. Looks good, thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2818538058 From pminborg at openjdk.org Tue May 6 14:40:46 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 May 2025 14:40:46 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v2] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix raw long updater under 32-bit mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/33e1779c..52e96c52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=00-01 Stats: 21 lines in 1 file changed: 12 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From rriggs at openjdk.org Tue May 6 15:00:25 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 May 2025 15:00:25 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Tue, 6 May 2025 01:38:21 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 277: > >> 275: // copy all bytes to new larger buffer >> 276: value = Arrays.copyOf(value, >> 277: newCapacity(value, newCoder, minimumCapacity) << newCoder); > > Would this benefit with an `assert` to verify that the new buffer length being proposed is not lesser than the current buffer's length (thus truncating content). Something like: > > > // copy all bytes to new larger buffer > int newLen = newCapacity(value, newCoder, minimumCapacity) << newCoder; > assert newLen >= value.length : "bad new length " + newLen + " for buffer's length " + value.length; > value = Arrays.copyOf(value, newLen); I'd be concerned about bloating the code size for a check that will not be triggered. `growth` is non-negative and `newCapacity()` uses the same comparison to determine its growth value. If ArraySupport.newLength can't satisify the request, it will throw. > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 309: > >> 307: if (minimumCapacity - oldCapacity > 0) { >> 308: value = Arrays.copyOf(value, >> 309: newCapacity(value, coder, minimumCapacity) << coder); > > Same question about whether we should assert that the new length we determine for the buffer is not lesser than the current buffer length. ditto, will not return a shorter array, it will throw instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075667207 PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075668360 From rriggs at openjdk.org Tue May 6 15:10:19 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 May 2025 15:10:19 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com> Message-ID: On Tue, 6 May 2025 13:03:37 GMT, Jaikiran Pai wrote: > I see that in the proposed changes, we are now using the same names for these local variables and method parameters as the field names. Would using different names for these local variables be better? To avoid shadowing the field names (`value`, `coder` and `count`)? I think that could help prevent future (accidental) refactoring changes that end up unintentionally accessing fields instead of local variables. A valid concern. Opinions vary about the value/risk of shadowing. Here the code is more readable using the familiar field names for all of the computations and highlighting the use of `this.` to identify the copying out of and into the fields while reviewing and auditing the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2854917666 From ihse at openjdk.org Tue May 6 15:12:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:12:19 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: <9Q_tHeUczynfbPen9yg52qG1NY6z_jVXFgIEnPcsh84=.7544bce2-ed3d-47fe-bb00-5c23bad638a8@github.com> On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato wrote: >>> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment) >> >> Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README. >> >> Is there some specific problem you are worried about on Windows that you were thinking about? > >> Is there some specific problem you are worried about on Windows that you were thinking about? > > I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas. @naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale. I'll ping Yi Yang who was behind https://github.com/openjdk/jdk/pull/3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before. @y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2854924350 From rriggs at openjdk.org Tue May 6 15:23:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 May 2025 15:23:39 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: References: Message-ID: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Apply reviewer suggestions for typos, javadoc, and copyright dates. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/80992a20..efd6fed1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=04-05 Stats: 9 lines in 3 files changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From duke at openjdk.org Tue May 6 15:23:39 2025 From: duke at openjdk.org (Johannes Graham) Date: Tue, 6 May 2025 15:23:39 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: <6fwx-RiRnE_IhQacZgAPnrF4S5Bd4DG7mw79RxZCea8=.4a62d7e4-d5ef-4301-bc08-c284167782d1@github.com> On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2101: > 2099: } > 2100: > 2101: private AbstractStringBuilder repeat(char c, int count) { How about renaming the `count` parameter here so that it is obviously distinct from the meaning of `count` elsewhere in this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075710531 From rriggs at openjdk.org Tue May 6 15:23:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 May 2025 15:23:39 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> Message-ID: On Tue, 6 May 2025 13:59:40 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. > > test/jdk/java/lang/StringBuilder/StressSBTest.java line 72: > >> 70: /** >> 71: * Stress test using a number of platform threads for a duration. >> 72: * Success is marked by a lack of exceptions. > > If I'm reading the test correctly, then the exceptions that happen in the launched thread are merely logged and thus the test will never throw any exceptions and will never fail? Yes, the logging is there to help assess how often racy use results in unpredictable (exception) behavior. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075705736 From ihse at openjdk.org Tue May 6 15:25:43 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:25:43 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v4] In-Reply-To: References: Message-ID: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Add informative message about supported locales. - Allow C locale with warning instead of fatal error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24574/files - new: https://git.openjdk.org/jdk/pull/24574/files/452f42dc..9ce59e1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24574.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574 PR: https://git.openjdk.org/jdk/pull/24574 From jpai at openjdk.org Tue May 6 15:29:16 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 15:29:16 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com> Message-ID: <3PXIAd_Exlyp5GTGdYJgbEhWjHmeXtbhgiHmwVBPo3s=.f7c9f696-ea2e-4222-81c5-5616f65c8bae@github.com> On Tue, 6 May 2025 15:07:25 GMT, Roger Riggs wrote: > > I see that in the proposed changes, we are now using the same names for these local variables and method parameters as the field names. Would using different names for these local variables be better? To avoid shadowing the field names (`value`, `coder` and `count`)? I think that could help prevent future (accidental) refactoring changes that end up unintentionally accessing fields instead of local variables. > > A valid concern. Opinions vary about the value/risk of shadowing. Here the code is more readable using the familiar field names for all of the computations and highlighting the use of `this.` to identify the copying out of and into the fields while reviewing and auditing the code. Fair enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2855021639 From rriggs at openjdk.org Tue May 6 15:29:18 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 May 2025 15:29:18 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v5] In-Reply-To: <6fwx-RiRnE_IhQacZgAPnrF4S5Bd4DG7mw79RxZCea8=.4a62d7e4-d5ef-4301-bc08-c284167782d1@github.com> References: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com> <6fwx-RiRnE_IhQacZgAPnrF4S5Bd4DG7mw79RxZCea8=.4a62d7e4-d5ef-4301-bc08-c284167782d1@github.com> Message-ID: On Tue, 6 May 2025 15:19:09 GMT, Johannes Graham wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder. > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2101: > >> 2099: } >> 2100: >> 2101: private AbstractStringBuilder repeat(char c, int count) { > > How about renaming the `count` parameter here so that it is obviously distinct from the meaning of `count` elsewhere in this class. Yes, that's a bit unfortunate overloading of the parameter name as defined in the public `repeat` methods. Maybe that can be considered more fully in a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075727565 From ihse at openjdk.org Tue May 6 15:29:27 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:29:27 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: <0yCHTP7eQgosQh4hZ5khOXUulKb6gRx_uCr7Rl785Zg=.16873d03-5d82-49f0-9ad4-26330b3282d0@github.com> On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision: >> >> - Also document UTF-8 requirements (solves JDK-8338973) >> - Let configure only accept utf-8 locales >> - Address review comments from Kim > > make/autoconf/basic.m4 line 155: > >> 153: else >> 154: AC_MSG_RESULT([no UTF-8 locale found]) >> 155: AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.]) > > Seems we run into this 'else' part on AIX > > > checking for locale to use... no UTF-8 locale found > configure: error: No UTF-8 locale found. This is required for building successfully. > configure exiting with result code 1 > > maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity? (have to check if there are other names on AIX) @MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2075728219 From ihse at openjdk.org Tue May 6 15:39:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:39:04 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). Magnus Ihse Bursie 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' into go-full-utf8 - Add informative message about supported locales. - Allow C locale with warning instead of fatal error - Also document UTF-8 requirements (solves JDK-8338973) - Let configure only accept utf-8 locales - Address review comments from Kim - Also tell javadoc that we have utf-8 now - Fix flags for Windows - Mark java and native source code as utf-8 - Don't convert properties files to iso-8859-1. - ... and 3 more: https://git.openjdk.org/jdk/compare/e43ea2cd...bea19a70 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24574/files - new: https://git.openjdk.org/jdk/pull/24574/files/9ce59e1f..bea19a70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=03-04 Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 mod Patch: https://git.openjdk.org/jdk/pull/24574.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574 PR: https://git.openjdk.org/jdk/pull/24574 From dfuchs at openjdk.org Tue May 6 15:39:19 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 May 2025 15:39:19 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v2] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com> On Tue, 6 May 2025 14:40:46 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Fix raw long updater under 32-bit mode src/java.base/share/classes/java/net/URI.java line 558: > 556: > 557: // Used reflectively by HASH_UPDATER > 558: @Stable What are the effect of this change on startup time? I remember that @cl4es made a number of changes to URI to improve startup. Maybe this change should be dropped out of this PR for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075743220 From ihse at openjdk.org Tue May 6 15:39:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:39:24 GMT Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie wrote: >> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII. > > Magnus Ihse Bursie 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 restore-more-ascii > - Remove incorrectly copied "?anchor" > - 8354273: Restore even more pointless unicode characters to ASCII Ping? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24567#issuecomment-2855052189 From bpb at openjdk.org Tue May 6 15:43:07 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 May 2025 15:43:07 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v16] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com> > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/db338317..983aeb50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=14-15 Stats: 96 lines in 3 files changed: 29 ins; 47 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From ihse at openjdk.org Tue May 6 15:46:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:46:03 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v2] In-Reply-To: References: Message-ID: > As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them. > > 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? > > I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code. > > There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into unicode-sequence-in-comments - 8354968: Replace unicode sequences in comment text with UTF-8 characters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24727/files - new: https://git.openjdk.org/jdk/pull/24727/files/ae1166af..694b33dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=00-01 Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 mod Patch: https://git.openjdk.org/jdk/pull/24727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727 PR: https://git.openjdk.org/jdk/pull/24727 From jpai at openjdk.org Tue May 6 15:51:17 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 15:51:17 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply reviewer suggestions for typos, javadoc, and copyright dates. Thank you for the updates. Overall the changes in this PR look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2818782618 From liach at openjdk.org Tue May 6 15:51:54 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 15:51:54 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v7] In-Reply-To: References: Message-ID: <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com> > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java Co-authored-by: Shaojin Wen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/2ead9d6d..450ea115 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From liach at openjdk.org Tue May 6 15:51:55 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 15:51:55 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: References: Message-ID: <1ZRryOd8Xk_Eu6uqiUBWav8Ss5IKpOpyT1U0Xj_27Tg=.dc714b83-1fa1-4389-893a-b5d9e892fc2d@github.com> On Tue, 6 May 2025 09:35:16 GMT, Shaojin Wen wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Review remarks > > src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 59: > >> 57: MemoryLayout[] stateLayouts = new MemoryLayout[supported.size()]; >> 58: @SuppressWarnings({"unchecked", "rawtypes"}) >> 59: Map.Entry[] entries = new Map.Entry[supported.size()]; > > Suggestion: > > CapturableState[] supported; > > if (OperatingSystem.isWindows()) { > supported = new CapturableState[] { > new CapturableState("GetLastError", JAVA_INT, 1 << 0), > new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1), > new CapturableState("errno", JAVA_INT, 1 << 2) > }; > } else { > supported = new CapturableState[] {new CapturableState("errno", JAVA_INT, 1 << 2)}; > } > > MemoryLayout[] stateLayouts = new MemoryLayout[supported.length]; > @SuppressWarnings({"unchecked", "rawtypes"}) > Map.Entry[] entries = new Map.Entry[supported.length]; > > Here it might be better to replace List with an array I think I might ask @JornVernee for opinion as that is the original author. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075764944 From liach at openjdk.org Tue May 6 15:51:55 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 15:51:55 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com> References: <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com> Message-ID: On Tue, 6 May 2025 11:56:04 GMT, Per Minborg wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Review remarks > > src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 81: > >> 79: >> 80: public static CapturableState forName(String name) { >> 81: var ret = LOOKUP.get(name); > > As we usually have just one element (and for Windows three elements) it might be both less memory consuming and faster to just search a `@Stable` array linearly rather than having a Map. `Map.get` still has cleaner code than an array iteration, and there is already a Map1 optimized implementation. I think map is more friendly in the long run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075767137 From liach at openjdk.org Tue May 6 15:51:55 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 15:51:55 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 12:07:46 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 88: >> >>> 86: >>> 87: // The current OperatingSystem >>> 88: private static @Stable OperatingSystem CURRENT_OS; >> >> Could this be a `StableValue.supplier()`? > > I would rather optimize MethodHandleAccessorFactory than defining a new class for this... Rolled back per @jaikiran. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075767396 From liach at openjdk.org Tue May 6 15:51:55 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 15:51:55 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v4] In-Reply-To: References: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com> Message-ID: <6kFeuo8pz_X5YITDlJcc-SYUpJvhSxrW_OsMHXqOrio=.9ef6de4f-16f2-4606-991c-87c91b655e09@github.com> On Tue, 6 May 2025 06:36:57 GMT, Jaikiran Pai wrote: >> Enum.valueOf -> Class.enumConstantDirectory -> Class.getEnumConstantsShared -> Method.invoke -> MethodHandleAccessorFactory.makeSpecializedTarget(isStatic = true) -> MethodHandles.dropArguments -> LambdaForm.editor -> bytecode generation and loading because this currently cannot be pregenerated by CDS archive. >> >> If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here. > > Thank you Chen for updating the issue type of bug. > >> If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here. > > The current bug fix I think should just address the incorrect result from `captureCallState()`. > > If the change to OperatingSystem class has practical improvements to the startup performance, then I think it's worth proposing. I suggest we do it in a separate and independent PR and the discussion and review for that change would have to take into account the existing comment in that class and see if it is no longer necessary. Yep, rolled back OS changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075768065 From asemenyuk at openjdk.org Tue May 6 16:43:15 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 16:43:15 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck Marked as reviewed by asemenyuk (Reviewer). Looks good assuming jpackage tests ([test/jdk/tools/jpackage/windows/WinNoRestartTest.java](https://github.com/openjdk/jdk/blob/a6995a3d42955f1f207c14be1634daf225b5ab3f/test/jdk/tools/jpackage/windows/Win8301247Test.java#L24) and [test/jdk/tools/jpackage/windows/Win8301247Test.java](https://github.com/openjdk/jdk/blob/a6995a3d42955f1f207c14be1634daf225b5ab3f/test/jdk/tools/jpackage/windows/Win8301247Test.java#L24)) passed with this change. ------------- PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2818983754 PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2855254506 From naoto at openjdk.org Tue May 6 16:45:26 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 May 2025 16:45:26 GMT Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie wrote: >> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII. > > Magnus Ihse Bursie 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 restore-more-ascii > - Remove incorrectly copied "?anchor" > - 8354273: Restore even more pointless unicode characters to ASCII LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24567#pullrequestreview-2818989660 From duke at openjdk.org Tue May 6 16:56:22 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 16:56:22 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com> References: <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com> Message-ID: On Tue, 6 May 2025 11:30:09 GMT, Jaikiran Pai wrote: > > do you mean merging master branch into this branch? > > Yes, that's correct. That should then run the GitHub actions job against this PR against a more relevant state of this PR. > > Since things have settled and the CSR approved, I'll also run this PR against our CI to verify nothing fails unexpectedly. I will anyway be doing the merge against master locally before submitting for tier testing, but it's always a good practice to keep the PR updated with latest master changes, when the master branch has seen too many commits since the PR was opened. Yes that is pretty clear. I'm using git since decades but always do rebase in all other project, so my question was only about *how* to perform the update. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2855286477 From jpai at openjdk.org Tue May 6 17:05:20 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 May 2025 17:05:20 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com> Message-ID: <6tJ94UzFn2GwHMB9WK3Xeig34edB02mMoWw8_ZjPMzc=.a69e8f1b-edd4-4c89-b34f-8248b11852c4@github.com> On Tue, 6 May 2025 16:53:07 GMT, Markus KARG wrote: > so my question was only about how to perform the update. Locally, if your remote repo that points to github.com/openjdk/jdk is named `upstream` and the local branch from which you have created this PR is named `getchars`, then you would do something like the following: # fetch latest changes in master branch of github.com/openjdk/jdk git fetch upstream master # update your local workspace to your local getchars branch (if you aren't already on it) git switch getchars # merge the changes from upstream master branch into this local getchars branch git merge -m "merge latest from master branch" upstream/master If there are no merge resolution conflicts, then those command should be enough and your local `getchars` branch should now have the upstream master changes. Once you build and test locally you can then push those changes from `getchars` branch to your forked remote repo's getchars branch (and thus automatically update this PR) using: # while being on getchars branch locally and your forked remote is named mkarg-remote git push mkarg-remote getchars ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2855309443 From jvernee at openjdk.org Tue May 6 17:16:21 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 6 May 2025 17:16:21 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: <1ZRryOd8Xk_Eu6uqiUBWav8Ss5IKpOpyT1U0Xj_27Tg=.dc714b83-1fa1-4389-893a-b5d9e892fc2d@github.com> References: <1ZRryOd8Xk_Eu6uqiUBWav8Ss5IKpOpyT1U0Xj_27Tg=.dc714b83-1fa1-4389-893a-b5d9e892fc2d@github.com> Message-ID: On Tue, 6 May 2025 15:46:22 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 59: >> >>> 57: MemoryLayout[] stateLayouts = new MemoryLayout[supported.size()]; >>> 58: @SuppressWarnings({"unchecked", "rawtypes"}) >>> 59: Map.Entry[] entries = new Map.Entry[supported.size()]; >> >> Suggestion: >> >> CapturableState[] supported; >> >> if (OperatingSystem.isWindows()) { >> supported = new CapturableState[] { >> new CapturableState("GetLastError", JAVA_INT, 1 << 0), >> new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1), >> new CapturableState("errno", JAVA_INT, 1 << 2) >> }; >> } else { >> supported = new CapturableState[] {new CapturableState("errno", JAVA_INT, 1 << 2)}; >> } >> >> MemoryLayout[] stateLayouts = new MemoryLayout[supported.length]; >> @SuppressWarnings({"unchecked", "rawtypes"}) >> Map.Entry[] entries = new Map.Entry[supported.length]; >> >> Here it might be better to replace List with an array > > I think I might ask @JornVernee for opinion as that is the original author. Either one works I think. Array might be a bit more efficient. Don't think it matters much though ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075931062 From swen at openjdk.org Tue May 6 17:19:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 6 May 2025 17:19:18 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Tue, 6 May 2025 12:30:01 GMT, Per Minborg wrote: >> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 390: >> >>> 388: return MhUtil.findVirtual(LOOKUP, Arena.class, "close", >>> 389: MethodType.methodType(void.class)); >>> 390: } >> >> Suggestion: >> >> return switch (index) { >> case NON_NEGATIVE_INT -> MhUtil.findStatic(LOOKUP, "nonNegative", >> MethodType.methodType(boolean.class, int.class)); >> case SUCCESS_INT -> MhUtil.findStatic(LOOKUP, "success", >> MethodType.methodType(int.class, int.class, MemorySegment.class)); >> case ERROR_INT -> MhUtil.findStatic(LOOKUP, "error", >> MethodType.methodType(int.class, MethodHandle.class, int.class, MemorySegment.class)); >> case NON_NEGATIVE_LONG -> MhUtil.findStatic(LOOKUP, "nonNegative", >> MethodType.methodType(boolean.class, long.class)); >> case SUCCESS_LONG -> MhUtil.findStatic(LOOKUP, "success", >> MethodType.methodType(long.class, long.class, MemorySegment.class)); >> case ERROR_LONG -> MhUtil.findStatic(LOOKUP, "error", >> MethodType.methodType(long.class, MethodHandle.class, long.class, MemorySegment.class)); >> case ACQUIRE_ARENA -> MhUtil.findStatic(LOOKUP, "acquireArena", >> MethodType.methodType(Arena.class)); >> case ALLOCATE -> MhUtil.findStatic(LOOKUP, "allocate", >> MethodType.methodType(MemorySegment.class, Arena.class)); >> case ARENA_CLOSE -> MhUtil.findVirtual(LOOKUP, Arena.class, "close", >> MethodType.methodType(void.class)); >> default -> throw new InternalError("Unknown index: " + index); >> }; >> >> Switch statement can be replaced with enhanced 'switch' > > I have the old switch format in anticipation of faster startup. enhanced 'switch' is just syntax sugar and does not affect startup speed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075935264 From naoto at openjdk.org Tue May 6 17:21:18 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 May 2025 17:21:18 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v2] In-Reply-To: References: Message-ID: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com> On Tue, 6 May 2025 15:46:03 GMT, Magnus Ihse Bursie wrote: >> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them. >> >> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? >> >> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code. >> >> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into unicode-sequence-in-comments > - 8354968: Replace unicode sequences in comment text with UTF-8 characters src/java.base/share/classes/java/text/Collator.java line 141: > 139: * considered significant during comparison. The assignment of strengths > 140: * to language features is locale dependent. A common example is for > 141: * different accented forms of the same base letter ("a" vs "?") to be Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here. src/java.base/share/classes/java/text/RuleBasedCollator.java line 594: > 592: // a three-digit number, one digit for primary, one for secondary, etc. > 593: // > 594: // String: A a B ? Maybe "? (\u00e9, e-acute)"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075933987 PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075935811 From jvernee at openjdk.org Tue May 6 17:22:17 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 6 May 2025 17:22:17 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v5] In-Reply-To: References: <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com> Message-ID: <3SAlKbn9bHOENW0w-L3AWBmYjrebfJdQRKuLI7o8Nr8=.0beead30-081e-48ae-9620-eafc68f5b64f@github.com> On Tue, 6 May 2025 15:47:36 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 81: >> >>> 79: >>> 80: public static CapturableState forName(String name) { >>> 81: var ret = LOOKUP.get(name); >> >> As we usually have just one element (and for Windows three elements) it might be both less memory consuming and faster to just search a `@Stable` array linearly rather than having a Map. > > `Map.get` still has cleaner code than an array iteration, and there is already a Map1 optimized implementation. I think map is more friendly in the long run. Alternatively, you could hard code the names in a `switch` here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075939248 From erikj at openjdk.org Tue May 6 17:26:23 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 6 May 2025 17:26:23 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie 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' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - Don't convert properties files to iso-8859-1. > - ... and 3 more: https://git.openjdk.org/jdk/compare/e6fcaea5...bea19a70 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2819093476 From duke at openjdk.org Tue May 6 17:28:21 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 17:28:21 GMT Subject: RFR: 8354724: BufferedReader readAllLines and readString methods [v14] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com> <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com> Message-ID: On Sun, 4 May 2025 05:08:46 GMT, Alan Bateman wrote: >> Oh, and we should set `next` afterwards, so the `Reader` knows that the end of the sequence is reached: >> >> >> public String readAllChars() throws IOException { >> ensureOpen(); >> var len = cs.length(); >> var remainder = cs.subSequence(next, len); >> next = len; >> return remainder.toString(); >> } >> >> >> (Edited my proposal to be a bit more concurrency-friendly and correct.) > > Probably best to ignore the implementation details as the discussions on what methods to expose, and where, is still going on. It was probably a bit premature to create the PR without getting agreement on the API first. So at least it's not just me... ? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2075948845 From jvernee at openjdk.org Tue May 6 17:30:15 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 6 May 2025 17:30:15 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v7] In-Reply-To: <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com> References: <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com> Message-ID: <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com> On Tue, 6 May 2025 15:51:54 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java > > Co-authored-by: Shaojin Wen Looks good. src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55: > 53: } else { > 54: supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2)); > 55: } Maybe just split the initialization of `LAYOUT` and `LOOKUP` across these 2 branches, instead of collecting everything into intermediate arrays. i.e. Suggestion: if (OperatingSystem.isWindows()) { LAYOUT = MemoryLayout.structLayout( JAVA_INT, // GetLastError JAVA_INT, // WSAGetLastError JAVA_INT // errno ); LOOKUP = Map.of( "GetLastError", 1 << 0, "WSAGetLastError", 1 << 1, "errno", 1 << 2 ); } else { LAYOUT = MemoryLayout.structLayout( JAVA_INT // errno ); LOOKUP = Map.of( "errno", 1 << 2 ); } ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2819101227 PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075950579 From duke at openjdk.org Tue May 6 17:33:20 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 17:33:20 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: <3KjNbuZlZwyr7pAf6idOFXuQO7TUNYXya8nUPGvlkII=.ba5d118a-17bb-4b56-a11c-065a59788ca9@github.com> On Thu, 1 May 2025 08:45:06 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? I know all that. As I said, I am using git since decades, so I know *lots* of alternative ways to update branches and even proposed the one you want, so I just needed to know *which of those alternatives* (not the exact commands) you *want*. Don't know why posted all that, as the question was already solved by you?! ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2855388011 From rgiulietti at openjdk.org Tue May 6 17:35:22 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 6 May 2025 17:35:22 GMT Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 20:58:56 GMT, Andrey Turbanov wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Increased min heap size to 8G. > > Marked as reviewed by aturbanov (Committer). Thanks to the reviewers, and to @turbanoff for reporting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25038#issuecomment-2855390232 From rgiulietti at openjdk.org Tue May 6 17:35:23 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 6 May 2025 17:35:23 GMT Subject: Integrated: 8356152: String.concat can throw StringIndexOutOfBoundsException In-Reply-To: References: Message-ID: On Mon, 5 May 2025 13:07:45 GMT, Raffaello Giulietti wrote: > A fix to throw `OutOfMemoryError`, as done in releases ? 23. This pull request has now been integrated. Changeset: 052e2522 Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/052e2522b661e51b5fd2e0561c4866e97b9d170d Stats: 79 lines in 2 files changed: 78 ins; 0 del; 1 mod 8356152: String.concat can throw StringIndexOutOfBoundsException Reviewed-by: liach, aturbanov, redestad, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/25038 From liach at openjdk.org Tue May 6 17:43:14 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 17:43:14 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v7] In-Reply-To: <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com> References: <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com> <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com> Message-ID: On Tue, 6 May 2025 17:27:09 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java >> >> Co-authored-by: Shaojin Wen > > src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55: > >> 53: } else { >> 54: supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2)); >> 55: } > > Maybe just split the initialization of `LAYOUT` and `LOOKUP` across these 2 branches, instead of collecting everything into intermediate arrays. i.e. > > Suggestion: > > if (OperatingSystem.isWindows()) { > LAYOUT = MemoryLayout.structLayout( > JAVA_INT, // GetLastError > JAVA_INT, // WSAGetLastError > JAVA_INT // errno > ); > LOOKUP = Map.of( > "GetLastError", 1 << 0, > "WSAGetLastError", 1 << 1, > "errno", 1 << 2 > ); > } else { > LAYOUT = MemoryLayout.structLayout( > JAVA_INT // errno > ); > LOOKUP = Map.of( > "errno", 1 << 2 > ); > } Then we can just make `CapturableState` a utility class. Should we proceed in this direction? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075969405 From almatvee at openjdk.org Tue May 6 17:47:19 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 May 2025 17:47:19 GMT Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect location in the app image [v2] In-Reply-To: <2qiByi-Qtb91lGRl1Bv21y6r-kIdsYU3EGMcqRK5qNU=.f138fa2f-e7a1-45cb-8f8e-658df628213c@github.com> References: <2qiByi-Qtb91lGRl1Bv21y6r-kIdsYU3EGMcqRK5qNU=.f138fa2f-e7a1-45cb-8f8e-658df628213c@github.com> Message-ID: On Tue, 6 May 2025 03:25:07 GMT, Alexey Semenyuk wrote: >> - Refactor PathGroup >> - Add test cases to PathGroupTest >> - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package >> - Refactor UsrTreeTest to use JPackageCommand assert functions > > Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Fix a typo in ApplicationLayout Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25051#pullrequestreview-2819144121 From ihse at openjdk.org Tue May 6 17:49:14 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 17:49:14 GMT Subject: RFR: 8356050: Problemlist jdk, langtools & lib-test tier1 tests requiring runtime usages of /bin/tools for static-jdk [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:43:37 GMT, Jiangli Zhou wrote: >> Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of /bin/tools, for testing on static-jdk. The affected tests using following tools at runtime: >> >> - javac >> - javadoc >> - jar >> - jarsigner >> - jcmd >> - jimage >> - jps >> >> The latest teir1 testing results on static-jdk: https://github.com/jianglizhou/jdk/actions/runs/14781658116/job/41503569932. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Problemlist jdk/test/lib/hprof/HprofTest. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24995#pullrequestreview-2819148902 From jiangli at openjdk.org Tue May 6 17:58:23 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 6 May 2025 17:58:23 GMT Subject: RFR: 8356050: Problemlist jdk, langtools & lib-test tier1 tests requiring runtime usages of /bin/tools for static-jdk [v2] In-Reply-To: References: Message-ID: <2cX5g5DljTkiJdCTP5YMjjehXOJah9VYInT3jLOiztQ=.0126c189-e8be-45d8-9c74-b66c7ec1af13@github.com> On Tue, 6 May 2025 17:47:04 GMT, Magnus Ihse Bursie wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Problemlist jdk/test/lib/hprof/HprofTest. > > Marked as reviewed by ihse (Reviewer). Thanks for reviewing, @magicus! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24995#issuecomment-2855446867 From jiangli at openjdk.org Tue May 6 17:58:24 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 6 May 2025 17:58:24 GMT Subject: Integrated: 8356050: Problemlist jdk, langtools & lib-test tier1 tests requiring runtime usages of /bin/tools for static-jdk In-Reply-To: References: Message-ID: On Fri, 2 May 2025 01:15:05 GMT, Jiangli Zhou wrote: > Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of /bin/tools, for testing on static-jdk. The affected tests using following tools at runtime: > > - javac > - javadoc > - jar > - jarsigner > - jcmd > - jimage > - jps > > The latest teir1 testing results on static-jdk: https://github.com/jianglizhou/jdk/actions/runs/14781658116/job/41503569932. This pull request has now been integrated. Changeset: 064b036e Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/064b036ebd73407ce036d283dbacce44530dbb38 Stats: 45 lines in 3 files changed: 45 ins; 0 del; 0 mod 8356050: Problemlist jdk, langtools & lib-test tier1 tests requiring runtime usages of /bin/tools for static-jdk Reviewed-by: ihse ------------- PR: https://git.openjdk.org/jdk/pull/24995 From asemenyuk at openjdk.org Tue May 6 18:00:24 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 18:00:24 GMT Subject: Integrated: 8356219: jpackage places libapplauncher.so in incorrect location in the app image In-Reply-To: References: Message-ID: <2fLeNTdovq40wT00G2iZG8Q2Ikte8LeFsCKyYZyRR7k=.8948c2a4-6abc-4a55-b212-51dcc5d48269@github.com> On Mon, 5 May 2025 21:44:36 GMT, Alexey Semenyuk wrote: > - Refactor PathGroup > - Add test cases to PathGroupTest > - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package > - Refactor UsrTreeTest to use JPackageCommand assert functions This pull request has now been integrated. Changeset: 9c43871f Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/9c43871fd15c6fa89f7ad8803c68db7d7a6c09ca Stats: 822 lines in 8 files changed: 641 ins; 64 del; 117 mod 8356219: jpackage places libapplauncher.so in incorrect location in the app image Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/25051 From ihse at openjdk.org Tue May 6 18:02:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 18:02:19 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v2] In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com> References: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com> Message-ID: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com> On Tue, 6 May 2025 17:15:34 GMT, Naoto Sato wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into unicode-sequence-in-comments >> - 8354968: Replace unicode sequences in comment text with UTF-8 characters > > src/java.base/share/classes/java/text/Collator.java line 141: > >> 139: * considered significant during comparison. The assignment of strengths >> 140: * to language features is locale dependent. A common example is for >> 141: * different accented forms of the same base letter ("a" vs "?") to be > > Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here. I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though). If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075997573 From ihse at openjdk.org Tue May 6 18:03:22 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 18:03:22 GMT Subject: Integrated: 8354273: Replace even more Unicode characters with ASCII In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 10:18:08 GMT, Magnus Ihse Bursie wrote: > As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII. This pull request has now been integrated. Changeset: 08dd4a75 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/08dd4a75c5b751a66d2e088b0ec9c6d6c443c14a Stats: 11 lines in 8 files changed: 0 ins; 1 del; 10 mod 8354273: Replace even more Unicode characters with ASCII Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/24567 From jvernee at openjdk.org Tue May 6 18:07:30 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 6 May 2025 18:07:30 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v7] In-Reply-To: References: <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com> <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com> Message-ID: On Tue, 6 May 2025 17:40:52 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55: >> >>> 53: } else { >>> 54: supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2)); >>> 55: } >> >> Maybe just split the initialization of `LAYOUT` and `LOOKUP` across these 2 branches, instead of collecting everything into intermediate arrays. i.e. >> >> Suggestion: >> >> if (OperatingSystem.isWindows()) { >> LAYOUT = MemoryLayout.structLayout( >> JAVA_INT, // GetLastError >> JAVA_INT, // WSAGetLastError >> JAVA_INT // errno >> ); >> LOOKUP = Map.of( >> "GetLastError", 1 << 0, >> "WSAGetLastError", 1 << 1, >> "errno", 1 << 2 >> ); >> } else { >> LAYOUT = MemoryLayout.structLayout( >> JAVA_INT // errno >> ); >> LOOKUP = Map.of( >> "errno", 1 << 2 >> ); >> } > > Then we can just make `CapturableState` a utility class. Should we proceed in this direction? Yes, that seems fine to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2076005578 From naoto at openjdk.org Tue May 6 18:09:25 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 May 2025 18:09:25 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v2] In-Reply-To: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com> References: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com> <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com> Message-ID: On Tue, 6 May 2025 17:59:18 GMT, Magnus Ihse Bursie wrote: >> src/java.base/share/classes/java/text/Collator.java line 141: >> >>> 139: * considered significant during comparison. The assignment of strengths >>> 140: * to language features is locale dependent. A common example is for >>> 141: * different accented forms of the same base letter ("a" vs "?") to be >> >> Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here. > > I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though). > > If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. > > But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that. Yes, I meant literally `\u00e9` or `\u00E4`, but I think it is better described as `U+00E9` emphasizing the code point. So in this case, I'd suggest "a" vs "?" (U+00E9) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2076008258 From henryjen at openjdk.org Tue May 6 18:09:45 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 6 May 2025 18:09:45 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v5] In-Reply-To: References: Message-ID: <4WWeeFJ0bxH4U1XfnLXi2wmekdo6rRRPzegDLnePGPc=.813a8ecc-f500-462a-a865-ca5d632e8423@github.com> > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Validation entry name, also output the count of duplicates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/e38774af..24d0776d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=03-04 Stats: 229 lines in 3 files changed: 151 ins; 45 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From henryjen at openjdk.org Tue May 6 18:21:30 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 6 May 2025 18:21:30 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v6] In-Reply-To: References: Message-ID: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Restore Validator access level ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/24d0776d..e0eff6ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From jlu at openjdk.org Tue May 6 18:30:18 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 6 May 2025 18:30:18 GMT Subject: RFR: 8356096: ISO 4217 Amendment 179 Update In-Reply-To: References: Message-ID: On Fri, 2 May 2025 20:51:31 GMT, Justin Lu wrote: > Please review this PR which implements ISO 4217 update 179. > > The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`). Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25014#issuecomment-2855531302 From jlu at openjdk.org Tue May 6 18:30:19 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 6 May 2025 18:30:19 GMT Subject: Integrated: 8356096: ISO 4217 Amendment 179 Update In-Reply-To: References: Message-ID: On Fri, 2 May 2025 20:51:31 GMT, Justin Lu wrote: > Please review this PR which implements ISO 4217 update 179. > > The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`). This pull request has now been integrated. Changeset: 0cb355ee Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/0cb355ee921183423c8ffc44491f428c49c62c28 Stats: 11 lines in 4 files changed: 2 ins; 0 del; 9 mod 8356096: ISO 4217 Amendment 179 Update Reviewed-by: naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/25014 From bchristi at openjdk.org Tue May 6 18:43:19 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 6 May 2025 18:43:19 GMT Subject: Integrated: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 22:35:23 GMT, Brent Christian wrote: > I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures: > > * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method > * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger` > * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram. This pull request has now been integrated. Changeset: fe29cad5 Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/fe29cad5e0b10cd088fc39967599f5a8dcaa445c Stats: 28 lines in 1 file changed: 14 ins; 1 del; 13 mod 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" Reviewed-by: kbarrett, jpai ------------- PR: https://git.openjdk.org/jdk/pull/24143 From liach at openjdk.org Tue May 6 20:07:56 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 20:07:56 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v8] In-Reply-To: References: Message-ID: > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Simplify to utility class - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states - Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java Co-authored-by: Shaojin Wen - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states - rollback OS - Review remarks - No env to test - Unchecked - Further revamp, remove unnecessary instances on irrelevant platforms - ... and 2 more: https://git.openjdk.org/jdk/compare/83a1ad55...0f495539 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/450ea115..0f495539 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=06-07 Stats: 8346 lines in 139 files changed: 4543 ins; 2476 del; 1327 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From bpb at openjdk.org Tue May 6 20:14:05 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 May 2025 20:14:05 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v13] In-Reply-To: References: Message-ID: > 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 13 commits: - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - 8337143: Clean up to address reviewer comments - Merge - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c - Merge - ... and 3 more: https://git.openjdk.org/jdk/compare/9477c422...da21fa69 ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=12 Stats: 1541 lines in 93 files changed: 774 ins; 668 del; 99 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 duke at openjdk.org Tue May 6 20:32:17 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 20:32:17 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sun, 4 May 2025 16:21:41 GMT, Markus KARG wrote: >> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. >> >> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Undone copyright update of otherwise unchanged file. > - Update Of.java > > Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise." > There is some wording around this topic in the guide already: _In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists](https://openjdk.org/guide/#mailing-lists). Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code._ > > I've added the suggested text to clarify this paragraph: [openjdk/guide#150](https://github.com/openjdk/guide/pull/150) Then I can literally stop working on OpenJDK rather immediately, as people never find enough time for **"broad"** agreement. At least they didn't in the past **years**. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2855892549 From asemenyuk at openjdk.org Tue May 6 20:38:23 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 20:38:23 GMT Subject: RFR: 8356309: Fix issues uncovered after running jpackage tests locally with installing test packages In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk wrote: > Fix issues uncovered in the tests after local test runs with the installation of test packages: > - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception. > - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode. > - Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed. > > Before the fix, the sequence was: > > for (action in {create, install, uninstall}) { > for (test in tests) { > for (type in {exe, msi}) { > run $action on $test of $type > } > } > } > > > After the fix, the sequence is: > > for (type in {exe, msi}) { > for (action in {create, install, uninstall}) { > for (test in tests) { > run $action on $test of $type > } > } > } > > > Additionally: > - Add missing `@Test` annotation to PathGroupTest.testNullId() test case; > - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y; > - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied; > - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/24884#issuecomment-2855904552 From asemenyuk at openjdk.org Tue May 6 20:38:23 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 20:38:23 GMT Subject: RFR: 8356309: Fix issues uncovered after running jpackage tests locally with installing test packages Message-ID: Fix issues uncovered in the tests after local test runs with the installation of test packages: - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception. - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode. - Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed. Before the fix, the sequence was: for (action in {create, install, uninstall}) { for (test in tests) { for (type in {exe, msi}) { run $action on $test of $type } } } After the fix, the sequence is: for (type in {exe, msi}) { for (action in {create, install, uninstall}) { for (test in tests) { run $action on $test of $type } } } Additionally: - Add missing `@Test` annotation to PathGroupTest.testNullId() test case; - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y; - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied; - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image ------------- Commit messages: - Merge branch 'master' into local-test-followup - Bugfix RuntimePackageTest - Bugfix - Better test coverage - Add RuntimeImageTest.testStrippedFiles() test to verify jmods and src.zip files are stripped from copied runtime - Improve RuntimeImageTest - Add missing @Test annotation - Fix typo - EmptyFolderTest: bugfix - PackageTest: fix to make it work when exe and msi packagings are both enabled and when PackageTest.Group is used - ... and 5 more: https://git.openjdk.org/jdk/compare/0cb355ee...9649c077 Changes: https://git.openjdk.org/jdk/pull/24884/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24884&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356309 Stats: 107 lines in 7 files changed: 49 ins; 6 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/24884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24884/head:pull/24884 PR: https://git.openjdk.org/jdk/pull/24884 From duke at openjdk.org Tue May 6 20:52:34 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 20:52:34 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: > This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. > > In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. > > To ensure quality... > * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. > * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. Markus KARG 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 latest from master branch - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? - Applied changes requested by Alan: Copies chars from this sequence into the given destination array - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a ------------- Changes: https://git.openjdk.org/jdk/pull/21730/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=11 Stats: 470 lines in 8 files changed: 399 ins; 59 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/21730.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730 PR: https://git.openjdk.org/jdk/pull/21730 From duke at openjdk.org Tue May 6 20:54:17 2025 From: duke at openjdk.org (Markus KARG) Date: Tue, 6 May 2025 20:54:17 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v11] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 11:23:01 GMT, Markus KARG wrote: > Hello Markus, it's been a while since this PR was merged with latest master branch in mainline. Could you update the PR to do that? Updated to current `master`. Builds fine locally. Pushed to Github. Github Actions currently are running. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2855944238 From duke at openjdk.org Tue May 6 21:45:34 2025 From: duke at openjdk.org (Mohamed Issa) Date: Tue, 6 May 2025 21:45:34 GMT Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3] In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com> References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com> Message-ID: > The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. > > The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version. > > For performance data collected with the built in **cbrt** micro-benchmark, see the table below. Each result is the mean of 8 individual runs. Overall, the intrinsic provides a performance uplift of 37%. > > | Benchmark | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup | > | :----------------: | :----------------------------------: | :----------------------------------: | :---------: | > | MathBench.cbrt | 152465 | 208537 | 1.37x | > > Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes. Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Add new set of cbrt micro-benchmarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24470/files - new: https://git.openjdk.org/jdk/pull/24470/files/3212c669..57412f0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=01-02 Stats: 148 lines in 1 file changed: 148 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24470.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24470/head:pull/24470 PR: https://git.openjdk.org/jdk/pull/24470 From jvernee at openjdk.org Tue May 6 21:49:19 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 6 May 2025 21:49:19 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v8] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:07:56 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Simplify to utility class > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states > - Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java > > Co-authored-by: Shaojin Wen > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states > - rollback OS > - Review remarks > - No env to test > > - Unchecked > > - Further revamp, remove unnecessary instances on irrelevant platforms > > - ... and 2 more: https://git.openjdk.org/jdk/compare/479659a2...0f495539 Changes look good src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 62: > 60: "errno", 1 << 2 > 61: ); > 62: } Pre-existing, but while you're here, could you add a comment stating that the mask values have to be kept in sync with the value in `DowncallLinker::capture_state` in `src/hotspot/share/prims/downcallLinker.cpp`? (See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/downcallLinker.cpp#L36) ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2819760597 PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2076367601 From jwilhelm at openjdk.org Tue May 6 21:57:15 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 6 May 2025 21:57:15 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sun, 4 May 2025 16:21:41 GMT, Markus KARG wrote: >> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. >> >> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Undone copyright update of otherwise unchanged file. > - Update Of.java > > Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise." We must remember that the OpenJDK community is built by individuals with different backgrounds and motivations to engaging. Some people get paid to work on OpenJDK development, others do it in their own time. It would be next to impossible to dictate any kinds of rules to enforce engagement from reviewers as this would require companies and individuals to commit to prioritizing issues that may not be in their interest to spend time on. Any kind of "if you engage in a discussion you must reply within X weeks" will most likely only result in less people engaging in the first place. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2856187951 From liach at openjdk.org Tue May 6 22:11:49 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 22:11:49 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v9] In-Reply-To: References: Message-ID: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com> > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. Chen Liang has updated the pull request incrementally with two additional commits since the last revision: - Indicate source file - Keep in sync comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25025/files - new: https://git.openjdk.org/jdk/pull/25025/files/0f495539..5986dbff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=07-08 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025 PR: https://git.openjdk.org/jdk/pull/25025 From liach at openjdk.org Tue May 6 22:11:50 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 22:11:50 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v8] In-Reply-To: References: Message-ID: <4EuA5Ih76U-5w5ifFq9G1nP4VAhGbuB9myNYpXkCFwc=.f275bd06-2625-41f9-aab5-288c75ed1f20@github.com> On Tue, 6 May 2025 21:45:55 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - Simplify to utility class >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states >> - Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java >> >> Co-authored-by: Shaojin Wen >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states >> - rollback OS >> - Review remarks >> - No env to test >> >> - Unchecked >> >> - Further revamp, remove unnecessary instances on irrelevant platforms >> >> - ... and 2 more: https://git.openjdk.org/jdk/compare/e1e77797...0f495539 > > src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 62: > >> 60: "errno", 1 << 2 >> 61: ); >> 62: } > > Pre-existing, but while you're here, could you add a comment stating that the mask values have to be kept in sync with the value in `DowncallLinker::capture_state` in `src/hotspot/share/prims/downcallLinker.cpp`? (See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/downcallLinker.cpp#L36) Done. Added in the MASKS field declaration. Also updated the outdated class name reference in downcallLinker.cpp. (Missed c++ file name in first push, c++ file name is not that easy to discover) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2076415819 From jvernee at openjdk.org Tue May 6 22:21:16 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 6 May 2025 22:21:16 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v9] In-Reply-To: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com> References: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com> Message-ID: <607rDUECdLHyT6YOhm3fMX6axgaBt81JF_cjePq0Qbg=.54d73522-7410-4811-9b8d-be78da9b272b@github.com> On Tue, 6 May 2025 22:11:49 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with two additional commits since the last revision: > > - Indicate source file > - Keep in sync comments Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2819834200 From liach at openjdk.org Tue May 6 22:21:16 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 22:21:16 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v9] In-Reply-To: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com> References: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com> Message-ID: On Tue, 6 May 2025 22:11:49 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with two additional commits since the last revision: > > - Indicate source file > - Keep in sync comments Thanks for the review! Tier 1-3 tests all pass. Will wait for people to check out this utility class version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2856250459 From bchristi at openjdk.org Tue May 6 22:51:16 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 6 May 2025 22:51:16 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply reviewer suggestions for typos, javadoc, and copyright dates. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1972: > 1970: * @param s a char array > 1971: * @param off the offset of the first character to append > 1972: * @param end end last (exclusive) character to append It might be helpful to somehow clarify that, in the case of appending Latin1 characters to a Latin1 buffer, it is expected/required that `value` is already of sufficient size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2076467887 From liach at openjdk.org Tue May 6 22:57:15 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 6 May 2025 22:57:15 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply reviewer suggestions for typos, javadoc, and copyright dates. Some of the new methods in ASB are still unsafe; I need to spend more time to verify each of their use cases. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 270: > 268: private static byte[] ensureCapacityNewCoder(byte[] value, byte coder, int count, > 269: int minimumCapacity, byte newCoder) { > 270: assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1"; I recommend an additional assertion `count <= minimumCapacity`; even though all callers ensure this currently, in case this is accidentally violated, we are sending dangerous arguments to `StringLatin1.inflate`. Also, the message string of assertion can include the `coder` and `newCoder` values. Same for the other assertions we add. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 321: > 319: */ > 320: private static byte[] inflateToUTF16(byte[] value, int count) { > 321: byte[] newValue = StringUTF16.newBytesFor(value.length); Same value.length vs count assertion recommendation ------------- PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2818880544 PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075825884 PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075827576 From bchristi at openjdk.org Tue May 6 22:57:15 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 6 May 2025 22:57:15 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply reviewer suggestions for typos, javadoc, and copyright dates. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2006: > 2004: * @param s a string > 2005: * @param off the offset of the first character to append > 2006: * @param end end last (exclusive) character to append It might be helpful to somehow clarify that, in the case of appending Latin1 characters to a Latin1 buffer, it is expected/required that `value` is already of sufficient size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2076470416 From bchristi at openjdk.org Tue May 6 23:00:16 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 6 May 2025 23:00:16 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply reviewer suggestions for typos, javadoc, and copyright dates. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2044: > 2042: * @param s a string > 2043: * @param off the offset of the first character to append > 2044: * @param end end last (exclusive) character to append It might be helpful to somehow clarify that, in the case of appending Latin1 characters to a Latin1 buffer, it is expected/required that `value` is already of sufficient size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2076475596 From almatvee at openjdk.org Tue May 6 23:32:13 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 May 2025 23:32:13 GMT Subject: RFR: 8356309: Fix issues uncovered after running jpackage tests locally with installing test packages In-Reply-To: References: Message-ID: <5htRvtHPwxIcBJByLPGox9myjjcoFmcwryVAVgp_C00=.17353db5-8120-4217-843f-5e5195271fdc@github.com> On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk wrote: > Fix issues uncovered in the tests after local test runs with the installation of test packages: > - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception. > - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode. > - Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed. > > Before the fix, the sequence was: > > for (action in {create, install, uninstall}) { > for (test in tests) { > for (type in {exe, msi}) { > run $action on $test of $type > } > } > } > > > After the fix, the sequence is: > > for (type in {exe, msi}) { > for (action in {create, install, uninstall}) { > for (test in tests) { > run $action on $test of $type > } > } > } > > > Additionally: > - Add missing `@Test` annotation to PathGroupTest.testNullId() test case; > - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y; > - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied; > - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24884#pullrequestreview-2819970329 From asemenyuk at openjdk.org Tue May 6 23:43:17 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 23:43:17 GMT Subject: Integrated: 8356309: Fix issues uncovered after running jpackage tests locally with installing test packages In-Reply-To: References: Message-ID: <9l8S-Efdjbhvz43_6Povp0ltYoEeT84TYHBkj0OVE7A=.526b1333-219e-4eab-a702-f3dac98a6f58@github.com> On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk wrote: > Fix issues uncovered in the tests after local test runs with the installation of test packages: > - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception. > - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode. > - Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed. > > Before the fix, the sequence was: > > for (action in {create, install, uninstall}) { > for (test in tests) { > for (type in {exe, msi}) { > run $action on $test of $type > } > } > } > > > After the fix, the sequence is: > > for (type in {exe, msi}) { > for (action in {create, install, uninstall}) { > for (test in tests) { > run $action on $test of $type > } > } > } > > > Additionally: > - Add missing `@Test` annotation to PathGroupTest.testNullId() test case; > - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y; > - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied; > - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image This pull request has now been integrated. Changeset: cbbab07d Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/cbbab07d232ff7d46f91b2df4e1b0ef4f37bba95 Stats: 107 lines in 7 files changed: 49 ins; 6 del; 52 mod 8356309: Fix issues uncovered after running jpackage tests locally with installing test packages Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/24884 From duke at openjdk.org Wed May 7 01:14:16 2025 From: duke at openjdk.org (Daishi Tabata) Date: Wed, 7 May 2025 01:14:16 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: <_DiRDJt8fWIUVE67JZBz77VD8I1ubbynjOkrjnX7jhU=.b6a7ef16-a1fb-447d-838c-b74b49157561@github.com> On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2856733631 From duke at openjdk.org Wed May 7 01:14:17 2025 From: duke at openjdk.org (duke) Date: Wed, 7 May 2025 01:14:17 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck @tabata-d Your change (at version 76a3a7ee1f3f266795c88dd35e03205d7a8234aa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2856734732 From almatvee at openjdk.org Wed May 7 01:34:13 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 May 2025 01:34:13 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v2] In-Reply-To: References: Message-ID: > - Symbolic links will not be followed for `--app-content` on all platforms. > - Added test to cover this case. > - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8352480 - 8352480: [macos] Don't follow symlinks in additional content for app images [v4] - 8352480: [macos] Don't follow symlinks in additional content for app images [v3] - 8352480: [macos] Don't follow symlinks in additional content for app images [v2] - 8352480: [macos] Don't follow symlinks in additional content for app images ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24974/files - new: https://git.openjdk.org/jdk/pull/24974/files/004304ed..519be97e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=00-01 Stats: 30202 lines in 804 files changed: 21331 ins; 5103 del; 3768 mod Patch: https://git.openjdk.org/jdk/pull/24974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24974/head:pull/24974 PR: https://git.openjdk.org/jdk/pull/24974 From almatvee at openjdk.org Wed May 7 01:34:13 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 May 2025 01:34:13 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 20:56:19 GMT, Alexey Semenyuk wrote: > I don't like the idea of changing behavior on only one platform. It should be consistent across all platforms. Let's not follow symlinks on other platforms, either. Fix is updated not to follow links on all platforms. Test is updated as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24974#issuecomment-2856762373 From yyang at openjdk.org Wed May 7 01:43:18 2025 From: yyang at openjdk.org (Yi Yang) Date: Wed, 7 May 2025 01:43:18 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato wrote: >>> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment) >> >> Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README. >> >> Is there some specific problem you are worried about on Windows that you were thinking about? > >> Is there some specific problem you are worried about on Windows that you were thinking about? > > I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas. > @naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale. > > I'll ping Yi Yang who was behind #3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before. > > @y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale? Sorry, I haven't worked on JDK for a while. Maybe @Glavo? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2856775920 From swen at openjdk.org Wed May 7 01:53:20 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 01:53:20 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v2] In-Reply-To: References: Message-ID: <0x4NlyUcYHzwYW-IIHRNJTNWIXRvcohZDad0eKVscNI=.bb774920-52df-4b0e-8c84-ee0d70c3d520@github.com> On Wed, 7 May 2025 01:34:13 GMT, Alexander Matveev wrote: >> - Symbolic links will not be followed for `--app-content` on all platforms. >> - Added test to cover this case. >> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8352480 > - 8352480: [macos] Don't follow symlinks in additional content for app images [v4] > - 8352480: [macos] Don't follow symlinks in additional content for app images [v3] > - 8352480: [macos] Don't follow symlinks in additional content for app images [v2] > - 8352480: [macos] Don't follow symlinks in additional content for app images test/jdk/tools/jpackage/share/AppContentTest.java line 37: > 35: import java.util.stream.Stream; > 36: import static jdk.internal.util.OperatingSystem.MACOS; > 37: import static jdk.internal.util.OperatingSystem.LINUX; Should the imports here be sorted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2076636260 From almatvee at openjdk.org Wed May 7 02:07:03 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 May 2025 02:07:03 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v3] In-Reply-To: References: Message-ID: > - Symbolic links will not be followed for `--app-content` on all platforms. > - Added test to cover this case. > - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8352480: [macos] Don't follow symlinks in additional content for app images [v5] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24974/files - new: https://git.openjdk.org/jdk/pull/24974/files/519be97e..166c3ffa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=01-02 Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24974/head:pull/24974 PR: https://git.openjdk.org/jdk/pull/24974 From almatvee at openjdk.org Wed May 7 02:07:05 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 May 2025 02:07:05 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v2] In-Reply-To: <0x4NlyUcYHzwYW-IIHRNJTNWIXRvcohZDad0eKVscNI=.bb774920-52df-4b0e-8c84-ee0d70c3d520@github.com> References: <0x4NlyUcYHzwYW-IIHRNJTNWIXRvcohZDad0eKVscNI=.bb774920-52df-4b0e-8c84-ee0d70c3d520@github.com> Message-ID: <1dns1SyGSQ85llY_Kqo98wTOpfm6WSvROxHacTyD7Ek=.0e491427-18de-4510-beea-09d2c096665a@github.com> On Wed, 7 May 2025 01:50:31 GMT, Shaojin Wen wrote: >> Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8352480 >> - 8352480: [macos] Don't follow symlinks in additional content for app images [v4] >> - 8352480: [macos] Don't follow symlinks in additional content for app images [v3] >> - 8352480: [macos] Don't follow symlinks in additional content for app images [v2] >> - 8352480: [macos] Don't follow symlinks in additional content for app images > > test/jdk/tools/jpackage/share/AppContentTest.java line 37: > >> 35: import java.util.stream.Stream; >> 36: import static jdk.internal.util.OperatingSystem.MACOS; >> 37: import static jdk.internal.util.OperatingSystem.LINUX; > > Should the imports here be sorted? Yes. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2076644634 From duke at openjdk.org Wed May 7 02:10:56 2025 From: duke at openjdk.org (erifan) Date: Wed, 7 May 2025 02:10:56 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... erifan 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: - Refactor code Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this optimization, making the code more modular. - Merge branch 'master' into JDK-8354242 - Update the jtreg test - Merge branch 'master' into JDK-8354242 - Addressed some review comments 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. 2. Improve code comments. - Merge branch 'master' into JDK-8354242 - Merge branch 'master' into JDK-8354242 - 8354242: VectorAPI: combine vector not operation with compare This patch optimizes the following patterns: For integer types: ``` (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) => (VectorMaskCmp src1 src2 ncond) (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) => (VectorMaskCmp src1 src2 ncond) ``` cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. For float and double types: ``` (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) ``` cond can be eq or ne. Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 testCompareLTMaskNotLong ops/s 856502.2695 12276.82851 1177671.815 496.723302 1.37 testCompareLTMaskNotShort ops/s 3325798.025 2412.702501 4711554.181 1779.302112 1.41 testCompareNEMaskNotByte ops/s 7910002.518 2771.82477 10245315.33 16321.93935 1.29 testCompareNEMaskNotDouble ops/s 863754.6022 523.140788 1179133.982 476.572178 1.36 testCompareNEMaskNotFloat ops/s 1723321.883 2598.484803 2358492.186 877.1401 1.36 testCompareNEMaskNotInt ops/s 1670288.841 751.774826 2354158.125 835.720163 1.4 testCompareNEMaskNotLong ops/s 836327.6835 410.525466 1178178.825 308.757932 1.4 testCompareNEMaskNotShort ops/s 3327815.841 1511.978763 4711379.136 2336.505531 1.41 testCompareUGEMaskNotByte ops/s 7906699.024 3200.936474 10253843.74 15067.59401 1.29 testCompareUGEMaskNotInt ops/s 1674003.923 3287.191727 2353340.666 951.381021 1.4 testCompareUGEMaskNotLong ops/s 852424.5562 8920.408939 1177943.609 389.6621 1.38 testCompareUGEMaskNotShort ops/s 3327255.858 1584.885143 4711622.355 1247.215277 1.41 testCompareUGTMaskNotByte ops/s 7909249.189 4435.283667 10245541.34 10993.34739 1.29 testCompareUGTMaskNotInt ops/s 1693713.433 20650.00213 2353153.787 1055.343846 1.38 testCompareUGTMaskNotLong ops/s 851022.3395 7079.065268 1177910.677 538.604598 1.38 testCompareUGTMaskNotShort ops/s 3327236.988 1616.886789 4711209.865 3098.494145 1.41 testCompareULEMaskNotByte ops/s 7909350.825 3251.262342 10261449.03 7273.831341 1.29 testCompareULEMaskNotInt ops/s 1672350.925 1545.304304 2353231.755 914.231193 1.4 testCompareULEMaskNotLong ops/s 853349.4765 9804.906913 1177967.254 435.044367 1.38 testCompareULEMaskNotShort ops/s 3325757.891 1555.062257 4712873.187 1650.986905 1.41 testCompareULTMaskNotByte ops/s 7912218.621 2633.477744 10242095.98 21921.39902 1.29 testCompareULTMaskNotInt ops/s 1673994.849 2672.507666 2353449.22 946.105757 1.4 testCompareULTMaskNotLong ops/s 849032.5868 10406.06689 1177586.047 506.541456 1.38 testCompareULTMaskNotShort ops/s 3328062.026 1892.991844 4713247.216 1855.983724 1.41 ``` With option `-XX:UseSVE=0`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 7895961.919 72712.90804 7746493.731 71481.92938 0.98 testCompareEQMaskNotDouble ops/s 789811.0455 384.493088 766473.7994 2216.581793 0.97 testCompareEQMaskNotFloat ops/s 1806305.818 638.010451 1819616.613 3295.38958 1 testCompareEQMaskNotInt ops/s 1815820.144 1225.336135 1849538.401 766.29902 1.01 testCompareEQMaskNotLong ops/s 807336.492 335.451807 792732.9483 277.954432 0.98 testCompareEQMaskNotShort ops/s 4818266.38 1927.862665 4668903.001 1922.782715 0.96 testCompareGEMaskNotByte ops/s 7818439.678 75374.97739 16498003.98 41440.49653 2.11 testCompareGEMaskNotInt ops/s 1815159.05 1090.912209 2372095.779 1664.397112 1.3 testCompareGEMaskNotLong ops/s 804324.5575 2301.686878 927919.8507 371.766719 1.15 testCompareGEMaskNotShort ops/s 4818966.563 2443.643652 5385561.038 29558.37423 1.11 testCompareGTMaskNotByte ops/s 7893406.157 82687.74264 16470663.2 22165.55812 2.08 testCompareGTMaskNotInt ops/s 1815316.812 915.894106 2370447.198 655.016338 1.3 testCompareGTMaskNotLong ops/s 807019.456 526.525482 928079.0541 330.582693 1.15 testCompareGTMaskNotShort ops/s 4820552.881 1684.247747 5355902.93 5893.2915 1.11 testCompareLEMaskNotByte ops/s 7816263.323 79560.0015 16473621.19 56688.99585 2.1 testCompareLEMaskNotInt ops/s 1814915.724 926.998625 2368790.306 932.594778 1.3 testCompareLEMaskNotLong ops/s 806483.9 935.718082 928110.9074 407.096695 1.15 testCompareLEMaskNotShort ops/s 4813660.241 6817.870509 5357107.852 10061.47975 1.11 testCompareLTMaskNotByte ops/s 7838948.962 69136.4504 16424405.96 24464.75469 2.09 testCompareLTMaskNotInt ops/s 1815056.833 1187.6453 2369892.187 1103.819634 1.3 testCompareLTMaskNotLong ops/s 806602.1804 287.923365 928346.4118 617.682824 1.15 testCompareLTMaskNotShort ops/s 4817940.643 2767.1509 5372537.84 15397.47169 1.11 testCompareNEMaskNotByte ops/s 9078493.798 4630.339307 16484348.42 18925.88346 1.81 testCompareNEMaskNotDouble ops/s 661769.6272 398.712981 926763.5839 1808.843788 1.4 testCompareNEMaskNotFloat ops/s 1570527.252 563.642144 2312425.678 1815.844846 1.47 testCompareNEMaskNotInt ops/s 1619146.58 626.793854 2369711.543 942.330478 1.46 testCompareNEMaskNotLong ops/s 680201.5381 2252.836482 927808.6147 414.917863 1.36 testCompareNEMaskNotShort ops/s 3763508.054 3622.560798 5367808.015 8591.466599 1.42 testCompareUGEMaskNotByte ops/s 7886373.129 75917.74675 16480928.93 27524.31005 2.08 testCompareUGEMaskNotInt ops/s 1815636.832 750.036241 2369683.015 901.609404 1.3 testCompareUGEMaskNotLong ops/s 806862.5826 287.819616 928001.4394 361.063837 1.15 testCompareUGEMaskNotShort ops/s 4820581.361 2098.537435 5375854.248 25619.40165 1.11 testCompareUGTMaskNotByte ops/s 7891591.465 96614.93542 16410405.93 15012.37096 2.07 testCompareUGTMaskNotInt ops/s 1814871.179 662.825588 2371325.903 1170.491164 1.3 testCompareUGTMaskNotLong ops/s 804013.7658 2240.534209 928062.2169 531.306897 1.15 testCompareUGTMaskNotShort ops/s 4818150.337 3051.717685 5381449.337 21212.34187 1.11 testCompareULEMaskNotByte ops/s 7831540.628 81306.67253 16495250.78 38682.19675 2.1 testCompareULEMaskNotInt ops/s 1814484.14 687.860656 2369265.075 940.609586 1.3 testCompareULEMaskNotLong ops/s 807780.5749 769.876816 927538.0732 1278.267724 1.14 testCompareULEMaskNotShort ops/s 4817437.42 5141.336541 5356183.359 7015.608124 1.11 testCompareULTMaskNotByte ops/s 7849078.225 56753.59764 16395975.27 34043.67295 2.08 testCompareULTMaskNotInt ops/s 1814328.226 2697.219111 2370700.47 1991.841988 1.3 testCompareULTMaskNotLong ops/s 807166.8197 253.061506 927926.2803 252.933462 1.14 testCompareULTMaskNotShort ops/s 4821098.216 1625.959044 5348980.243 4100.768121 1.1 ``` Benchmarks on AMD EPYC 9124 16-Core Processor: With option `-XX:UseAVX=3`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 16607323.35 1233692.631 18381557.66 1163201.522 1.1 testCompareEQMaskNotDouble ops/s 2114285.245 58782.2534 2959946.353 43016.0445 1.39 testCompareEQMaskNotFloat ops/s 4480874.437 89975.29074 6960151.436 64799.143 1.55 testCompareEQMaskNotInt ops/s 4370906.91 51784.80889 6856955.043 313858.5504 1.56 testCompareEQMaskNotLong ops/s 2080065.895 26762.06732 2939142.143 67179.05314 1.41 testCompareEQMaskNotShort ops/s 7968282.563 210437.2781 12701214.56 473152.6407 1.59 testCompareGEMaskNotByte ops/s 18419141.89 473408.9451 19880059.68 321638.0397 1.07 testCompareGEMaskNotInt ops/s 4419015.62 77352.98633 7037639.227 151066.0383 1.59 testCompareGEMaskNotLong ops/s 2147982.48 49227.42782 3000275.928 39298.75344 1.39 testCompareGEMaskNotShort ops/s 8469039.613 17833.19707 12288229.49 244317.8812 1.45 testCompareGTMaskNotByte ops/s 18728997.5 468328.8358 20544730.05 392264.6466 1.09 testCompareGTMaskNotInt ops/s 4510009.705 78812.57357 7364629.942 70970.78473 1.63 testCompareGTMaskNotLong ops/s 2124104.969 40917.89257 2953536.279 35199.19687 1.39 testCompareGTMaskNotShort ops/s 8690557.621 311534.1159 12344017.51 457931.8741 1.42 testCompareLEMaskNotByte ops/s 17758400.53 478383.4945 19209183.26 1143297.241 1.08 testCompareLEMaskNotInt ops/s 4363664.862 43443.18063 7054093.064 78141.11476 1.61 testCompareLEMaskNotLong ops/s 2068632.213 29844.78023 2954766.412 50667.22502 1.42 testCompareLEMaskNotShort ops/s 8637608.548 183538.5511 12719010.27 473568.8825 1.47 testCompareLTMaskNotByte ops/s 14406138.95 423105.0163 17292417.96 371386.9689 1.2 testCompareLTMaskNotInt ops/s 4546707.266 131977.3144 7040483.394 213590.4657 1.54 testCompareLTMaskNotLong ops/s 2123277.356 47243.21499 2848720.442 58896.97045 1.34 testCompareLTMaskNotShort ops/s 7570169.363 649873.6295 11945383.75 988276.5955 1.57 testCompareNEMaskNotByte ops/s 18274529.55 683396.7384 19081938.8 1118739.778 1.04 testCompareNEMaskNotDouble ops/s 2112533.61 43295.50012 2912115.441 78189.51083 1.37 testCompareNEMaskNotFloat ops/s 4628683.814 93817.07362 6967208.729 145135.8544 1.5 testCompareNEMaskNotInt ops/s 4470900.214 75974.50842 7286913.662 116328.5277 1.62 testCompareNEMaskNotLong ops/s 2134091.061 46377.94061 2934667.477 81675.46021 1.37 testCompareNEMaskNotShort ops/s 8790384.287 396161.8599 13076858.35 286272.1155 1.48 testCompareUGEMaskNotByte ops/s 18009150.9 660803.8886 17551258.33 1667014.843 0.97 testCompareUGEMaskNotInt ops/s 4442928.74 83190.81019 6854088.277 329008.8901 1.54 testCompareUGEMaskNotLong ops/s 2088357.736 71696.24791 2973202.26 63278.78974 1.42 testCompareUGEMaskNotShort ops/s 8348624.02 116562.7876 12832250.78 546869.3006 1.53 testCompareUGTMaskNotByte ops/s 17871101.25 800199.6321 19902619.81 214003.3262 1.11 testCompareUGTMaskNotInt ops/s 4088304.421 137797.9723 7135454.33 124553.651 1.74 testCompareUGTMaskNotLong ops/s 2070610.42 19881.82182 2991536.365 36260.60767 1.44 testCompareUGTMaskNotShort ops/s 8637099.341 155822.1608 12756579.77 186068.199 1.47 testCompareULEMaskNotByte ops/s 17940901.36 1258029.364 18932484.94 694554.6305 1.05 testCompareULEMaskNotInt ops/s 4369177.511 74982.31936 6392773.082 550171.2266 1.46 testCompareULEMaskNotLong ops/s 2135905.761 43693.63178 2877579.631 41651.56289 1.34 testCompareULEMaskNotShort ops/s 8607710.544 132655.1676 12446370.04 441718.3035 1.44 testCompareULTMaskNotByte ops/s 17409912.23 1033204.537 20607479.99 362000.5056 1.18 testCompareULTMaskNotInt ops/s 4386455.9 119192.1635 6920123.264 186158.2845 1.57 testCompareULTMaskNotLong ops/s 2064995.149 38622.2734 2988343.589 39037.90006 1.44 testCompareULTMaskNotShort ops/s 8642182.752 230919.2442 13029582.09 437101.4923 1.5 ``` The small amount of performance degradation is due to test fluctuations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24674/files - new: https://git.openjdk.org/jdk/pull/24674/files/4fbf84e3..001fac0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=03-04 Stats: 27362 lines in 755 files changed: 19223 ins; 4813 del; 3326 mod Patch: https://git.openjdk.org/jdk/pull/24674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674 PR: https://git.openjdk.org/jdk/pull/24674 From duke at openjdk.org Wed May 7 02:10:56 2025 From: duke at openjdk.org (erifan) Date: Wed, 7 May 2025 02:10:56 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v3] In-Reply-To: References: <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com> Message-ID: On Thu, 1 May 2025 07:32:22 GMT, erifan wrote: >> Yes, this discussion is down to `requires` vs `applyIf`. This is my argument for `applyIf`, quoted from above, I have not yet seen an argument against it: >> >>> If you use @require, then the person does not realize there is a test AND the test is not run. If you use applyIf, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash. >> >> In my understanding, `requires` should only be used if the test really **requires** a certain platform or feature. That can be because some flags are only available under certain platforms for example. But for IR tests, we should try to always use `applyIf`, because it allows testing on other platforms. >> >> Actually, I filed this RFE a while ago: https://bugs.openjdk.org/browse/JDK-8310891 >> We should try to move as many tests from using `requires` to `applyIf`, so that we have an increased test coverage. > > @eme64 @jatin-bhateja I have updated the test, thanks for your suggestion. > @erifan thanks for updating the tests! > > Now I had a quick look at the VM code. > > My biggest observation is this: > > Wrapping `VectorNode::Ideal` somewhere in the middle of your new optimization is going to make future optimizations here much harder. How would they check their conditions next to yours? That would be quite a mess. > > I suggest you do this: > > * `XorVNode::Ideal` does > > * checks `in1 == in2` case > * calls a method called `XorVNode::Ideal_XorV_VectorMaskCmp`. Check if it succeeded, i.e. returns `nullptr`. > * ... future optimizations could go here ... > * Finally, i.e. none of the optimizations above worked: call `VectorNode::Ideal` > > Then you pack all your new logic here into `XorVNode::Ideal_XorV_VectorMaskCmp`. You can also find a better name, it is just what I came up with just now. > > This gives us a much more **modular** design, and it is easier to add another new optimization to `XorVNode::Ideal`. It is easy to change the precedence of the optimizations by just changing the order, etc. > > Examples of this "modular" design: > > * `CMoveNode::Ideal` -> calls `TypeNode::Ideal` and `Ideal_minmax`. > * `StoreBNode::Ideal` -> calls `StoreNode::Ideal_masked_input` and `StoreNode::Ideal_sign_extended_input` > These are really nice, because you can quickly see what optimizations we already have, and in which order they are checked. Yes, this is a good idea, I have changed it like this, thanks for your suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2856811448 From duke at openjdk.org Wed May 7 02:10:56 2025 From: duke at openjdk.org (erifan) Date: Wed, 7 May 2025 02:10:56 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 06:14:33 GMT, Emanuel Peter wrote: >> src/hotspot/share/opto/vectornode.cpp line 2216: >> >>> 2214: in2->is_predicated_vector()) { >>> 2215: with_predicated = true; >>> 2216: } >> >> Suggestion: >> >> bool with_predicated = is_predicated_vector() || >> in1->is_predicated_vector() || >> in2->is_predicated_vector(); > > Would that not be easier to read? Yes, done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076645802 From duke at openjdk.org Wed May 7 02:10:58 2025 From: duke at openjdk.org (erifan) Date: Wed, 7 May 2025 02:10:58 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v4] In-Reply-To: References: Message-ID: <4ZhJjZtiOsmaTZzKbYFE99Q-J01WP_8kDB3Egx5znHY=.54b633f8-73ba-4083-8946-524c8bd6e47e@github.com> On Fri, 2 May 2025 06:16:03 GMT, Emanuel Peter wrote: >> erifan 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: >> >> - Update the jtreg test >> - Merge branch 'master' into JDK-8354242 >> - Addressed some review comments >> >> 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. >> 2. Improve code comments. >> - Merge branch 'master' into JDK-8354242 >> - Merge branch 'master' into JDK-8354242 >> - 8354242: VectorAPI: combine vector not operation with compare >> >> This patch optimizes the following patterns: >> For integer types: >> ``` >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> ``` >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the >> negative comparison of cond. >> >> For float and double types: >> ``` >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> ``` >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: >> With option `-XX:UseSVE=2`: >> ``` >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 1... > > src/hotspot/share/opto/vectornode.cpp line 2224: > >> 2222: // => (VectorMaskCmp src1 src2 ncond) >> 2223: // cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the >> 2224: // negative comparison of cond. > > Suggestion: > > // cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt. > // ncond is the negative comparison of cond. > > I was getting lost in all the commas. Done. > src/hotspot/share/opto/vectornode.cpp line 2248: > >> 2246: !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() || >> 2247: !VectorNode::is_all_ones_vector(in2)) { >> 2248: return VectorNode::Ideal(phase, can_reshape); > > Hmm, so this is really the "else" case, if your optimization does not succeed, right? > > Wrapping `VectorNode::Ideal` somewhere in the middle is going to make future optimizations here much harder. > How would they check their conditions next to yours? That would be quite a mess. > > I suggest you do this: > - `XorVNode::Ideal` does > - checks `in1 == in2` case > - calls a method called `XorVNode::Ideal_XorV_VectorMaskCmp`. Check if it succeeded, i.e. returns `nullptr`. > - Finally, i.e. none of the optimizations above worked: call `VectorNode::Ideal` > > Then you pack all your new logic here into `XorVNode::Ideal_XorV_VectorMaskCmp`. You can also find a better name, it is just what I came up with just now. > > This gives us a much more **modular** design, and it is easier to add another new optimization to `XorVNode::Ideal`. It is easy to change the precedence of the optimizations by just changing the order, etc. Done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076646028 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076646366 From asmehra at openjdk.org Wed May 7 02:40:15 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 02:40:15 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments src/hotspot/share/cds/cdsConfig.cpp line 428: > 426: > 427: // At least one AOT flag has been used > 428: _new_aot_flags_used = true; indentation seems off? src/hotspot/share/cds/cdsConfig.cpp line 490: > 488: bool has_output = !FLAG_IS_DEFAULT(AOTCacheOutput); > 489: > 490: if (has_output) { Can this if-else block be refactored as: if (!has_output && !has_config) { vm_exit_during_initialization("..."); } if (has_output) { } This pattern in much easier to read IMO. src/hotspot/share/cds/cdsConfig.cpp line 504: > 502: } else { > 503: if (!has_config) { > 504: vm_exit_during_initialization("-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration"); I suggest to be consistent in phrasing the error messages related to incomplete options. I liked the way it is worded in `check_aotmode_create()`. So my preference is to replace `-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration` with `AOTCacheOutput or AOTConfiguration must be specified when using -XX:AOTMode=record`. But you may chose otherwise as long as the structure of the error messages is consistent. src/hotspot/share/cds/cdsConfig.cpp line 526: > 524: void CDSConfig::check_aotmode_create() { > 525: if (FLAG_IS_DEFAULT(AOTConfiguration)) { > 526: vm_exit_during_initialization("-XX:AOTMode=create cannot be used without setting AOTConfiguration"); Same suggestion regarding error msg: Replace `-XX:AOTMode=create cannot be used without setting AOTConfiguration` with `AOTConfiguration must be specified when using -XX:AOTMode=create` src/hotspot/share/cds/metaspaceShared.cpp line 1082: > 1080: for (int i = 0; i < Arguments::num_jvm_args(); i++) { > 1081: const char* arg = Arguments::jvm_args_array()[i]; > 1082: if (strncmp("-XX:AOTCacheOutput=", arg, 19) == 0 || I have seen this hard coding of string length in the `strncmp` call many times in the code base. I wonder why we don't use something like this: strncmp("-XX:AOTCacheOutput=", arg, sizeof("-XX:AOTCacheOutput=")-1) Counting chars is really error prone. sizeof("...")-1 gives the same result. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076664964 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076665081 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667404 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667613 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667744 From swen at openjdk.org Wed May 7 03:08:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 03:08:14 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Tue, 6 May 2025 17:16:32 GMT, Shaojin Wen wrote: >> I have the old switch format in anticipation of faster startup. > > enhanced 'switch' is just syntax sugar and does not affect startup speed I looked at the generated bytecode through javap and confirmed that the enhanced switch is just syntactic sugar and no additional classes are generated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076686117 From swen at openjdk.org Wed May 7 03:12:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 03:12:14 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v4] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Tue, 6 May 2025 12:32:38 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 121: > 119: return obj instanceof BasicKey that && > 120: returnType.equals(that.returnType) && > 121: stateName.equals(that.stateName); Suggestion: return obj instanceof BasicKey that && returnType.equals(that.returnType) && stateName.equals(that.stateName); In the JDK source code, the operator && is placed in front in most cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076688887 From swen at openjdk.org Wed May 7 03:22:13 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 03:22:13 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v4] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Tue, 6 May 2025 12:32:38 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 78: > 76: inputs.add(new BasicKey(c, layout.name().orElseThrow())); > 77: } > 78: } Suggestion: for (MemoryLayout layout : CAPTURE_LAYOUT.memberLayouts()) { String name = layout.name().orElseThrow(); inputs.add(new BasicKey(int.class, name)); inputs.add(new BasicKey(long.class, name)); } There are only two classes, int.class and long.class, so this might be simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076694737 From swen at openjdk.org Wed May 7 03:28:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 03:28:14 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v4] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Tue, 6 May 2025 12:32:38 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 215: > 213: } > 214: // Last takes first > 215: perm[target.type().parameterCount()] = 0; Suggestion: for (int i = 0; i < perm.length - 1; i++) { perm[i] = i; } // Last takes first perm[perm.length - 1] = 0; Here you can use perm.length - 1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076701381 From iklam at openjdk.org Wed May 7 05:11:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 05:11:01 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v4] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/0eb8b545..5004a0b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=02-03 Stats: 19 lines in 5 files changed: 4 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Wed May 7 05:11:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 05:11:01 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 02:33:50 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @vnkozlov comments > > src/hotspot/share/cds/cdsConfig.cpp line 428: > >> 426: >> 427: // At least one AOT flag has been used >> 428: _new_aot_flags_used = true; > > indentation seems off? Fixed. > src/hotspot/share/cds/cdsConfig.cpp line 490: > >> 488: bool has_output = !FLAG_IS_DEFAULT(AOTCacheOutput); >> 489: >> 490: if (has_output) { > > Can this if-else block be refactored as: > > > if (!has_output && !has_config) { > vm_exit_during_initialization("..."); > } > if (has_output) { > > } > > This pattern in much easier to read IMO. Fixed. > src/hotspot/share/cds/cdsConfig.cpp line 504: > >> 502: } else { >> 503: if (!has_config) { >> 504: vm_exit_during_initialization("-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration"); > > I suggest to be consistent in phrasing the error messages related to incomplete options. I liked the way it is worded in `check_aotmode_create()`. So my preference is to replace `-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration` with `AOTCacheOutput or AOTConfiguration must be specified when using -XX:AOTMode=record`. But you may chose otherwise as long as the structure of the error messages is consistent. I changed to "At least one of AOTCacheOutput and AOTConfiguration must be specified when using -XX:AOTMode=record", so it's clear that both option can be specified together. > src/hotspot/share/cds/cdsConfig.cpp line 526: > >> 524: void CDSConfig::check_aotmode_create() { >> 525: if (FLAG_IS_DEFAULT(AOTConfiguration)) { >> 526: vm_exit_during_initialization("-XX:AOTMode=create cannot be used without setting AOTConfiguration"); > > Same suggestion regarding error msg: > Replace `-XX:AOTMode=create cannot be used without setting AOTConfiguration` > with > `AOTConfiguration must be specified when using -XX:AOTMode=create` Fixed. > src/hotspot/share/cds/metaspaceShared.cpp line 1082: > >> 1080: for (int i = 0; i < Arguments::num_jvm_args(); i++) { >> 1081: const char* arg = Arguments::jvm_args_array()[i]; >> 1082: if (strncmp("-XX:AOTCacheOutput=", arg, 19) == 0 || > > I have seen this hard coding of string length in the `strncmp` call many times in the code base. I wonder why we don't use something like this: > > strncmp("-XX:AOTCacheOutput=", arg, sizeof("-XX:AOTCacheOutput=")-1) > > Counting chars is really error prone. sizeof("...")-1 gives the same result. I end up using `strstr()`, as I don't want to repeat the string literal twice (risking a typo) or use a macro. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796934 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796911 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796869 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796827 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796802 From alanb at openjdk.org Wed May 7 06:09:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 06:09:14 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: <5sF6nQjDykFcP5-etCpaYidBIGkJvNUzjC6PYRGfuGA=.71fc9b7e-40c8-4ee1-8a67-9b9181cda6ae@github.com> On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter wrote: >> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set The implementation changes looks okay. I assume the CSR will be expanded, e.g. to list deleteOnExit as Jason mentioned, before we can review it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2857168778 From duke at openjdk.org Wed May 7 06:19:17 2025 From: duke at openjdk.org (Bernd) Date: Wed, 7 May 2025 06:19:17 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter wrote: >> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set Maybe the Release Notes should mention that this does not care for Unix readonly (I.e. files without Read permissions). Some tools warn about deleting such files on Linux, too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2857201912 From duke at openjdk.org Wed May 7 06:22:19 2025 From: duke at openjdk.org (Daishi Tabata) Date: Wed, 7 May 2025 06:22:19 GMT Subject: Integrated: 8355249: Remove the use of WMIC from the entire source code In-Reply-To: References: Message-ID: On Tue, 22 Apr 2025 07:29:08 GMT, Daishi Tabata wrote: > After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. > > The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. > > Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. > Note: In my environment, it worked correctly even without these options. > > The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: > > - `environment.html`: `windows/system/os` section > - `process.html`: `[Process ID]/windows/native/info` section > > **Testing:** > I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. This pull request has now been integrated. Changeset: 4458719a Author: Daishi Tabata Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/4458719a108f45d3744d47a6ea081fe9ec3e675e Stats: 32 lines in 4 files changed: 6 ins; 2 del; 24 mod 8355249: Remove the use of WMIC from the entire source code Reviewed-by: erikj, ihse, asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/24791 From duke at openjdk.org Wed May 7 06:23:24 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 7 May 2025 06:23:24 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG 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 latest from master branch > - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? > - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs > - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. > - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' > - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() > - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() > - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' > - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? > - Applied changes requested by Alan: Copies chars from this sequence into the given destination array > - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a Github Actions have successfully passed all checks. ?? ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2857242098 From alanb at openjdk.org Wed May 7 06:34:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 06:34:14 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: <0ylrb_KFxt2743YSl-GAK03cv9xcQWQmXivbCu1jGsw=.84fa516a-cefe-4d45-98f9-f9262e04c5dd@github.com> On Wed, 7 May 2025 06:16:53 GMT, Bernd wrote: > Maybe the Release Notes should mention that this does not care for Unix readonly (I.e. files without Read permissions). The release note will be clear that this is a Windows only change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2857268088 From jlahoda at openjdk.org Wed May 7 06:34:14 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 7 May 2025 06:34:14 GMT Subject: RFR: 8354260: Launcher help text is wrong for -Xms In-Reply-To: References: Message-ID: On Tue, 6 May 2025 08:02:21 GMT, Christian Stein wrote: > Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage. > > Copied from the issue: >> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size. >> >> ```` >> $ java -X >> ... >> -Xms set initial Java heap size >> ```` >> >> From the manpage: >> ```` >> `-Xms` *size* >> : Sets the minimum and the initial size (in bytes) of the heap. This value >> must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or >> `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G` >> to indicate gigabytes. The following examples show how to set the size of >> allocated memory to 6 MB using various units: >> ```` Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25058#pullrequestreview-2820511606 From alan.bateman at oracle.com Wed May 7 06:54:33 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 7 May 2025 07:54:33 +0100 Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an efficient alternative to java.io.StringWriter In-Reply-To: <1b7d9c21-bfb1-43d1-945d-5d8597000968@headcrashing.eu> References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu> <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu> <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu> <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com> <1b7d9c21-bfb1-43d1-945d-5d8597000968@headcrashing.eu> Message-ID: On 15/03/2025 17:58, Markus KARG wrote: > Chen, > > thank you for sharing your opinion! > > Thinking about what you wrote about the "trifecta" complexity, I think > it might be better to restart my idea from scratch: > > As explained in my original proposal > (https://mail.openjdk.org/pipermail/core-libs-dev/2024-December/137807.html), > the actual driver for my proposal was to provide a StringWriter > alternative which solves two main problems: It shall prevent String > copies, and it shall be non-synchronized. > > What comes into mind is: Writer.of(StringBuilder). > > While compared to Appendable this signature is much less flexible, it > also makes less headaches, but solved in fact those 99% of cases that > triggered this whole idea: It does not create String copies, and it is > non-synchronized. What this writer would simply, simply would be > routing all incoming "append" and "write" calls down to the provided > string builder. > > Hence, kindly asking for comments on this updated idea: WDYT about > Writer.of(StringBuilder)? I think the main issue with Writer.of(SB) is that the usages would requiring hopping between SB, Writer, then back to SB. That is, you start accumulating characters in the SB, then wrap it with a Writer to write/append characters with a different API, be careful to flush/close so that all characters get to the SB, then back to the SB to append more before creating the String. That seems a bit fragile and very different to the decoration/wrapping when using reader/writers. You've made it clear that your motivation is performance and avoiding the synchronization and internal buffer of StringWriter. I think it would be useful if you could expand a bit on the pain points. Maye this is about rehabilitating StringWriter or maybe it's about making it easier and more efficient to bridge between StringWriter and other Appendables. Expanding more on the problem might help to give you some suggestions and directions to explore and prototype. -Alan From alanb at openjdk.org Wed May 7 07:01:27 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 07:01:27 GMT Subject: RFR: 8354260: Launcher help text is wrong for -Xms In-Reply-To: References: Message-ID: On Tue, 6 May 2025 08:02:21 GMT, Christian Stein wrote: > Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage. > > Copied from the issue: >> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size. >> >> ```` >> $ java -X >> ... >> -Xms set initial Java heap size >> ```` >> >> From the manpage: >> ```` >> `-Xms` *size* >> : Sets the minimum and the initial size (in bytes) of the heap. This value >> must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or >> `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G` >> to indicate gigabytes. The following examples show how to set the size of >> allocated memory to 6 MB using various units: >> ```` I checked java.md to make sure that it doesn't need any update too, all good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25058#issuecomment-2857344128 From cstein at openjdk.org Wed May 7 07:01:27 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 07:01:27 GMT Subject: Integrated: 8354260: Launcher help text is wrong for -Xms In-Reply-To: References: Message-ID: On Tue, 6 May 2025 08:02:21 GMT, Christian Stein wrote: > Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage. > > Copied from the issue: >> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size. >> >> ```` >> $ java -X >> ... >> -Xms set initial Java heap size >> ```` >> >> From the manpage: >> ```` >> `-Xms` *size* >> : Sets the minimum and the initial size (in bytes) of the heap. This value >> must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or >> `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G` >> to indicate gigabytes. The following examples show how to set the size of >> allocated memory to 6 MB using various units: >> ```` This pull request has now been integrated. Changeset: 910d77d3 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/910d77d39e6fb9ca339272c75fa4ff7ff99bffcf Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8354260: Launcher help text is wrong for -Xms Reviewed-by: jsikstro, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/25058 From alanb at openjdk.org Wed May 7 07:02:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 07:02:42 GMT Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v11] In-Reply-To: References: Message-ID: > Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically: > > - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. > - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. > - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. > - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. > - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. > > The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into JDK-8342486 - Merge branch 'master' into JDK-8342486 - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - Merge branch 'master' into JDK-8342486 - Add JEP number, update copyright headers - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f ------------- Changes: https://git.openjdk.org/jdk/pull/21934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=10 Stats: 4039 lines in 14 files changed: 1821 ins; 1438 del; 780 mod Patch: https://git.openjdk.org/jdk/pull/21934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934 PR: https://git.openjdk.org/jdk/pull/21934 From jbhateja at openjdk.org Wed May 7 07:03:32 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 7 May 2025 07:03:32 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 02:10:56 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan 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: > > - Refactor code > > Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this > optimization, making the code more modular. > - Merge branch 'master' into JDK-8354242 > - Update the jtreg test > - Merge branch 'master' into JDK-8354242 > - Addressed some review comments > > 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. > 2. Improve code comments. > - Merge branch 'master' into JDK-8354242 > - Merge branch 'master' into JDK-8354242 > - 8354242: VectorAPI: combine vector not operation with compare > > This patch optimizes the following patterns: > For integer types: > ``` > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > ``` > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the > negative comparison of cond. > > For float and double types: > ``` > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > ``` > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: > With option `-XX:UseSVE=2`: > ``` > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4... src/hotspot/share/opto/vectornode.cpp line 2231: > 2229: } > 2230: if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 || > 2231: !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() || Do you plan to extend your testcase / matching logic to cover following equivalent patterns: - compare.xor(maskAll(true)) - compare.xor(VectorMask.fromLong(SPECIES, -1L)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076939541 From swen at openjdk.org Wed May 7 07:11:22 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 07:11:22 GMT Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:02:42 GMT, Alan Bateman wrote: >> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically: >> >> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. >> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. >> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. >> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. >> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. >> >> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Add JEP number, update copyright headers > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 51: > 49: private static final int ST_JOIN_STARTED = 2; // join started, can no longer fork > 50: private static final int ST_JOIN_COMPLETED = 3; // join completed > 51: private static final int ST_CLOSED = 4; // closed Suggestion: private static final int ST_NEW = 0, ST_FORKED = 1, // subtasks forked, need to join ST_JOIN_STARTED = 2, // join started, can no longer fork ST_JOIN_COMPLETED = 3, // join completed ST_CLOSED = 4; // closed This is more readable ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076953403 From swen at openjdk.org Wed May 7 07:21:23 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 07:21:23 GMT Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:02:42 GMT, Alan Bateman wrote: >> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically: >> >> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. >> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. >> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. >> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. >> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. >> >> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Add JEP number, update copyright headers > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f src/java.base/share/classes/java/util/concurrent/Joiners.java line 84: > 82: @SuppressWarnings("unchecked") > 83: var s = (Subtask) subtask; > 84: subtasks.add(s); Suggestion: subtasks.add((Subtask) subtask); The local variable s is only used once and can be simplified src/java.base/share/classes/java/util/concurrent/Joiners.java line 103: > 101: } else { > 102: return subtasks.stream(); > 103: } Suggestion: return subtasks.stream(); The else here is redundant src/java.base/share/classes/java/util/concurrent/Joiners.java line 155: > 153: case FAILED -> throw subtask.exception(); > 154: default -> throw new InternalError(); > 155: }; Suggestion: return switch (subtask.state()) { case SUCCESS -> subtask.get(); case FAILED -> throw subtask.exception(); default -> throw new InternalError(); }; The switch of the stateToInt method is aligned, so it should also be aligned here to keep the style consistent src/java.base/share/classes/java/util/concurrent/Joiners.java line 183: > 181: } else { > 182: return null; > 183: } Suggestion: if (ex != null) { throw ex; } return null; The else here is redundant src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 820: > 818: @PreviewFeature(feature = PreviewFeature.Feature.STRUCTURED_CONCURRENCY) > 819: final class TimeoutException extends RuntimeException { > 820: @java.io.Serial Use import without full path ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076962370 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076959693 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076964945 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076957675 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076968111 From mbaesken at openjdk.org Wed May 7 07:23:16 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 May 2025 07:23:16 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision: >> >> - Also document UTF-8 requirements (solves JDK-8338973) >> - Let configure only accept utf-8 locales >> - Address review comments from Kim > > make/autoconf/basic.m4 line 155: > >> 153: else >> 154: AC_MSG_RESULT([no UTF-8 locale found]) >> 155: AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.]) > > Seems we run into this 'else' part on AIX > > > checking for locale to use... no UTF-8 locale found > configure: error: No UTF-8 locale found. This is required for building successfully. > configure exiting with result code 1 > > maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity? (have to check if there are other names on AIX) > @MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :) Sounds good to me , thanks for adjusting ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2076970234 From swen at openjdk.org Wed May 7 07:24:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 07:24:18 GMT Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:02:42 GMT, Alan Bateman wrote: >> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically: >> >> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. >> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. >> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. >> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. >> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. >> >> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Add JEP number, update copyright headers > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 389: > 387: Throwable ex = ((AltResult) result).exception(); > 388: yield "[Failed: " + ex + "]"; > 389: } Suggestion: String stateAsString = switch (state()) { case UNAVAILABLE -> "[Unavailable]"; case SUCCESS -> "[Completed successfully]"; case FAILED -> "[Failed: " + ((AltResult) result).exception() + "]"; }; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076973064 From vyazici at openjdk.org Wed May 7 07:29:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:29:55 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Fix typo in pre-existing JavaDoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24982/files - new: https://git.openjdk.org/jdk/pull/24982/files/ef88b10a..f0623258 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From vyazici at openjdk.org Wed May 7 07:29:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:29:55 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:26:56 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314: > 312: *

    > 313: * WARNING: The caller of this method shall relinquish and transfer the > 314: * ownership of the byte array to the callee, since the later will not Suggestion: * ownership of the byte array to the callee, since the latter will not ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076979439 From vyazici at openjdk.org Wed May 7 07:29:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:29:55 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:39:55 GMT, Roger Riggs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314: > >> 312: *

    >> 313: * WARNING: The caller of this method shall relinquish and transfer the >> 314: * ownership of the byte array to the callee, since the later will not > > Typo: "later" -> "latter". (pre-existing) Fixed in f0623258e0506c68a274a1e094039bd6d76e3fa6. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076980772 From vyazici at openjdk.org Wed May 7 07:33:14 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:33:14 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: <7Tq127ca8kJ6NdghXUbeFL5cT4HC7dEe9-0ySUirpy8=.999f9f7c-2118-4d4a-83c1-d67fb006a2e4@github.com> On Thu, 1 May 2025 13:00:37 GMT, Chen Liang wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 315: > >> 313: * WARNING: The caller of this method shall relinquish and transfer the >> 314: * ownership of the byte array to the callee, since the later will not >> 315: * make a copy. > > I think we should add a note on why no copy is made - there may be multiple reads to the input array for decoding, so the input array must not be accessible by untrusted code, which can racily modify it. A side effect is that this array is simply reused if it's eligible to be the string content array, which is unfortunately abused in a few places in the JDK. @liach, thank you so much for the review and the feedback. We internally discussed this and decided leave the change as is. Resolving this conversation. Please let me know if you think otherwise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076985931 From swen at openjdk.org Wed May 7 07:37:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 07:37:18 GMT Subject: RFR: 8341184: Clean up the interaction between the launcher native code and the LauncherHelper [v16] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 09:46:29 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. >> >> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code. >> >> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - ... and 6 more: https://git.openjdk.org/jdk/compare/e410af00...d1ac5174 src/java.base/share/classes/sun/launcher/LauncherHelper.java line 946: > 944: JAVAFX_APPLICATION_CLASS_NAME); > 945: } > 946: } Suggestion: if (!PreviewFeatures.isEnabled()) { int mods = mainMethod.getModifiers(); if (!Modifier.isStatic(mods) || !Modifier.isPublic(mods) || mainMethod.getParameterCount() == 0) { abort(null, "java.launcher.cls.error2", builder.mainClass.getName(), JAVAFX_APPLICATION_CLASS_NAME); } } Remove variables that are only used once ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21256#discussion_r2076992705 From alanb at openjdk.org Wed May 7 07:40:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 07:40:14 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302: > 300: * WARNING: This method does not perform any bound checks. > 301: */ > 302: int countPositives(byte[] ba, int off, int len); Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076997921 From pminborg at openjdk.org Wed May 7 07:46:45 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 07:46:45 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v3] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com> > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add a method handle based field updater ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/52e96c52..83ce9ac1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=01-02 Stats: 95 lines in 2 files changed: 95 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From alanb at openjdk.org Wed May 7 07:55:16 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 07:55:16 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 332: > 330: *

    > 331: * This method throws {@code CharacterCodingException} instead of replacing > 332: * when malformed input or unmappable characters are encountered. Do we have a JBS issue to track renaming the "no replacement" methods? The naming has confused several people as not everyone is familiar with coding error actions. Here, "no replacement" actually means that coding errors are reported. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077022991 From pminborg at openjdk.org Wed May 7 07:56:48 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 07:56:48 GMT Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out Message-ID: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> This PR proposes to skip a stress test if the `main` thread is a virtual thread. ------------- Commit messages: - Skip stress if main is a virtual thread Changes: https://git.openjdk.org/jdk/pull/25084/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356114 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25084/head:pull/25084 PR: https://git.openjdk.org/jdk/pull/25084 From duke at openjdk.org Wed May 7 07:57:19 2025 From: duke at openjdk.org (erifan) Date: Wed, 7 May 2025 07:57:19 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 06:59:34 GMT, Jatin Bhateja wrote: >> erifan 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: >> >> - Refactor code >> >> Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this >> optimization, making the code more modular. >> - Merge branch 'master' into JDK-8354242 >> - Update the jtreg test >> - Merge branch 'master' into JDK-8354242 >> - Addressed some review comments >> >> 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. >> 2. Improve code comments. >> - Merge branch 'master' into JDK-8354242 >> - Merge branch 'master' into JDK-8354242 >> - 8354242: VectorAPI: combine vector not operation with compare >> >> This patch optimizes the following patterns: >> For integer types: >> ``` >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> ``` >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the >> negative comparison of cond. >> >> For float and double types: >> ``` >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> ``` >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: >> With option `-XX:UseSVE=2`: >> ``` >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.156... > > src/hotspot/share/opto/vectornode.cpp line 2231: > >> 2229: } >> 2230: if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 || >> 2231: !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() || > > Do you plan to extend your testcase / matching logic to cover following equivalent patterns: > > - compare.xor(maskAll(true)) > - compare.xor(VectorMask.fromLong(SPECIES, -1L)) Oh, I didn't think of this case, let me try. Thanks~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077026150 From swen at openjdk.org Wed May 7 08:00:23 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 7 May 2025 08:00:23 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v3] In-Reply-To: <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com> Message-ID: On Wed, 7 May 2025 07:46:45 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add a method handle based field updater src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 173: > 171: if (!underlying.type().parameterType(0).equals(Object.class)) { > 172: underlying = underlying.asType(underlying.type().changeParameterType(0, Object.class)); > 173: } Suggestion: var type = underlying.type(); if (type.returnType() != int.class || type.parameterCount() != 1) { throw new IllegalArgumentException("Illegal underlying function: " + underlying); } if (!type.parameterType(0).equals(Object.class)) { underlying = underlying.asType(type.changeParameterType(0, Object.class)); } underlying.type() is used 4 times, local variables should be used ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077031643 From djelinski at openjdk.org Wed May 7 08:03:18 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 7 May 2025 08:03:18 GMT Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> Message-ID: On Wed, 7 May 2025 07:52:22 GMT, Per Minborg wrote: > This PR proposes to skip a stress test if the `main` thread is a virtual thread. test/jdk/java/foreign/TestBufferStackStress2.java line 69: > 67: // this stress test will not work as the main thread is always alive causing > 68: // us to wait forever for contraction. > 69: // Hence, we will skipp this test if the main thread is virtual. Suggestion: // Hence, we will skip this test if the main thread is virtual. test/jdk/java/foreign/TestBufferStackStress2.java line 70: > 68: // us to wait forever for contraction. > 69: // Hence, we will skipp this test if the main thread is virtual. > 70: if (Thread.currentThread().isVirtual()) { Suggestion: Assumptions.assumeFalse(Thread.currentThread().isVirtual(), "Skipped because the main thread is a virtual thread"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25084#discussion_r2077033646 PR Review Comment: https://git.openjdk.org/jdk/pull/25084#discussion_r2077034970 From alanb at openjdk.org Wed May 7 08:03:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 08:03:19 GMT Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> Message-ID: On Wed, 7 May 2025 07:52:22 GMT, Per Minborg wrote: > This PR proposes to skip a stress test if the `main` thread is a virtual thread. test/jdk/java/foreign/TestBufferStackStress2.java line 73: > 71: System.out.println("Skipped because the main thread is a virtual thread"); > 72: return; > 73: } This is okay. An alternative that we use in a few other tests is to use the Assumptions API t, e.g. assumeFalse(Thread.currentThread().isVirtual(), "message"). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25084#discussion_r2077037194 From jpai at openjdk.org Wed May 7 08:05:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 May 2025 08:05:14 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc Hello Volkan, I checked with others on how to make it prominent, when reading code and when reviewing changes to code, that the usage of these methods needs extra careful attention. In addition to updating the javadoc of these methods, we came to an agreement that each of these methods should be updated to have `unchecked` as the prefix in their method names. For example, renaming `countPositives(...)` to `uncheckedCountPositives(...)`. Even though it means a few additional characters to the method names, this should help catch attention wherever these methods get used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2857500353 From alanb at openjdk.org Wed May 7 08:05:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 08:05:15 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com> On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355: > 353: * UTF-16 representation. > 354: *

    > 355: * WARNING: This method does not perform any bound checks. Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077039719 From mbaesken at openjdk.org Wed May 7 08:17:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 May 2025 08:17:21 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie 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' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - Don't convert properties files to iso-8859-1. > - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70 Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2820807425 From mdoerr at openjdk.org Wed May 7 08:17:22 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 7 May 2025 08:17:22 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie 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' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - Don't convert properties files to iso-8859-1. > - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70 @sxa I guess UTF-8 locales will need to be documented for Adoptium AIX build requirements, too, when this change goes in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2857536070 From pminborg at openjdk.org Wed May 7 08:18:55 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 08:18:55 GMT Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out [v2] In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> Message-ID: <5sqR7qp4X4elVJwtAmtQi72cvDGh9azfT-6rnahuy6s=.b53b3c1b-eee4-493c-83a6-96d78f18cb51@github.com> > This PR proposes to skip a stress test if the `main` thread is a virtual thread. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Update test/jdk/java/foreign/TestBufferStackStress2.java Co-authored-by: Daniel Jelinski - Update test/jdk/java/foreign/TestBufferStackStress2.java Co-authored-by: Daniel Jelinski ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25084/files - new: https://git.openjdk.org/jdk/pull/25084/files/6ee12db8..39bbc360 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25084/head:pull/25084 PR: https://git.openjdk.org/jdk/pull/25084 From pminborg at openjdk.org Wed May 7 08:21:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 08:21:15 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com> Message-ID: On Wed, 7 May 2025 03:05:31 GMT, Shaojin Wen wrote: >> enhanced 'switch' is just syntax sugar and does not affect startup speed > > I looked at the generated bytecode through javap and confirmed that the enhanced switch is just syntactic sugar and no additional classes are generated. Thanks for clarifying this @wenshao ! I will go ahead and make the changes proposed by you here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2077073780 From pminborg at openjdk.org Wed May 7 08:30:28 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 08:30:28 GMT Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out [v3] In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> Message-ID: > This PR proposes to skip a stress test if the `main` thread is a virtual thread. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Cleanup merges ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25084/files - new: https://git.openjdk.org/jdk/pull/25084/files/39bbc360..5aeb01af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25084/head:pull/25084 PR: https://git.openjdk.org/jdk/pull/25084 From mli at openjdk.org Wed May 7 08:36:15 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 7 May 2025 08:36:15 GMT Subject: RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786 In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com> Message-ID: On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation. > But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime. > > This change the behaviour of existing jdk, and it should not throw exception anyway. > > @iwanowww @RealFYang > > Thanks! Thanks, I'll check it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2857667370 From djelinski at openjdk.org Wed May 7 08:37:24 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 7 May 2025 08:37:24 GMT Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out [v3] In-Reply-To: References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> Message-ID: On Wed, 7 May 2025 08:30:28 GMT, Per Minborg wrote: >> This PR proposes to skip a stress test if the `main` thread is a virtual thread. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup merges LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25084#pullrequestreview-2820883237 From pminborg at openjdk.org Wed May 7 08:48:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 08:48:53 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v5] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: - Simplify equals method - Use modern switch - Merge branch 'master' into errno-util3b - Address comments - Fix empty line at the end of a third file - Fix empty line at the end of another file - Fix empty line at the end of a file - Reformat more - Reformat - Use stable values - ... and 38 more: https://git.openjdk.org/jdk/compare/21f01e0c...f9511b88 ------------- Changes: https://git.openjdk.org/jdk/pull/25043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=04 Stats: 818 lines in 9 files changed: 804 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Wed May 7 08:54:43 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 08:54:43 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Simplify ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/f9511b88..e435762b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Wed May 7 08:54:44 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 08:54:44 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v4] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Wed, 7 May 2025 03:19:53 GMT, Shaojin Wen wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 78: > >> 76: inputs.add(new BasicKey(c, layout.name().orElseThrow())); >> 77: } >> 78: } > > Suggestion: > > for (MemoryLayout layout : CAPTURE_LAYOUT.memberLayouts()) { > String name = layout.name().orElseThrow(); > inputs.add(new BasicKey(int.class, name)); > inputs.add(new BasicKey(long.class, name)); > } > > There are only two classes, int.class and long.class, so this might be simpler. I like the existing code better, but I'll guess that is a matter of taste. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2077145341 From asotona at openjdk.org Wed May 7 08:55:15 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 7 May 2025 08:55:15 GMT Subject: RFR: 8355775: Improve symbolic sharing in dynamic constant pool entries In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang wrote: > Some dynamic constant pool entries with heavy symbolic descriptors currently don't share them, yet they are used by stack map generation, and computing a new descriptor every time introduces a heavy cost. > > This cost is obvious if bytecode generation uses constant dynamic - the stack map generator parses the whole dynamic constant symbol to interpret the return type of an ldc condy, such as in FFM downcalls. > > Both the lack of expensive symbol caching in dynamic cp entries and the incorrect query in StackMapGenerator should be fixed. Looks reasonable to me. Is it visible in some benchmark numbers? ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24938#pullrequestreview-2820956106 From alanb at openjdk.org Wed May 7 09:02:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 09:02:14 GMT Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out [v3] In-Reply-To: References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> Message-ID: On Wed, 7 May 2025 08:30:28 GMT, Per Minborg wrote: >> This PR proposes to skip a stress test if the `main` thread is a virtual thread. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup merges Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25084#pullrequestreview-2820982351 From pminborg at openjdk.org Wed May 7 09:15:17 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 09:15:17 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v2] In-Reply-To: <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com> Message-ID: <6mGpPA6jay-y2UOlU6MWj6Od8MoFs6NL9YRcImf4mf0=.eec82983-2964-47ac-b200-1defe79f4d0d@github.com> On Tue, 6 May 2025 15:34:11 GMT, Daniel Fuchs wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix raw long updater under 32-bit mode > > src/java.base/share/classes/java/net/URI.java line 558: > >> 556: >> 557: // Used reflectively by HASH_UPDATER >> 558: @Stable > > What are the effect of this change on startup time? I remember that @cl4es made a number of changes to URI to improve startup. Maybe this change should be dropped out of this PR for now. Yes. I think we should remove these public changes and maybe come back in a separate PR with those. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077189936 From pminborg at openjdk.org Wed May 7 09:15:22 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 09:15:22 GMT Subject: Integrated: 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com> Message-ID: On Wed, 7 May 2025 07:52:22 GMT, Per Minborg wrote: > This PR proposes to skip a stress test if the `main` thread is a virtual thread. This pull request has now been integrated. Changeset: 1bdff3cc Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/1bdff3ccd069142e21c8b0a9ecf759b82302a2d2 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out Reviewed-by: djelinski, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25084 From pminborg at openjdk.org Wed May 7 09:23:45 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 09:23:45 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v4] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Reformat - Revert changes in public classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/83ce9ac1..4a42b271 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=02-03 Stats: 62 lines in 2 files changed: 17 ins; 37 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From aph at openjdk.org Wed May 7 09:28:19 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 7 May 2025 09:28:19 GMT Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3] In-Reply-To: References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com> Message-ID: On Tue, 6 May 2025 21:45:34 GMT, Mohamed Issa wrote: >> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. >> >> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version. >> >> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs. >> >> | Input range(s) | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup | >> | :-------------------------------------: | :----------------------------------: | :----------------------------------: | :---------: | >> | [-2^(-1022), 2^(-1022)] | 6568 | 17678 | 2.69x | >> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932 | 200897 | 1.45x | >> >> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Add new set of cbrt micro-benchmarks src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 62: > 60: { > 61: 0, 3220193280 > 62: }; What is this constant? Its value is 0xbff0400000000000, which is -ve bit set, bias (top bit of exponent) clear, but one of the bits in the fraction is set. So its value is -0x1.04p+0. As well as the exponent it also sets the 1 bit, just below the 5 most significant bits of the fraction. I guess this in effect rounds up the value that is added in the final rounding. Is that right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2077214995 From duke at openjdk.org Wed May 7 09:29:23 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 7 May 2025 09:29:23 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Tue, 6 May 2025 21:54:59 GMT, Jesper Wilhelmsson wrote: > We must remember that the OpenJDK community is built by individuals with different backgrounds and motivations to engaging. Some people get paid to work on OpenJDK development, others do it in their own time. It would be next to impossible to dictate any kinds of rules to enforce engagement from reviewers as this would require companies and individuals to commit to prioritizing issues that may not be in their interest to spend time on. > > Any kind of "if you engage in a discussion you must reply within X weeks" will most likely only result in less people engaging in the first place. I *am* on of those unpaid fellows, actually. Sure, we are not the project police, and it is not about *controlling* people, but what I meant is that if we enforce "broad agreement" *piror* to a PR, then we MUST tell those people that they SHOULD react *prior* to the PR. Actually, currently many of them do not respond at all, even if they like to have a feature, as they think "I will chime in once the PR is there" (this is my recognized experience with my last PRs). So when you hold me back from PRs, the other side of the medal is that you tell all those people that they cannot wait for the PR anymore, but they MUST send at least "+1" or "proceed with PR" in the mailing list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2857838032 From alanb at openjdk.org Wed May 7 09:31:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 09:31:24 GMT Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:14:58 GMT, Shaojin Wen wrote: >> Alan Bateman 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 branch 'master' into JDK-8342486 >> - Merge branch 'master' into JDK-8342486 >> - Merge branch 'master' into JDK-8342486 >> - Sync up from loom repo >> - Merge branch 'master' into JDK-8342486 >> - Add JEP number, update copyright headers >> - Merge branch 'master' into JDK-8342486 >> - Sync up from loom repo >> - Merge branch 'master' into JDK-8342486 >> - Sync up from loom repo >> - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f > > src/java.base/share/classes/java/util/concurrent/Joiners.java line 84: > >> 82: @SuppressWarnings("unchecked") >> 83: var s = (Subtask) subtask; >> 84: subtasks.add(s); > > Suggestion: > > subtasks.add((Subtask) subtask); > > The local variable s is only used once and can be simplified No, it has to be a local to avoid broadening the use of SW. > src/java.base/share/classes/java/util/concurrent/Joiners.java line 155: > >> 153: case FAILED -> throw subtask.exception(); >> 154: default -> throw new InternalError(); >> 155: }; > > Suggestion: > > return switch (subtask.state()) { > case SUCCESS -> subtask.get(); > case FAILED -> throw subtask.exception(); > default -> throw new InternalError(); > }; > > The switch of the stateToInt method is aligned, so it should also be aligned here to keep the style consistent I'll look to re-align these in the loom repo for the next refresh. > src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 820: > >> 818: @PreviewFeature(feature = PreviewFeature.Feature.STRUCTURED_CONCURRENCY) >> 819: final class TimeoutException extends RuntimeException { >> 820: @java.io.Serial > > Use import without full path I think `@java.io.Serial` is okay here, you'll see the same in many other areas. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2077217919 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2077215677 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2077222469 From jpai at openjdk.org Wed May 7 10:08:24 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 May 2025 10:08:24 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG 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 latest from master branch > - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? > - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs > - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. > - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' > - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() > - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() > - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' > - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? > - Applied changes requested by Alan: Copies chars from this sequence into the given destination array > - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a tier1 through tier3 testing of this PR passed without issues. The CSR has been approved and the changes in this PR look good to me. Thank you for being patient and contributing this enhancement. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2821184175 From duke at openjdk.org Wed May 7 10:27:16 2025 From: duke at openjdk.org (erifan) Date: Wed, 7 May 2025 10:27:16 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 06:59:34 GMT, Jatin Bhateja wrote: >> erifan 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: >> >> - Refactor code >> >> Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this >> optimization, making the code more modular. >> - Merge branch 'master' into JDK-8354242 >> - Update the jtreg test >> - Merge branch 'master' into JDK-8354242 >> - Addressed some review comments >> >> 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. >> 2. Improve code comments. >> - Merge branch 'master' into JDK-8354242 >> - Merge branch 'master' into JDK-8354242 >> - 8354242: VectorAPI: combine vector not operation with compare >> >> This patch optimizes the following patterns: >> For integer types: >> ``` >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> ``` >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the >> negative comparison of cond. >> >> For float and double types: >> ``` >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> ``` >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: >> With option `-XX:UseSVE=2`: >> ``` >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.156... > > src/hotspot/share/opto/vectornode.cpp line 2231: > >> 2229: } >> 2230: if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 || >> 2231: !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() || > > Do you plan to extend your testcase / matching logic to cover following equivalent patterns: > > - compare.xor(maskAll(true)) > - compare.xor(VectorMask.fromLong(SPECIES, -1L)) Hi @jatin-bhateja It is feasible. But I was thinking about whether another solution would be better, which is to turn `VectorMask.fromLong(SPECIES, -1L)` into `MaskAll(true)` in the mid-end. In this way, we don't need to check this pattern in this optimization. What do you think ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077316033 From duke at openjdk.org Wed May 7 10:46:14 2025 From: duke at openjdk.org (kabutz) Date: Wed, 7 May 2025 10:46:14 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com> References: <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com> <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com> Message-ID: On Mon, 28 Apr 2025 19:48:40 GMT, Viktor Klang wrote: >> @viktorklang-ora @DougLea @AlanBateman > > @kabutz Thanks for opening this PR?just confirming that it's on my to-review queue. @viktorklang-ora any idea whom else we can ask to approve this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2858077986 From duke at openjdk.org Wed May 7 10:56:19 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 7 May 2025 10:56:19 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 10:05:12 GMT, Jaikiran Pai wrote: > tier1 through tier3 testing of this PR passed without issues. The CSR has been approved and the changes in this PR look good to me. Thank you, Jaikiran! Will this result convince everybody to actively mark this PR as officially reviewed, so I can finally integrate it? ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2858104713 From pminborg at openjdk.org Wed May 7 11:04:14 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 11:04:14 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v4] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com> Message-ID: On Tue, 6 May 2025 12:23:44 GMT, Chen Liang wrote: >> This would require another implementation to be written. Maybe we can add that later? > > I feel like declaring a function is declaring redundant classes when we can just reuse a DirectMethodHandle pointing to an actual method. Also the zero alternative should be handled by the provided computing function/method instead of handled by this utility. There is an MH variant now. The use of the zero alternative is optional, as if you put in `0`, it will have no effect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077372099 From jbhateja at openjdk.org Wed May 7 11:06:21 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 7 May 2025 11:06:21 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 10:24:14 GMT, erifan wrote: >> src/hotspot/share/opto/vectornode.cpp line 2231: >> >>> 2229: } >>> 2230: if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 || >>> 2231: !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() || >> >> Do you plan to extend your testcase / matching logic to cover following equivalent patterns: >> >> - compare.xor(maskAll(true)) >> - compare.xor(VectorMask.fromLong(SPECIES, -1L)) > > Hi @jatin-bhateja It is feasible. But I was thinking about whether another solution would be better, which is to turn `VectorMask.fromLong(SPECIES, -1L)` into `MaskAll(true)` in the mid-end. In this way, we don't need to check this pattern in this optimization. What do you think ? Yes, that's the right approach. For this PR, I think you can mix some test points covering compare, xor(maskAll(true)). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077373581 From duke at openjdk.org Wed May 7 11:08:18 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 7 May 2025 11:08:18 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 10:53:09 GMT, Markus KARG wrote: > Thank you, Jaikiran! Will this result convince everybody to actively mark this PR as officially reviewed, so I can finally integrate it? ? @liach For example, you could approve your outdated approval so this PR finally has to *current* reviews. Thanks. >[Chen Liang](https://openjdk.org/census#liach) (@liach - Reviewer) ? **Re-review required** (review applies to [884e7dc1](https://git.openjdk.org/jdk/pull/21730/files/884e7dc14c25b47ff6e5056fb663cfccf17f243e)) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2858138560 From jbhateja at openjdk.org Wed May 7 11:09:16 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 7 May 2025 11:09:16 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v2] In-Reply-To: <7IGU54ppPKoebXOt0BaS9r-eYf92mtILbHLu8RsfmSk=.a0b3259c-e5ea-43a2-b34c-38d439bd0a41@github.com> References: <7IGU54ppPKoebXOt0BaS9r-eYf92mtILbHLu8RsfmSk=.a0b3259c-e5ea-43a2-b34c-38d439bd0a41@github.com> Message-ID: On Fri, 25 Apr 2025 09:17:02 GMT, Jatin Bhateja wrote: >> Thanks for telling me this information. Another more important reason to check outcnt here is to prevent this optimization when the uses of VectorMaskCmp is greater than 1, because this optimization may not be worthwhile. For example: >> >> >> public static void testVectorMaskCmp() { >> IntVector bv = IntVector.fromArray(I_SPECIES, ib, 0); >> IntVector av = IntVector.fromArray(I_SPECIES, ia, 0); >> VectorMask m1 = av.compare(VectorOperators.NE, bv); // two uses >> VectorMask m2 =m1.not(); >> m1.intoArray(m, 0); >> av.lanewise(VectorOperators.ABS, m2).intoArray(ia, 0); >> } >> >> >> If we do not check outcnt and still do this optimization, two VectorMaskCmp nodes will be generated, and finally two VectorMaskCmp instructions will be generated. This is unreasonable because VectorMaskCmp has much higher latency than xor instruction on aarch64. > > Thanks, we can add this comment to the code where we are checking outcnt. What if all the other users are also XorNodes?. At present, you are checking for one XOR user; shouldn't it be all or one scenario? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077378879 From vyazici at openjdk.org Wed May 7 11:20:26 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 11:20:26 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:37:48 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302: > >> 300: * WARNING: This method does not perform any bound checks. >> 301: */ >> 302: int countPositives(byte[] ba, int off, int len); > > Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed. Submitted [8356380](https://bugs.openjdk.org/browse/JDK-8356380) to address this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077399743 From jbhateja at openjdk.org Wed May 7 11:24:17 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 7 May 2025 11:24:17 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 02:10:56 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan 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: > > - Refactor code > > Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this > optimization, making the code more modular. > - Merge branch 'master' into JDK-8354242 > - Update the jtreg test > - Merge branch 'master' into JDK-8354242 > - Addressed some review comments > > 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. > 2. Improve code comments. > - Merge branch 'master' into JDK-8354242 > - Merge branch 'master' into JDK-8354242 > - 8354242: VectorAPI: combine vector not operation with compare > > This patch optimizes the following patterns: > For integer types: > ``` > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > ``` > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the > negative comparison of cond. > > For float and double types: > ``` > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > ``` > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: > With option `-XX:UseSVE=2`: > ``` > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4... test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 40: > 38: @Fork(jvmArgs = { "--add-modules=jdk.incubator.vector" }) > 39: public class MaskCompareNotBenchmark { > 40: private static final int ARRAYLEN = 4096; ARRAYLEN should be configurable @Param. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077390413 From vklang at openjdk.org Wed May 7 11:52:21 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 7 May 2025 11:52:21 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com> <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com> Message-ID: On Wed, 7 May 2025 10:43:55 GMT, kabutz wrote: >> @kabutz Thanks for opening this PR?just confirming that it's on my to-review queue. > > @viktorklang-ora any idea whom else we can ask to approve this PR? @kabutz I think @AlanBateman might be able to have a look as well. As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in *after* JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2858284560 From rgiulietti at openjdk.org Wed May 7 11:57:20 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 11:57:20 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Simplify long power computing test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72: > 70: > 71: new Runner(opt).run(); > 72: } There's no need for these lines. test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 117: > 115: @OperationsPerInvocation(TESTSIZE) > 116: public void testPowXS(Blackhole bh) { > 117: for (BigInteger s : xsArray) { Suggestion: for (BigInteger xs : xsArray) { and similarly for the other arrays. test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 118: > 116: public void testPowXS(Blackhole bh) { > 117: for (BigInteger s : xsArray) { > 118: bh.consume(s.pow(xsExp)); Suggestion: bh.consume(s.pow(xsExp & ~0b0111_0101)); bh.consume(s.pow(xsExp)); bh.consume(s.pow(xsExp + 1)); or something similar, just to measure other than "all-ones" exponents as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077443258 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077449324 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077452722 From abimpoudis at openjdk.org Wed May 7 12:02:26 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 7 May 2025 12:02:26 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler Message-ID: While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. For example this is not valid Java (and protected) by javac: byte b = 1; switch (b) { case String s -> System.out.println("How did we get here? byte is " + s.getClass()); } but this is a valid call (and not protected): CallSite shortSwitch = SwitchBootstraps.typeSwitch( MethodHandles.lookup(), "", MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int String.class); The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. ------------- Commit messages: - 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler Changes: https://git.openjdk.org/jdk/pull/25090/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354323 Stats: 33 lines in 2 files changed: 27 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25090.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25090/head:pull/25090 PR: https://git.openjdk.org/jdk/pull/25090 From duke at openjdk.org Wed May 7 12:11:19 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 7 May 2025 12:11:19 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v4] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Wed, 7 May 2025 09:23:45 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Reformat > - Revert changes in public classes Starting to look nicely idiomatic. If I saw this I would however want to add a thin wrapper specific for hash codes where the "zero replacement" and generic types are more hidden. * HashCoder.forIntField(Foo.class, "hash", ...) * HashCoder.forLongField(...) I like that there's an annotation on the field now though! test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 83: > 81: > 82: > 83: static // Intentionally in unblessed order to allow the example to look nice Huh, not seen this before ... interesting. test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 117: > 115: private static final ToIntFunction HASH_UPDATER = > 116: StableFieldUpdater.ofInt(LazyFoo.class, "hash", > 117: l -> Objects.hash(l.bar, l.baz), -1); As someone unfamiliar with this, I'm given to ask "What's the -1 for?" I *think* I can intuit that it's a value to be used *if* the hashcode actually ends up calculating zero (so any random bit pattern would (should?) be equally useful? In example code if feels like this is not quite explaining itself enough to teach someone about its usage. For example (if it's what I think) it can't actually be passed as zero. test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 149: > 147: private static final ToLongFunction HASH_UPDATER = > 148: StableFieldUpdater.ofLong(LazySpecifiedFoo.class, "hash", > 149: l -> (l.bar == null && l.baz == null) ? 0 : Objects.hash(l.bar, l.baz), 1L << 32); Maybe for an example, use a (private?) static method reference here `calculateHash`. It helps visually distinguish plumbing and business logic IMO. ------------- PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2821463165 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077457809 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077457604 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077460209 From rgiulietti at openjdk.org Wed May 7 12:14:24 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 12:14:24 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Simplify long power computing src/java.base/share/classes/java/math/BigInteger.java line 2622: > 2620: > 2621: // Factor the powers of two out quickly by shifting right, if needed. > 2622: if (powersOfTwo > 0) { `shiftRight()` returns `this` when the shift distance is 0, so there's no compelling need to have two branches for `powersOfTwo` src/java.base/share/classes/java/math/BigInteger.java line 2626: > 2624: remainingBits = base.bitLength(); > 2625: if (remainingBits == 1) { // Nothing left but +/- 1? > 2626: if (signum < 0 && (exponent&1) == 1) { This `boolean` expression occurs many times. It could be factored out in a local var. src/java.base/share/classes/java/math/BigInteger.java line 2656: > 2654: > 2655: // Multiply back the powers of two (quickly, by shifting left) > 2656: return powersOfTwo == 0 I don't think there's a compelling need to "optimize" for `powersOfTwo == 0`. src/java.base/share/classes/java/math/BigInteger.java line 2662: > 2660: : new BigInteger(result, newSign).shiftLeft(bitsToShift)); > 2661: } else { > 2662: if ((((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH) { Suggestion: if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) { src/java.base/share/classes/java/math/BigInteger.java line 2718: > 2716: x *= x; > 2717: } > 2718: return pow; This uselessly computes a square in the last iteration. See the [suggested variant](https://github.com/openjdk/jdk/pull/24690#discussion_r2068549452) for inspiration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077472392 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077465904 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077482776 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077473938 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077478542 From liach at openjdk.org Wed May 7 12:57:17 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 12:57:17 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v4] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Wed, 7 May 2025 09:23:45 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Reformat > - Revert changes in public classes The MH+VH form should be much more lightweight: MH and VH are just MemberName references. I wonder if we can advertise the MH+VH version as an indy BSM: public static CallSite lazyAccessor(Lookup lookup, String unused, MethodType callType, VarHandle field, MethodHandle computer) The CallSite would be constant, with `StableIntFieldUpdaterVarHandle.applyAsInt` bound to the specific updater. This way, we can even defer the creation of the updater. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2858487803 From liach at openjdk.org Wed May 7 12:59:14 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 12:59:14 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sun, 4 May 2025 16:21:41 GMT, Markus KARG wrote: >> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. >> >> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Undone copyright update of otherwise unchanged file. > - Update Of.java > > Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise." I guess a better approach may be to allow periodical reminders if a thread gets no reply - many of us gets quite a few hundred mails every day on workdays. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2858492193 From liach at openjdk.org Wed May 7 13:00:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 13:00:18 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:45:14 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify long power computing > > test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72: > >> 70: >> 71: new Runner(opt).run(); >> 72: } > > There's no need for these lines. These are here for convenience when a benchmark is run standalone. I think this has no harm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077570983 From rgiulietti at openjdk.org Wed May 7 13:10:21 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 13:10:21 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 12:57:13 GMT, Chen Liang wrote: >> test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72: >> >>> 70: >>> 71: new Runner(opt).run(); >>> 72: } >> >> There's no need for these lines. > > These are here for convenience when a benchmark is run standalone. I think this has no harm. There's no harm, but no need either. We can add a comment like so, to clarify that the benchmark is here to measure memory allocations, rather than running time. You can run this test via the command line: $ make test TEST="micro:java.math.BigIntegerPow" MICRO="OPTIONS=-prof gc" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077590224 From rgiulietti at openjdk.org Wed May 7 13:25:18 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 13:25:18 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com> References: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com> Message-ID: On Wed, 7 May 2025 08:02:28 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355: > >> 353: * UTF-16 representation. >> 354: *

    >> 355: * WARNING: This method does not perform any bound checks. > > Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked". As mentioned by Alan and Jaikiran, at some point it is advisable to prefix the names with "unchecked". For the "noRepl" names, perhaps the mouthful but clearer "noReplacementChar" might help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077617931 From pminborg at openjdk.org Wed May 7 13:55:08 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 13:55:08 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v5] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. 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: - Add low level variants - Merge branch 'master' into stable-updaters - Reformat - Revert changes in public classes - Add a method handle based field updater - Fix raw long updater under 32-bit mode - Address comments - Document field alignment assumption - Add unhecked call test - Move raw factories into inner class Raw - ... and 5 more: https://git.openjdk.org/jdk/compare/de41c1f3...6342fbd8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/4a42b271..6342fbd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=03-04 Stats: 14466 lines in 388 files changed: 9105 ins; 3251 del; 2110 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From pminborg at openjdk.org Wed May 7 13:55:10 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 13:55:10 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v4] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: <6V0vEbAOnYqONTavs8-eEVlInQI5pTcYDAo1tRYduNA=.0ff84e6a-73e6-40c3-b616-0c0753d330a3@github.com> On Wed, 7 May 2025 11:54:09 GMT, David Beaumont wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Reformat >> - Revert changes in public classes > > test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 117: > >> 115: private static final ToIntFunction HASH_UPDATER = >> 116: StableFieldUpdater.ofInt(LazyFoo.class, "hash", >> 117: l -> Objects.hash(l.bar, l.baz), -1); > > As someone unfamiliar with this, I'm given to ask "What's the -1 for?" > > I *think* I can intuit that it's a value to be used *if* the hashcode actually ends up calculating zero (so any random bit pattern would (should?) be equally useful? > > In example code if feels like this is not quite explaining itself enough to teach someone about its usage. For example (if it's what I think) it can't actually be passed as zero. I've added some verbiage around this now. Let me know if it can be improved further. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077688537 From liach at openjdk.org Wed May 7 14:08:20 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 14:08:20 GMT Subject: RFR: 8341184: Clean up the interaction between the launcher native code and the LauncherHelper [v16] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:34:32 GMT, Shaojin Wen wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - ... and 6 more: https://git.openjdk.org/jdk/compare/e410af00...d1ac5174 > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 946: > >> 944: JAVAFX_APPLICATION_CLASS_NAME); >> 945: } >> 946: } > > Suggestion: > > if (!PreviewFeatures.isEnabled()) { > int mods = mainMethod.getModifiers(); > if (!Modifier.isStatic(mods) || !Modifier.isPublic(mods) || mainMethod.getParameterCount() == 0) { > abort(null, "java.launcher.cls.error2", builder.mainClass.getName(), > JAVAFX_APPLICATION_CLASS_NAME); > } > } > > Remove variables that are only used once This can now be removed. Compact source files and instance main methods have been integrated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21256#discussion_r2077717832 From liach at openjdk.org Wed May 7 14:11:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 14:11:18 GMT Subject: RFR: 8355775: Improve symbolic sharing in dynamic constant pool entries In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang wrote: > Some dynamic constant pool entries with heavy symbolic descriptors currently don't share them, yet they are used by stack map generation, and computing a new descriptor every time introduces a heavy cost. > > This cost is obvious if bytecode generation uses constant dynamic - the stack map generator parses the whole dynamic constant symbol to interpret the return type of an ldc condy, such as in FFM downcalls. > > Both the lack of expensive symbol caching in dynamic cp entries and the incorrect query in StackMapGenerator should be fixed. Yeah, this is visible if a condy is used due to that updated site in StackMapGenerator - it required a symbolic expansion. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24938#issuecomment-2858740354 From liach at openjdk.org Wed May 7 14:11:19 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 14:11:19 GMT Subject: Integrated: 8355775: Improve symbolic sharing in dynamic constant pool entries In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang wrote: > Some dynamic constant pool entries with heavy symbolic descriptors currently don't share them, yet they are used by stack map generation, and computing a new descriptor every time introduces a heavy cost. > > This cost is obvious if bytecode generation uses constant dynamic - the stack map generator parses the whole dynamic constant symbol to interpret the return type of an ldc condy, such as in FFM downcalls. > > Both the lack of expensive symbol caching in dynamic cp entries and the incorrect query in StackMapGenerator should be fixed. This pull request has now been integrated. Changeset: d7e648bb Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/d7e648bb2737362d3cba3350cae63b1013967a66 Stats: 103 lines in 6 files changed: 56 ins; 34 del; 13 mod 8355775: Improve symbolic sharing in dynamic constant pool entries Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/24938 From duke at openjdk.org Wed May 7 14:54:09 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 14:54:09 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v50] In-Reply-To: References: Message-ID: > This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24690/files - new: https://git.openjdk.org/jdk/pull/24690/files/b8ca4fe4..4103e491 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=49 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=48-49 Stats: 110 lines in 2 files changed: 49 ins; 36 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/24690.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690 PR: https://git.openjdk.org/jdk/pull/24690 From pminborg at openjdk.org Wed May 7 14:58:33 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 14:58:33 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v6] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com> > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add convenience methods and documentations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/6342fbd8..a01ba9ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=04-05 Stats: 107 lines in 2 files changed: 106 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From duke at openjdk.org Wed May 7 15:03:36 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 15:03:36 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: > This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Removed needless brackets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24690/files - new: https://git.openjdk.org/jdk/pull/24690/files/4103e491..5ebc16b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=50 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=49-50 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24690.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690 PR: https://git.openjdk.org/jdk/pull/24690 From pminborg at openjdk.org Wed May 7 15:03:57 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 May 2025 15:03:57 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v7] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Reformat ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/a01ba9ab..de8e2387 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=05-06 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From duke at openjdk.org Wed May 7 15:10:16 2025 From: duke at openjdk.org (ExE Boss) Date: Wed, 7 May 2025 15:10:16 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v7] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: <89tWdW-Z_osB8oN36zrb_w_BPPDjCd6mJ_pEpDjCfXQ=.9ce14d67-3867-4c37-9d72-4fe690c2e0bc@github.com> On Wed, 7 May 2025 15:03:57 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Reformat `StableFieldUpdater?.checkAndAdapt(?)` also?performs an?implicit null?check: ------------- PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2822161491 From duke at openjdk.org Wed May 7 15:10:19 2025 From: duke at openjdk.org (ExE Boss) Date: Wed, 7 May 2025 15:10:19 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v6] In-Reply-To: <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com> Message-ID: On Wed, 7 May 2025 14:58:33 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add convenience methods and documentations src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 257: > 255: check(accessor, int.class); > 256: Objects.requireNonNull(underlying); > 257: var adaptedUnderlying = checkAndAdapt(underlying, int.class); Suggestion: // Implicit null checks: check(accessor, int.class); var adaptedUnderlying = checkAndAdapt(underlying, int.class); src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 311: > 309: check(accessor, long.class); > 310: Objects.requireNonNull(underlying); > 311: var adaptedUnderlying = checkAndAdapt(underlying, long.class); Suggestion: // Implicit null checks: check(accessor, long.class); var adaptedUnderlying = checkAndAdapt(underlying, long.class); src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 588: > 586: > 587: private static MethodHandle checkAndAdapt(MethodHandle underlying, Class returnType) { > 588: final var underlyingType = underlying.type(); Suggestion: // Implicit null check final var underlyingType = underlying.type(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077860284 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077860770 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077861275 From bpb at openjdk.org Wed May 7 15:32:16 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 May 2025 15:32:16 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: <5sF6nQjDykFcP5-etCpaYidBIGkJvNUzjC6PYRGfuGA=.71fc9b7e-40c8-4ee1-8a67-9b9181cda6ae@github.com> References: <5sF6nQjDykFcP5-etCpaYidBIGkJvNUzjC6PYRGfuGA=.71fc9b7e-40c8-4ee1-8a67-9b9181cda6ae@github.com> Message-ID: On Wed, 7 May 2025 06:06:08 GMT, Alan Bateman wrote: > I assume the CSR will be expanded, e.g. to list deleteOnExit Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2859058406 From rgiulietti at openjdk.org Wed May 7 15:45:21 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 15:45:21 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Removed needless brackets src/java.base/share/classes/java/math/BigInteger.java line 2607: > 2605: > 2606: BigInteger base = this.abs(); > 2607: final boolean negative = signum < 0 && (exponent & 1) == 1; Some effectively final locals are declared `final`, while others are not. src/java.base/share/classes/java/math/BigInteger.java line 2643: > 2641: : new BigInteger(result, newSign).shiftLeft(bitsToShift); > 2642: } else { > 2643: if ((bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5) { Suggestion: if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) { or Suggestion: if ((bitLength() - 1L) * exponent >= (long) Integer.SIZE * MAX_MAG_LENGTH) { Both variant are easier to read, more honest, and exactly as efficient as with the shift. The right-hand sides are compile-time constants, so they have no impact on runtime performance. More generally, the runtime compilers are perfectly capable to optimize multiplications by constant powers of 2 and replace them with shifts, even if the other operand is not a constant. test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 74: > 72: * Each array entry is atmost 64 bits > 73: * in size > 74: */ These should probably be part of the declarations: private int xsExp = (1 << 20) - 1; private BigInteger[] xsArray = new BigInteger[TESTSIZE]; // Each array entry is atmost 64 bits in size Similarly for the other fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077924006 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077942835 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077949298 From duke at openjdk.org Wed May 7 15:48:40 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 15:48:40 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v52] In-Reply-To: References: Message-ID: > This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Code simplification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24690/files - new: https://git.openjdk.org/jdk/pull/24690/files/5ebc16b7..e0816d55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=50-51 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24690.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690 PR: https://git.openjdk.org/jdk/pull/24690 From rgiulietti at openjdk.org Wed May 7 15:48:40 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 15:48:40 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Removed needless brackets The large number algorithm loop in `pow()` might deserve an invariant in a comment. Did you make sure that the existing tests also cover the `unsignedLongPow()` sufficiently well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2859115099 From rgiulietti at openjdk.org Wed May 7 15:51:19 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 15:51:19 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Removed needless brackets JMH benchmarks look good for the random exponents as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2859124431 From rgiulietti at openjdk.org Wed May 7 15:59:19 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 15:59:19 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:28:59 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed needless brackets > > src/java.base/share/classes/java/math/BigInteger.java line 2607: > >> 2605: >> 2606: BigInteger base = this.abs(); >> 2607: final boolean negative = signum < 0 && (exponent & 1) == 1; > > Some effectively final locals are declared `final`, while others are not. Personally, I don't have a strong preference, but I prefer consistency. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077981057 From duke at openjdk.org Wed May 7 16:03:18 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 16:03:18 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:46:16 GMT, Raffaello Giulietti wrote: > Did you make sure that the existing tests also cover the `unsignedLongPow()` sufficiently well? @rgiulietti There are already the tests for `BigInteger`'s [pow](https://github.com/fabioromano1/jdk/blob/BigInteger-nth-root/test/jdk/java/math/BigInteger/BigIntegerTest.java#L219), since the code of `unsignedLongPow()` is basically equivalent to that one in the current implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2859155908 From rriggs at openjdk.org Wed May 7 16:04:27 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 7 May 2025 16:04:27 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG 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 latest from master branch > - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? > - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs > - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. > - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' > - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() > - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() > - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' > - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? > - Applied changes requested by Alan: Copies chars from this sequence into the given destination array > - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a Thanks for the persistence. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2822378207 From joehw at openjdk.org Wed May 7 16:22:33 2025 From: joehw at openjdk.org (Joe Wang) Date: Wed, 7 May 2025 16:22:33 GMT Subject: RFR: 8353232: Standardizing and Unifying XML Component Configurations Message-ID: This is a refactor patch, no change in functionality. This patch refactor the configuration code. Rather than for each factory to go through the whole configuration process, a base configuration as represented in JdkXmlConfig is created once, which includes loading of the JAXP Configuration file, factories then get their own copies of the property managers, created on top of the base ones rather than directly constructed. The JDKCatalogResolver is lazily constructed as needed instead of created along with the security manager. The rest of changes basically replace all direct constructions of XMLSecurityManager/XMLSecurityPropertyManager with calls to JdkXmlConfig's corresponding get methods, which return clones of the base instances. in the factory classes, these clones are updated with property settings on the factories. In non-public or legacy code paths (inherited from upstream components), such updates may not be necessary. Tests: existing tests T1-3 passed; XML JCK tests passed. ------------- Commit messages: - 8353232: Standardizing and Unifying XML Component Configurations Changes: https://git.openjdk.org/jdk/pull/25102/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25102&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353232 Stats: 582 lines in 31 files changed: 318 ins; 119 del; 145 mod Patch: https://git.openjdk.org/jdk/pull/25102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25102/head:pull/25102 PR: https://git.openjdk.org/jdk/pull/25102 From liach at openjdk.org Wed May 7 16:39:21 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 16:39:21 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: References: Message-ID: <5mcBz7IvDNxwrQJh9EjP-gKejbWG92idqojhc0MXjI8=.68a4d03a-5af9-430a-96de-20c8775d1dce@github.com> On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis wrote: > While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. > > For example this is not valid Java (and protected) by javac: > > > byte b = 1; > switch (b) { > case String s -> System.out.println("How did we get here? byte is " + s.getClass()); > } > > > but this is a valid call (and not protected): > > > CallSite shortSwitch = SwitchBootstraps.typeSwitch( > MethodHandles.lookup(), > "", > MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int > String.class); > > > The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. > > This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 553: > 551: continue; > 552: } > 553: else if (unconditionalExactnessCheck(selectorType, classLabel)) { Can we merge this into `isNotValidPair(...) || unconditionalExactnessCheck(...)` then do nothing? The next label is already in theory immediately bound to the instruction after goto. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2078046340 From liach at openjdk.org Wed May 7 16:42:30 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 16:42:30 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG 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 latest from master branch > - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? > - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs > - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. > - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' > - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() > - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() > - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' > - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? > - Applied changes requested by Alan: Copies chars from this sequence into the given destination array > - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a The latest iteration looks the same as the one I last reviewed. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2822479972 From duke at openjdk.org Wed May 7 16:42:31 2025 From: duke at openjdk.org (duke) Date: Wed, 7 May 2025 16:42:31 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG 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 latest from master branch > - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? > - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs > - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. > - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' > - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() > - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() > - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' > - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? > - Applied changes requested by Alan: Copies chars from this sequence into the given destination array > - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a @mkarg Your change (at version 31537b7a4fa0a6b0ba235f6db4d901a9a134a6fa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2859256566 From duke at openjdk.org Wed May 7 16:55:17 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 7 May 2025 16:55:17 GMT Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2] In-Reply-To: References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Wed, 7 May 2025 12:56:20 GMT, Chen Liang wrote: > I guess a better approach may be to allow periodical reminders if a thread gets no reply - many of us gets quite a few hundred mails every day on workdays. I think it is time to move this discussion into its own thread, but just a last word from my side: Same with me. We need to find a way how external contributors can make progress even if the core team at Oracle has no time -- because you *mostly* have no time. ? Otherwise lots of contributions will simply not happen, as they linger around for years and then nobody likes to get back to it. ? One thing I hope you don't mind if I say is: Being a committer / reviewer is not just a power, it is also a responsibility to stay in contact with "normal" contributors in a timely manner. For that reason, in the open source projects where *I* am the code owner, I reserve time for working with contributors, and I always help others before working on my own stuff. Just as an idea. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2859305952 From asmehra at openjdk.org Wed May 7 16:58:15 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 16:58:15 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v4] In-Reply-To: References: Message-ID: <5EjPGeqBe78hoAgNgx8-1_BeO8cAyoP0H2t_e-41LnU=.2cfa426f-8240-43ab-9c9a-7352f2614243@github.com> On Wed, 7 May 2025 05:11:01 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java thanks for addressing the comments. lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2822524147 From duke at openjdk.org Wed May 7 17:04:16 2025 From: duke at openjdk.org (kabutz) Date: Wed, 7 May 2025 17:04:16 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com> <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com> Message-ID: On Wed, 7 May 2025 10:43:55 GMT, kabutz wrote: >> @kabutz Thanks for opening this PR?just confirming that it's on my to-review queue. > > @viktorklang-ora any idea whom else we can ask to approve this PR? > @kabutz I think @AlanBateman might be able to have a look as well. > > As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in _after_ JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense. That sound reasonable. When would this be? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2859366474 From naoto at openjdk.org Wed May 7 17:07:23 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 7 May 2025 17:07:23 GMT Subject: RFR: 8356221: Clarify Console.charset() method description Message-ID: Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/25103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25103&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356221 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25103/head:pull/25103 PR: https://git.openjdk.org/jdk/pull/25103 From bpb at openjdk.org Wed May 7 17:11:13 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 May 2025 17:11:13 GMT Subject: RFR: 8356221: Clarify Console.charset() method description In-Reply-To: References: Message-ID: On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote: > Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied. Looks all right to me. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25103#pullrequestreview-2822560049 From duke at openjdk.org Wed May 7 17:17:17 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 17:17:17 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:38:41 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed needless brackets > > src/java.base/share/classes/java/math/BigInteger.java line 2643: > >> 2641: : new BigInteger(result, newSign).shiftLeft(bitsToShift); >> 2642: } else { >> 2643: if ((bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5) { > > Suggestion: > > if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) { > > or > Suggestion: > > if ((bitLength() - 1L) * exponent >= (long) Integer.SIZE * MAX_MAG_LENGTH) { > > > Both variant are easier to read, more honest, and exactly as efficient as with the shift. The right-hand sides are compile-time constants, so they have no impact on runtime performance. > > More generally, the runtime compilers are perfectly capable to optimize multiplications by constant powers of 2 and replace them with shifts, even if the other operand is not a constant. @rgiulietti What about `(bitLength() - 1L) * exponent >= Integer.MAX_VALUE`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078107104 From duke at openjdk.org Wed May 7 17:20:33 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 7 May 2025 17:20:33 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks Message-ID: Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. ------------- Commit messages: - 8348828: Windows dll loading now resolves symlinks Changes: https://git.openjdk.org/jdk/pull/24694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348828 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From duke at openjdk.org Wed May 7 17:20:33 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 7 May 2025 17:20:33 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. by corporate OCA under "EngFlow Inc." @AlanBateman @bplb Hello! Any chance either of you could be induced to sponsor and review this? Also, any idea how to accelerate the OCA verification process? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2810188272 PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2835812629 From alanb at openjdk.org Wed May 7 17:20:33 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 17:20:33 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. This issue has the "oca" label so we cannot engage, sorry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2835855589 From duke at openjdk.org Wed May 7 17:20:33 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 7 May 2025 17:20:33 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 16:42:35 GMT, Alan Bateman wrote: > This issue has the "oca" label so we cannot engage, sorry. Ah, sorry. I only asked because I saw a colleague of yours helping out with OCA verification over at https://github.com/openjdk/jdk/pull/23905#issuecomment-2762865417. Also, the [OCA FAQ](https://oca.opensource.oracle.com/?ojr=faq) suggests to "please reach out to project maintainers (e.g., through comments on your GitHub PR, Slack channels, or mailing lists)". Any breadcrumbs you can lay for me to escape this forest are appreciated! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2836014867 From duke at openjdk.org Wed May 7 17:20:33 2025 From: duke at openjdk.org (simon) Date: Wed, 7 May 2025 17:20:33 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 17:44:31 GMT, Benjamin Peterson wrote: >> This issue has the "oca" label so we cannot engage, sorry. > >> This issue has the "oca" label so we cannot engage, sorry. > > Ah, sorry. I only asked because I saw a colleague of yours helping out with OCA verification over at https://github.com/openjdk/jdk/pull/23905#issuecomment-2762865417. Also, the [OCA FAQ](https://oca.opensource.oracle.com/?ojr=faq) suggests to "please reach out to project maintainers (e.g., through comments on your GitHub PR, Slack channels, or mailing lists)". Any breadcrumbs you can lay for me to escape this forest are appreciated! Hello @benjaminp! I think you should wait for the OCA process ? it's very fast. I'll just ping @robilad, as he might be able to help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2836349678 From alanb at openjdk.org Wed May 7 17:31:20 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 17:31:20 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. Are you the submitter of JDK-8348828? Asking because the configuration described seems very unusual and sounds like something that changed the JDK image so the DLLs from the JDK bin directory are moved to somewhere else and sym link put in place instead. I think we also need to understand if there is a bug in File::getCanonicalPath before change the usage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859466053 From rgiulietti at openjdk.org Wed May 7 17:39:20 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 17:39:20 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:14:19 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 2643: >> >>> 2641: : new BigInteger(result, newSign).shiftLeft(bitsToShift); >>> 2642: } else { >>> 2643: if ((bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5) { >> >> Suggestion: >> >> if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) { >> >> or >> Suggestion: >> >> if ((bitLength() - 1L) * exponent >= (long) Integer.SIZE * MAX_MAG_LENGTH) { >> >> >> Both variant are easier to read, more honest, and exactly as efficient as with the shift. The right-hand sides are compile-time constants, so they have no impact on runtime performance. >> >> More generally, the runtime compilers are perfectly capable to optimize multiplications by constant powers of 2 and replace them with shifts, even if the other operand is not a constant. > > @rgiulietti What about `(bitLength() - 1L) * exponent >= Integer.MAX_VALUE`? Ah right, but you probably want Suggestion: if ((bitLength() - 1L) * exponent > Integer.MAX_VALUE) { I mean `>` rather than `>=` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078138621 From duke at openjdk.org Wed May 7 17:39:21 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 17:39:21 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:32:06 GMT, Raffaello Giulietti wrote: > Ah right, but you probably want No, the sufficient condition to get the overflow is `(bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078142049 From rgiulietti at openjdk.org Wed May 7 17:46:19 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 17:46:19 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:34:27 GMT, fabioromano1 wrote: >> Ah right, but you probably want >> Suggestion: >> >> if ((bitLength() - 1L) * exponent > Integer.MAX_VALUE) { >> >> I mean `>` rather than `>=` > >> Ah right, but you probably want > > No, the sufficient condition to get the overflow is `(bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote above. At some point you proposed (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5 Given the value of `MAX_MAG_LENGTH`, which is 2^26, this is equivalent to (bitLength() - 1L) * exponent >= 1L << 31 that is, to (bitLength() - 1L) * exponent > Integer.MAX_VALUE What am I missing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078163320 From lancea at openjdk.org Wed May 7 17:46:28 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 7 May 2025 17:46:28 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v6] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 18:21:30 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Restore Validator access level Hi Henry, Thank you for tackling this one. I am still going through this but have some initial comments on my 1st pass Can you also please address the following in jar.properties: - remove the duplicate entry of `main.help.opt.extract ` - update `main.help.opt.main.validate` to document the additional actions --validate now takes We also need to update `open/src/jdk.jartool/share/man/jar.md` as it currently contains no mentions of the `--validate `option src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 120: > 118: /** > 119: * Helper class to deduplicate entry names. > 120: * Keep a coutner for duplicate entry names and check if the entry name is valid on first add. counter -> counter src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 122: > 120: * Keep a coutner for duplicate entry names and check if the entry name is valid on first add. > 121: */ > 122: private class DedupEntryNames { Need a better name for this class as it is hard to understand what its purpose is from the name src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 122: > 120: * Keep a coutner for duplicate entry names and check if the entry name is valid on first add. > 121: */ > 122: private class DedupEntryNames { This class and some of its methods I would rename as it is difficult to understand what their purpose is and this will help future maintainers There also needs to be more meaningful class documentation given how the class/methods are used src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 124: > 122: private class DedupEntryNames { > 123: LinkedHashMap entries = new LinkedHashMap<>(); > 124: boolean isCEN; An enum might be clearer vs using a boolean for clarity src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127: > 125: > 126: public DedupEntryNames(boolean isCEN) { > 127: this.isCEN = isCEN; Might be clearer if this was an enum vs boolean? src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 135: > 133: isValid = false; > 134: } else if (!isZipEntryNameValid(entryName)) { > 135: warn(formatMsg("error.validator.bad.entry.name", entryName)); I think we need to consider a better message as 'malformed' might not be clear enough (also looks like this message was added but not used previously) error.validator.bad.entry.name=\ entry name malformed, {0} src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 135: > 133: isValid = false; > 134: } else if (!isZipEntryNameValid(entryName)) { > 135: warn(formatMsg("error.validator.bad.entry.name", entryName)); This message for `error.validator.bad.entry.name` could be clearer as I don't think "malformed" indicating the issues with the file name entry in the CEN/LOC Header. We should also prefix it a "Warning:" `entry name malformed, {0}` src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147: > 145: warn(formatMsg(msg, count.toString(), counter.getKey())); > 146: } > 147: return true; This seems to always be true as `warn()` results in `err.println` call (unless I am missing something) src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 150: > 148: } > 149: > 150: public LinkedList dedup() { Need a better method name and a comment for the method would be helpful for future maintainers src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 169: > 167: > 168: // Check next CEN entry is matching the specified name > 169: private boolean checkNextCenEntry(String locEntryName, LinkedList cenEntryNames) { The method description and method name could be clearer as to its purpose src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 184: > 182: > 183: /* > 184: * Retrieve entries from the XipInputStream to verify local file headers(LOC) XipInputStream -> ZipInputStream src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 184: > 182: > 183: /* > 184: * Retrieve entries from the XipInputStream to verify local file headers(LOC) Typo: `XipInputStream` src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 215: > 213: private boolean validate() { > 214: try { > 215: var dedupCEN = new DedupEntryNames(true); Please use a more insightful variable name src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 217: > 215: var dedupCEN = new DedupEntryNames(true); > 216: zf.stream() > 217: .peek(e -> dedupCEN.add(e.getName())) I am wondering if it might be clearer to consider breaking the above into a separate step for clarity vs part of the current stream traversal? Otherwise there should be more comments added for future maintainers src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147: > 145: in incompatible public interfaces > 146: warn.validator.duplicate.cen.entry=\ > 147: Warning: {0} copies of {1} is detected in central directory I would change: `Warning: {0} copies of {1} is detected in central directory` to: `Warning: There were {0} central directory headers found for file name {1} ` src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 148: > 146: warn.validator.duplicate.cen.entry=\ > 147: Warning: {0} copies of {1} is detected in central directory > 148: warn.validator.duplicate.loc.entry=\ Same comment as for `warn.validator.duplicate.cen.entry` src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 150: > 148: warn.validator.duplicate.loc.entry=\ > 149: Warning: {0} copies of {1} is detected in local file header > 150: warn.validator.cen.only.entry=\ I would change `Warning: Entry {0} in central directory is not in local file header` to `Warning: An equivalent local file header was not found for the central directory header for the file name: {0} ` src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 151: > 149: Warning: {0} copies of {1} is detected in local file header > 150: warn.validator.cen.only.entry=\ > 151: Warning: Entry {0} in central directory is not in local file header I would change the above to something like: Warning: An equivalent Local File header record for the Central Directory Header record for file {0} was not found src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 152: > 150: warn.validator.cen.only.entry=\ > 151: Warning: Entry {0} in central directory is not in local file header > 152: warn.validator.loc.only.entry=\ Same comment as for `warn.validator.duplicate.loc.entry` test/jdk/tools/jar/ValidatorTest.java line 106: > 104: var template = out.toByteArray(); > 105: // ISO_8859_1 to keep the 8-bit value > 106: var s = new String(template, StandardCharsets.ISO_8859_1); Is there a reason you are not using UTF8 here given that is the charset being used for the zip creation? test/jdk/tools/jar/ValidatorTest.java line 145: > 143: var template = out.toByteArray(); > 144: // ISO_8859_1 to keep the 8-bit value > 145: var s = new String(template, StandardCharsets.ISO_8859_1); Ok, but the zip is being created using UTF_8.... test/jdk/tools/jar/ValidatorTest.java line 232: > 230: var err = e.getMessage(); > 231: System.out.println(err); > 232: Assertions.assertTrue(err.contains("Warning: 2 copies of META-INF/MANIFEST.MF is detected in local file header")); Given you are importing Assertions, you should be able to just use `assertTrue` ------------- PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2819609944 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076261620 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076262727 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077860557 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076291444 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078105322 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076275933 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077910292 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078098847 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076276973 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076281636 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076283433 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077916062 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077909330 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077908477 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078106177 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078078764 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078088807 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076319729 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078089755 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077731161 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078159472 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078131560 From duke at openjdk.org Wed May 7 17:54:20 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 17:54:20 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:43:30 GMT, Raffaello Giulietti wrote: >>> Ah right, but you probably want >> >> No, the sufficient condition to get the overflow is `(bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote above. > > At some point you proposed > > (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5 > > Given the value of `MAX_MAG_LENGTH`, which is 2^26, this is equivalent to > > (bitLength() - 1L) * exponent >= 1L << 31 > > that is, to > > (bitLength() - 1L) * exponent > Integer.MAX_VALUE > > > What am I missing? The condition `A := (bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE` is more accurate, as it compares the bit length of the result, in fact `B := (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5` implies `A`, but `A` does not imply `B`. The `BigInteger`s can have a mag length up to `MAX_MAG_LENGTH`, but `MAX_MAG_LENGTH * Integer.SIZE > Integer.MAX_VALUE`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078174586 From rgiulietti at openjdk.org Wed May 7 18:01:25 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 18:01:25 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:51:05 GMT, fabioromano1 wrote: >> At some point you proposed >> >> (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5 >> >> Given the value of `MAX_MAG_LENGTH`, which is 2^26, this is equivalent to >> >> (bitLength() - 1L) * exponent >= 1L << 31 >> >> that is, to >> >> (bitLength() - 1L) * exponent > Integer.MAX_VALUE >> >> >> What am I missing? > > The condition `A := (bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE` is more accurate, as it compares the bit length of the result, in fact `B := (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5` implies `A`, but `A` does not imply `B`. The `BigInteger`s can have a mag length up to `MAX_MAG_LENGTH`, but `MAX_MAG_LENGTH * Integer.SIZE > Integer.MAX_VALUE`. OK. But then your original expression (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH was a bit too restrictive as well, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078191934 From henryjen at openjdk.org Wed May 7 18:02:33 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 7 May 2025 18:02:33 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v6] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:13:19 GMT, Lance Andersen wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore Validator access level > > src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127: > >> 125: >> 126: public DedupEntryNames(boolean isCEN) { >> 127: this.isCEN = isCEN; > > Might be clearer if this was an enum vs boolean? I feel the same way but wondering if that's an overkill. > src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147: > >> 145: warn(formatMsg(msg, count.toString(), counter.getKey())); >> 146: } >> 147: return true; > > This seems to always be true as `warn()` results in `err.println` call (unless I am missing something) I should clean that up better. As we just want to show the message but not really filter out that entry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078195738 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078193636 From duke at openjdk.org Wed May 7 18:04:17 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 18:04:17 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: Message-ID: <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com> On Wed, 7 May 2025 17:58:11 GMT, Raffaello Giulietti wrote: > OK. > > But then your original expression > > ``` > (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH > ``` > > was a bit too restrictive as well, right? On the contrary, it was too loose, as it admitted a bit length equal to `2^31 > Integer.MAX_VALUE`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078197555 From rgiulietti at openjdk.org Wed May 7 18:12:41 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 18:12:41 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com> References: <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com> Message-ID: On Wed, 7 May 2025 18:01:24 GMT, fabioromano1 wrote: >> OK. >> >> But then your original expression >> >> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH >> >> was a bit too restrictive as well, right? > >> OK. >> >> But then your original expression >> >> ``` >> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH >> ``` >> >> was a bit too restrictive as well, right? > > On the contrary, it was too loose, as it admitted a bit length equal to `MAX_MAG_LENGTH * Integer.SIZE == 2^31 > Integer.MAX_VALUE`. I mean, if B strictly implies A, then B is more restrictive (stronger). Since B is equivalent to your original formulation, to me it means that it was more restrictive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078218931 From abimpoudis at openjdk.org Wed May 7 18:30:59 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 7 May 2025 18:30:59 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: <5mcBz7IvDNxwrQJh9EjP-gKejbWG92idqojhc0MXjI8=.68a4d03a-5af9-430a-96de-20c8775d1dce@github.com> References: <5mcBz7IvDNxwrQJh9EjP-gKejbWG92idqojhc0MXjI8=.68a4d03a-5af9-430a-96de-20c8775d1dce@github.com> Message-ID: On Wed, 7 May 2025 16:36:09 GMT, Chen Liang wrote: >> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. >> >> For example this is not valid Java (and protected) by javac: >> >> >> byte b = 1; >> switch (b) { >> case String s -> System.out.println("How did we get here? byte is " + s.getClass()); >> } >> >> >> but this is a valid call (and not protected): >> >> >> CallSite shortSwitch = SwitchBootstraps.typeSwitch( >> MethodHandles.lookup(), >> "", >> MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int >> String.class); >> >> >> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. >> >> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 553: > >> 551: continue; >> 552: } >> 553: else if (unconditionalExactnessCheck(selectorType, classLabel)) { > > Can we merge this into `isNotValidPair(...) || unconditionalExactnessCheck(...)` then do nothing? The next label is already in theory immediately bound to the instruction after goto. The empty body means that we unconditionally return the index `case 0 -> /*no if is generated*/ return 0;`. I confirmed that by merging, the following test would not pass. It returns erroneously 0, instead of 1. testPrimitiveType((byte) 1, byte.class,0, 1, boolean.class, byte.class); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2078206536 From liach at openjdk.org Wed May 7 18:31:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 18:31:18 GMT Subject: RFR: 8356126: Duplication handling and optimization of CaptureCallState [v9] In-Reply-To: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com> References: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com> Message-ID: <2jO8bdVw7tAbJUIXsupJ8WMxlS0xafpPLMyK9cFvXXE=.38591311-e87f-4ab6-b786-dd10ae2ac286@github.com> On Tue, 6 May 2025 22:11:49 GMT, Chen Liang wrote: >> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. >> >> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. >> >> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) >> >> Testing: jdk/lang/foreign, tier 1-3 in progress. > > Chen Liang has updated the pull request incrementally with two additional commits since the last revision: > > - Indicate source file > - Keep in sync comments Seems there is no new reviews. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2859734901 From liach at openjdk.org Wed May 7 18:31:21 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 18:31:21 GMT Subject: Integrated: 8356126: Duplication handling and optimization of CaptureCallState In-Reply-To: References: Message-ID: On Sun, 4 May 2025 22:37:21 GMT, Chen Liang wrote: > Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap. > > Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly. > > Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field) > > Testing: jdk/lang/foreign, tier 1-3 in progress. This pull request has now been integrated. Changeset: 8c1b915c Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/8c1b915c7ef2b3a6e65705b91f4eb464caaec4e7 Stats: 128 lines in 7 files changed: 37 ins; 44 del; 47 mod 8356126: Duplication handling and optimization of CaptureCallState Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/25025 From duke at openjdk.org Wed May 7 18:32:50 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 18:32:50 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v53] In-Reply-To: References: Message-ID: <416Ep8OzMrQzitAI-WaIkgbhu7RAcriT9W63DZyblLc=.28549efe-7c6c-4a29-be36-df35f20d6035@github.com> > This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24690/files - new: https://git.openjdk.org/jdk/pull/24690/files/e0816d55..009937b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=52 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=51-52 Stats: 64 lines in 2 files changed: 29 ins; 29 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24690.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690 PR: https://git.openjdk.org/jdk/pull/24690 From duke at openjdk.org Wed May 7 18:32:50 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 7 May 2025 18:32:50 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51] In-Reply-To: References: <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com> Message-ID: On Wed, 7 May 2025 18:10:36 GMT, Raffaello Giulietti wrote: > I mean, if B strictly implies A, then B is more restrictive (stronger). Since B is equivalent to your original formulation, to me it means that it was more restrictive. Exactly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078224687 From kbarrett at openjdk.org Wed May 7 18:33:08 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 7 May 2025 18:33:08 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v5] In-Reply-To: References: Message-ID: > Please review this change which adds a native method providing the > implementation of Reference::get. Referece::get is an intrinsic candidate, so > this native method implementation is only used when the intrinsic is not. > > Currently there is intrinsic support by the interpreter, C1, C2, and graal, > which are always used. With this change we can later remove all the > per-platform interpreter intrinsic implementations, and might also remove the > C1 intrinsic implementation. > > Testing: > (1) mach5 tier1-6 normal (so using all the existing intrinsics). > (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. Kim Barrett 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: - use new waitForRefProc, some tidying - Merge branch 'master' into native-reference-get - remove timeout by using waitForReferenceProcessing - make ill-timed gc in non-concurrent case less likely - fix test package use - add package decl to test - parameterized return type of native get0 - test native method - native Reference.get helper ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24315/files - new: https://git.openjdk.org/jdk/pull/24315/files/234465f4..48b7960c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=03-04 Stats: 334519 lines in 3461 files changed: 113842 ins; 207130 del; 13547 mod Patch: https://git.openjdk.org/jdk/pull/24315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315 PR: https://git.openjdk.org/jdk/pull/24315 From vyazici at openjdk.org Wed May 7 18:33:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 18:33:12 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com> Message-ID: On Wed, 7 May 2025 13:22:11 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355: >> >>> 353: * UTF-16 representation. >>> 354: *

    >>> 355: * WARNING: This method does not perform any bound checks. >> >> Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked". > > As mentioned by Alan and Jaikiran, at some point it is advisable to prefix the names with "unchecked". > > For the "noRepl" names, perhaps the mouthful but clearer "noReplacementChar" might help. @jaikiran, @AlanBateman, implemented `unchecked` method prefix in 4d237efa053. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2078253548 From vyazici at openjdk.org Wed May 7 18:33:11 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 18:33:11 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v3] In-Reply-To: References: Message-ID: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Prefix touched methods with `unchecked` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24982/files - new: https://git.openjdk.org/jdk/pull/24982/files/f0623258..4d237efa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=01-02 Stats: 66 lines in 21 files changed: 0 ins; 3 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From vyazici at openjdk.org Wed May 7 18:39:42 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 18:39:42 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:52:37 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 332: > >> 330: *

    >> 331: * This method throws {@code CharacterCodingException} instead of replacing >> 332: * when malformed input or unmappable characters are encountered. > > Do we have a JBS issue to track renaming the "no replacement" methods? The naming has confused several people as not everyone is familiar with coding error actions. Here, "no replacement" actually means that coding errors are reported. Created [JDK-8356439](https://bugs.openjdk.org/browse/JDK-8356439) for this purpose. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2078269984 From duke at openjdk.org Wed May 7 18:43:57 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 7 May 2025 18:43:57 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:28:23 GMT, Alan Bateman wrote: > Are you the submitter of JDK-8348828? Yes, I am. > Asking because the configuration described seems very unusual and sounds like something that changed the JDK image so the DLLs from the JDK bin directory are moved to somewhere else and sym link put in place instead. Correct, I explained a bit on the issue, but we have a system that replicates normal filesystem trees with symlink trees. > I think we also need to understand if there is a bug in File::getCanonicalPath before change the usage. I believe the problem is that `getCanonicalPath` is working too well and that symlink resolution of native libraries should be left to the system resolver. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859855724 From liach at openjdk.org Wed May 7 18:56:53 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 May 2025 18:56:53 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis wrote: > While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. > > For example this is not valid Java (and protected) by javac: > > > byte b = 1; > switch (b) { > case String s -> System.out.println("How did we get here? byte is " + s.getClass()); > } > > > but this is a valid call (and not protected): > > > CallSite shortSwitch = SwitchBootstraps.typeSwitch( > MethodHandles.lookup(), > "", > MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int > String.class); > > > The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. > > This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. looks good! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25090#pullrequestreview-2822890841 From alanb at openjdk.org Wed May 7 19:07:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 19:07:52 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859921963 From lancea at openjdk.org Wed May 7 19:13:50 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 7 May 2025 19:13:50 GMT Subject: RFR: 8353232: Standardizing and Unifying XML Component Configurations In-Reply-To: References: Message-ID: <2OoPRoRRxyUejk3PuSfSn5spQDNUnkdd4tHC1dzyh5k=.a10280df-0173-42d9-8b7c-751e8ef0ddc9@github.com> On Wed, 7 May 2025 16:17:07 GMT, Joe Wang wrote: > This is a refactor patch, no change in functionality. > > This patch refactor the configuration code. Rather than for each factory to go through the whole configuration process, a base configuration as represented in JdkXmlConfig is created once, which includes loading of the JAXP Configuration file, factories then get their own copies of the property managers, created on top of the base ones rather than directly constructed. > > The JDKCatalog and its Resolver are lazily initialized when external references are encountered. This code replaces the original code block within the security manager. This change also addresses JDK-8350189. > > The rest of changes basically replace all direct constructions of XMLSecurityManager/XMLSecurityPropertyManager with calls to JdkXmlConfig's corresponding get methods, which return clones of the base instances. in the factory classes, these clones are updated with property settings on the factories. In non-public or legacy code paths (inherited from upstream components), such updates may not be necessary. > > Tests: existing tests T1-3 passed; XML JCK tests passed. Hi Joe, This looks good overall. ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25102#pullrequestreview-2822928555 From duke at openjdk.org Wed May 7 19:23:51 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 7 May 2025 19:23:51 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. Going back to the reproducer in my OP on JBS: > mv .\jdk-24\bin\jimage.dll rando > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando > \jdk-24\bin\javac During JVM startup, `NativeImageBuffer` will execute `System.loadLibrary("jimage")`, which will eventually make its way into `NativeLibraries.loadLibrary`. `NativeLibraries` will search the native library path and identitfy `.\jdk-24\bin\jimage.dll` as a file to load. The `getCanonicalPath()` invocation changed in this PR will be invoked to determine the final path to load. At this point, the path to load will be `$PWD\rando` due to symlink resolution. Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail. This chain of events is avoided by presenting `LoadLibrary` with `jimage.dll` and letting the system do the symlink resolution as happened previously in JDK23. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859971671 From duke at openjdk.org Wed May 7 19:33:05 2025 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Wed, 7 May 2025 19:33:05 GMT Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> Message-ID: On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s 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) Need more time to check test coverage ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2859994821 From bpb at openjdk.org Wed May 7 21:21:57 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 May 2025 21:21:57 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 7 May 2025 19:21:38 GMT, Benjamin Peterson wrote: > > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando What if instead this were the following > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando.dll where `.dll` is appended to the target? > At this point, the path to load will be `$PWD\rando` due to symlink resolution. Which is in fact correct, no? > Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail. Indeed from the `LoadLibrary` documentation If the string specifies a module name without a path and the file name extension is omitted, the function appends the default library extension ".DLL" to the module name. To prevent the function from appending ".DLL" to the module name, include a trailing point character (.) in the module name string. so a trailing `.` character on `rando` might equally resolve the problem? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860411482 From duke at openjdk.org Wed May 7 21:49:52 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 7 May 2025 21:49:52 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com> On Wed, 7 May 2025 21:19:41 GMT, Brian Burkhalter wrote: > > > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando > > What if instead this were the following > > ``` > > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando.dll > ``` > > where `.dll` is appended to the target? I expect that would work given the `LoadLibrary` documentation you've quoted. > > > At this point, the path to load will be `$PWD\rando` due to symlink resolution. > > Which is in fact correct, no? Correct in that that's the library that should be loaded. `LoadLibrary` doesn't want to cooperate, though. > > > Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail. > > Indeed from the `LoadLibrary` documentation > > ``` > If the string specifies a module name without a path and the file name extension is > omitted, the function appends the default library extension ".DLL" to the module name. > To prevent the function from appending ".DLL" to the module name, include a trailing > point character (.) in the module name string. > ``` > > so a trailing `.` character on `rando` might equally resolve the problem? Perhaps. In my usecase, files come into the system "anonymously"; files that make up the symlink tree are received before it's known what the layout of the tree will be. A link to a given file could turn out to be, e.g., `myaudio.mp3`, `MyClass.java`, or `jimage.dll`. I'm disinclined to append `.` or `.DLL` to every file in off chance that it turns out to be a library that Java wants to load. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860469015 From darcy at openjdk.org Wed May 7 22:41:54 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 7 May 2025 22:41:54 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v7] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 15:28:39 GMT, Raffaello Giulietti wrote: >> If I understand correctly, we are talking about several (primitive) array type fields having a `@Stable` annotation, in a single class, right? So we aren't really talking about levels? >> If so, given what `@Stable` is documented to do, I don't think the number of fields annotated as `@Stable` plays any role in the C2 compiler generating the resultant code. > > @jaikiran "Levels" in the sense that Q_MIN depends on E_MIN, which depends on E_MAX, which depends on W, which depends on P. > If `@Stable` helps, which I think it does, great. If it doesn't, it shouldn't matter in practice. Generally good cleanup @rgiulietti. I'd like to see some kind of representation of the grammar of strings being recognized included in this file, for example a cut-and-paste of the grammar from Double.valueOf(String) (with leading and trailing spaces): FloatValue: Sign_opt NaN Sign_opt Infinity Sign_opt FloatingPointLiteral Sign_opt HexFloatingPointLiteral SignedInteger HexFloatingPointLiteral: HexSignificand BinaryExponent FloatTypeSuffixopt HexSignificand: HexNumeral HexNumeral . 0x HexDigitsopt . HexDigits 0X HexDigitsopt . HexDigits BinaryExponent: BinaryExponentIndicator SignedInteger BinaryExponentIndicator: p P ------------- PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2860610215 From bchristi at openjdk.org Wed May 7 22:44:54 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 7 May 2025 22:44:54 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply reviewer suggestions for typos, javadoc, and copyright dates. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1912: > 1910: * @param count the count of characters in the original buffer > 1911: * @param index the insertion point > 1912: * @param s char[] array to insert from Should be: `@param` s `CharSequence` to insert from ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2078589707 From asemenyuk at openjdk.org Wed May 7 22:49:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 7 May 2025 22:49:54 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v3] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev wrote: >> - Symbolic links will not be followed for `--app-content` on all platforms. >> - Added test to cover this case. >> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8352480: [macos] Don't follow symlinks in additional content for app images [v5] test/jdk/tools/jpackage/share/AppContentTest.java line 116: > 114: private static Path getAppContentPath(JPackageCommand cmd, Path name) { > 115: Path contentDir = cmd.appLayout().contentDirectory(); > 116: // Links are always created in "Resources" > Links are always created in "Resources" All additional content on macOS is created in the "Resources" directory. On Linux there is no such requirement. The return value of `getAppContentPath()` is not supposed to depend on the additional content type; the new "name" parameter doesn't make sense to me. test/jdk/tools/jpackage/share/AppContentTest.java line 147: > 145: > 146: private static Path copyAppContentPath(Path appContentPath) throws IOException { > 147: Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources"); This is a redundant change test/jdk/tools/jpackage/share/AppContentTest.java line 149: > 147: Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources"); > 148: var srcPath = TKit.TEST_SRC_ROOT.resolve(appContentPath); > 149: Path dstPath = appContentArg.resolve(srcPath.getFileName()); This is a redundant change test/jdk/tools/jpackage/share/AppContentTest.java line 164: > 162: private static List initAppContentPaths(List appContentPaths) { > 163: boolean copy = (copyInResources || appContentPaths.stream() > 164: .anyMatch(s -> s.toString().contains("Link"))); `s.toString().contains("Link")` is a lousy way to detect if the path is a symlink. "s" can be an absolute path (to the local OpenJDK repo) that may have a "Link" substring in one of path components, like "/home/BLink/my-projects/open/test/jdk/tools/jpackage/non-existant". The test will fail, and we will have a very hard time figuring out the cause. I'd fix it by narrowing the scope from the full path to the filename; create a dedicated function for detecting if the given path is supposed to be a symlink instead of repeating `.toString().contains("Link")`: private static boolean isSymlinkPath(Path v) { return v.getFileName().toString().contains("Link"); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077510440 PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077512476 PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077512103 PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077542387 From bpb at openjdk.org Wed May 7 23:04:51 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 May 2025 23:04:51 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com> References: <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com> Message-ID: On Wed, 7 May 2025 21:47:37 GMT, Benjamin Peterson wrote: > > > At this point, the path to load will be `$PWD\rando` due to symlink resolution. > > > > > > Which is in fact correct, no? > > Correct in that that's the library that should be loaded. `LoadLibrary` doesn't want to cooperate, though. So is it correct to say that the link resolution appears correct but `LoadLibrary`'s quirks cause the intended behavior to fail? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860642950 From bchristi at openjdk.org Wed May 7 23:22:01 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 7 May 2025 23:22:01 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply reviewer suggestions for typos, javadoc, and copyright dates. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2042: > 2040: * @param coder the coder of the buffer > 2041: * @param count the character count > 2042: * @param s a string Should be: `@param` s a `CharSequence` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2078645712 From duke at openjdk.org Wed May 7 23:23:52 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 7 May 2025 23:23:52 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com> Message-ID: On Wed, 7 May 2025 23:02:41 GMT, Brian Burkhalter wrote: > > > > At this point, the path to load will be `$PWD\rando` due to symlink resolution. > > > > > > > > > Which is in fact correct, no? > > > > > > Correct in that that's the library that should be loaded. `LoadLibrary` doesn't want to cooperate, though. > > So is it correct to say that the link resolution appears correct but `LoadLibrary`'s quirks cause the intended behavior to fail? Yes. The `getCanonicalPath` canonicalization indeed produces the file pointed to by the symlink. However, in the context of `NativeLibraries`, doing path canonicalization is at best unnecessary and at worst yields the linked bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860678324 From bpb at openjdk.org Wed May 7 23:32:51 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 May 2025 23:32:51 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com> Message-ID: On Wed, 7 May 2025 23:21:20 GMT, Benjamin Peterson wrote: > > So is it correct to say that the link resolution appears correct but `LoadLibrary`'s quirks cause the intended behavior to fail? > > Yes. The `getCanonicalPath` canonicalization indeed produces the file pointed to by the symlink. All right, it is good to know that it is behaving in the desired manner. > However, in the context of `NativeLibraries`, doing path canonicalization is at best unnecessary and at worst yields the linked bug. You might be correct. We'll see what @AlanBateman and others have to say about it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860711420 From ccheung at openjdk.org Thu May 8 00:28:07 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 8 May 2025 00:28:07 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking Message-ID: This fix adds the `--add-reads` support for CDS and AOTClassLinking. Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` During runtime, the archived full module graph will be disabled: `[0.021s][info][cds ] full module graph: disabled` With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. Testing: tiers 1 - 4. ------------- Commit messages: - fix trailing whitespace - 8354083: Support --add-reads with -XX:+AOTClassLinking Changes: https://git.openjdk.org/jdk/pull/25109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354083 Stats: 111 lines in 4 files changed: 81 ins; 14 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25109/head:pull/25109 PR: https://git.openjdk.org/jdk/pull/25109 From duke at openjdk.org Thu May 8 01:01:06 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 8 May 2025 01:01:06 GMT Subject: Integrated: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG wrote: > This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. > > In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. > > To ensure quality... > * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. > * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. This pull request has now been integrated. Changeset: 7642556a Author: Markus KARG Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/7642556a5a131e9104033ad7d7abfdb4be5012cf Stats: 470 lines in 8 files changed: 399 ins; 59 del; 12 mod 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer Reviewed-by: liach, jpai, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/21730 From xgong at openjdk.org Thu May 8 01:53:58 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 8 May 2025 01:53:58 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:02:43 GMT, Jatin Bhateja wrote: >> Hi @jatin-bhateja It is feasible. But I was thinking about whether another solution would be better, which is to turn `VectorMask.fromLong(SPECIES, -1L)` into `MaskAll(true)` in the mid-end. In this way, we don't need to check this pattern in this optimization. What do you think ? > > Yes, that's the right approach. For this PR, I think you can mix some test points covering compare, xor(maskAll(true)). Yes, converting `VectorMask.fromLong(SPECIES, -1L)` to `MaskAll()` would be better, and that will benefit AArch64 as well, since `MaskAll()` is much more cheaper than `fromLong()` on AArch64. We can add such a transformation with another PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2078760074 From iklam at openjdk.org Thu May 8 03:24:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 03:24:50 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 00:19:17 GMT, Calvin Cheung wrote: > This fix adds the `--add-reads` support for CDS and AOTClassLinking. > Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: > `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` > During runtime, the archived full module graph will be disabled: > `[0.021s][info][cds ] full module graph: disabled` > > With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. > > Testing: tiers 1 - 4. I think we need a test to validate that the `--add-reads` flag actually works. I wrote such a test when I implemented `--add-exports`: see [runtime/cds/appcds/jigsaw/modulepath/AddExports.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddExports.java) I think we need a similar test for `--add-opens` as well. Since the main reason for supporting `--add-{expors,opens,reads}` is for user of AOT class linking, I would suggest moving the above AddExports.java test to - runtime/cds/appcds/aotClassLinking/modules/AddExports.java And then add AddReads.java and AddOpens.java there as well. The reason for putting the tests inside aotClassLinking is that they will be excluded from the `hotspot_appcds_dynamic` and `hotspot_aot_classlinking` test groups, so you don't need to add special case code to handle those two test groups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2861575003 From alanb at openjdk.org Thu May 8 07:10:35 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 07:10:35 GMT Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v12] In-Reply-To: References: Message-ID: > Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically: > > - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. > - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. > - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. > - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. > - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. > > The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - Merge branch 'master' into JDK-8342486 - Merge branch 'master' into JDK-8342486 - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - Merge branch 'master' into JDK-8342486 - Add JEP number, update copyright headers - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - ... and 12 more: https://git.openjdk.org/jdk/compare/52a5583d...c61ba159 ------------- Changes: https://git.openjdk.org/jdk/pull/21934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=11 Stats: 4036 lines in 14 files changed: 1818 ins; 1438 del; 780 mod Patch: https://git.openjdk.org/jdk/pull/21934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934 PR: https://git.openjdk.org/jdk/pull/21934 From pminborg at openjdk.org Thu May 8 07:16:28 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 07:16:28 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v8] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add lazy CallSite methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/de8e2387..e2a2d7bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=06-07 Stats: 64 lines in 2 files changed: 62 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From pminborg at openjdk.org Thu May 8 07:27:50 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 07:27:50 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v9] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Revert changes in stable classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/e2a2d7bd..e928591a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=07-08 Stats: 23 lines in 2 files changed: 8 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From pminborg at openjdk.org Thu May 8 07:40:44 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 07:40:44 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Clean up and remove unrelated changed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/e435762b..3a4cf9dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=05-06 Stats: 115 lines in 5 files changed: 0 ins; 100 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Thu May 8 07:54:17 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 07:54:17 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/3a4cf9dc..c5159e5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=06-07 Stats: 46 lines in 2 files changed: 0 ins; 45 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Thu May 8 07:54:17 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 07:54:17 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: <60XAq-TsBu_ZOi281yI0VKJDJsHIQQ6FHuM7oYMrdX4=.a5264b71-c008-48fa-bb64-fd31153373d5@github.com> On Thu, 8 May 2025 07:40:44 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Clean up and remove unrelated changed Updated benchmarks: Benchmark Mode Cnt Score Error Units CaptureStateUtilBench.OfVirtual.adaptedSysCallFail avgt 30 34.138 ? 0.269 ns/op CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess avgt 30 12.660 ? 0.251 ns/op CaptureStateUtilBench.OfVirtual.explicitAllocationFail avgt 30 39.592 ? 0.319 ns/op CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess avgt 30 21.379 ? 0.162 ns/op CaptureStateUtilBench.adaptedSysCallFail avgt 30 30.636 ? 0.410 ns/op CaptureStateUtilBench.adaptedSysCallSuccess avgt 30 4.990 ? 0.042 ns/op CaptureStateUtilBench.explicitAllocationFail avgt 30 39.763 ? 0.316 ns/op CaptureStateUtilBench.explicitAllocationSuccess avgt 30 21.420 ? 0.241 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/25043#issuecomment-2862103792 From vklang at openjdk.org Thu May 8 08:02:02 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 May 2025 08:02:02 GMT Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v12] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 07:10:35 GMT, Alan Bateman wrote: >> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically: >> >> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. >> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. >> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. >> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. >> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. >> >> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Add JEP number, update copyright headers > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - ... and 12 more: https://git.openjdk.org/jdk/compare/52a5583d...c61ba159 Marked as reviewed by vklang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21934#pullrequestreview-2824182310 From vklang at openjdk.org Thu May 8 08:38:55 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 May 2025 08:38:55 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com> On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote: > We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR. > > 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take > > The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. > > 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators > > LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. > > The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking. > > This can be fixed very easily by linking both f.prev and f.next back to f. > > 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached > > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > 4. LinkedBlockingDeque allows us to overflow size with addAll() > > In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed... src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 341: > 339: if (count >= capacity) > 340: return false; > 341: linkFirst(node); I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean? src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 735: > 733: */ > 734: public int remainingCapacity() { > 735: return capacity - count; Nice improvement! src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 817: > 815: */ > 816: public int size() { > 817: return count; Nice improvement here as well! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079178889 PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079183074 PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079183713 From sgehwolf at openjdk.org Thu May 8 08:40:00 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 8 May 2025 08:40:00 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v17] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 14:59:37 GMT, Severin Gehwolf 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 44 commits: > > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - JDK-8350103 > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Fix missing imports > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - ... and 34 more: https://git.openjdk.org/jdk/compare/6801eb87...32960cd6 Keep open, bot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2862232316 From mcimadamore at openjdk.org Thu May 8 08:46:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 May 2025 08:46:54 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove class src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 53: > 51: private static final BufferStack POOL = BufferStack.of(CAPTURE_LAYOUT); > 52: > 53: // Do not use a lambda in order to allow early use in the init sequence This can be a local variable in the static initializer, right -- e.g. no need to expose it at class-level? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079201294 From vklang at openjdk.org Thu May 8 08:44:55 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 May 2025 08:44:55 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote: > We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR. > > 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take > > The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. > > 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators > > LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. > > The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking. > > This can be fixed very easily by linking both f.prev and f.next back to f. > > 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached > > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > 4. LinkedBlockingDeque allows us to overflow size with addAll() > > In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed... src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 860: > 858: // As historically specified in AbstractQueue#addAll > 859: throw new IllegalArgumentException(); > 860: We could likely check if there's any remaining capacity up front, and immediately return false? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079194580 From mcimadamore at openjdk.org Thu May 8 08:50:53 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 May 2025 08:50:53 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove class src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 110: > 108: > 109: @Override > 110: public int hashCode() { isn't the default toString/hashCode/equals for records good enough? If these overload are added for bootstrapping, please say so in a comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079206969 From vklang at openjdk.org Thu May 8 08:53:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 May 2025 08:53:58 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote: > We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR. > > 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take > > The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. > > 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators > > LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. > > The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking. > > This can be fixed very easily by linking both f.prev and f.next back to f. > > 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached > > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > 4. LinkedBlockingDeque allows us to overflow size with addAll() > > In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed... test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1958: > 1956: q.add(four); > 1957: q.add(five); > 1958: q.add(six); Out of curiosity, how does `it.remove()` work under these conditions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079213178 From mcimadamore at openjdk.org Thu May 8 09:02:02 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 May 2025 09:02:02 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove class src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 244: > 242: } > 243: > 244: private static MethodHandle makeBasicHandle(BasicKey basicKey) { more than a "basic handle" this seems more a "return filter" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079227117 From vklang at openjdk.org Thu May 8 09:02:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 May 2025 09:02:52 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote: > We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR. > > 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take > > The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. > > 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators > > LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. > > The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking. > > This can be fixed very easily by linking both f.prev and f.next back to f. > > 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached > > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > 4. LinkedBlockingDeque allows us to overflow size with addAll() > > In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed... src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 865: > 863: long n = 0; > 864: for (E e : c) { > 865: Objects.requireNonNull(e); This makes me wonder: Does it make sense to create new nodes if we don't track if they will still fit into the capacity? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079229217 From rgiulietti at openjdk.org Thu May 8 09:18:00 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 8 May 2025 09:18:00 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v53] In-Reply-To: <416Ep8OzMrQzitAI-WaIkgbhu7RAcriT9W63DZyblLc=.28549efe-7c6c-4a29-be36-df35f20d6035@github.com> References: <416Ep8OzMrQzitAI-WaIkgbhu7RAcriT9W63DZyblLc=.28549efe-7c6c-4a29-be36-df35f20d6035@github.com> Message-ID: On Wed, 7 May 2025 18:32:50 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Suggested changes Last nits. I'll approve the PR in the next couple of days for last minute small changes from you. src/java.base/share/classes/java/math/BigInteger.java line 2656: > 2654: // Perform exponentiation using repeated squaring trick > 2655: // The loop relies on this invariant: > 2656: // base^exponent == answer^(2^expLen) * base^(exponent & (2^expLen - 1)) The invariant is correct, but it should minimally involve all running variables updated in the loop, including `workingExp`. Otherwise, reasoning about the invariant becomes harder. Further, I suggest to replace the subexpression `exponent & (2^expLen - 1)` with the more mathematical `exponent % (2^expLen)`. test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 62: > 60: * Each array entry is atmost 64 bits > 61: * in size > 62: */ This can be re-flowed more compactly like so (and similarly for the other fields) Suggestion: private int xsExp = (1 << 20) - 1; /* Each array entry is at most 64 bits in size */ private BigInteger[] xsArray = new BigInteger[TESTSIZE]; ------------- PR Review: https://git.openjdk.org/jdk/pull/24690#pullrequestreview-2824381118 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2079247545 PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2079251316 From pminborg at openjdk.org Thu May 8 09:21:35 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 09:21:35 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v9] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/c5159e5f..9772c703 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=07-08 Stats: 51 lines in 3 files changed: 9 ins; 19 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From pminborg at openjdk.org Thu May 8 09:21:35 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 09:21:35 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Thu, 8 May 2025 08:47:50 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove class > > src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 110: > >> 108: >> 109: @Override >> 110: public int hashCode() { > > isn't the default toString/hashCode/equals for records good enough? If these overload are added for bootstrapping, please say so in a comment Added for bootstrapping but I think this could be addressed in another way (e.g. helloClass once this class is used). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079258413 From mcimadamore at openjdk.org Thu May 8 09:23:53 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 May 2025 09:23:53 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v9] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Thu, 8 May 2025 09:21:35 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 15520: > 15518: > 15519: > 15520: Spurious commit? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079264611 From ihse at openjdk.org Thu May 8 10:19:31 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 May 2025 10:19:31 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). Magnus Ihse Bursie 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' into go-full-utf8 - Merge branch 'master' into go-full-utf8 - Add informative message about supported locales. - Allow C locale with warning instead of fatal error - Also document UTF-8 requirements (solves JDK-8338973) - Let configure only accept utf-8 locales - Address review comments from Kim - Also tell javadoc that we have utf-8 now - Fix flags for Windows - Mark java and native source code as utf-8 - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db ------------- Changes: https://git.openjdk.org/jdk/pull/24574/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=05 Stats: 177 lines in 13 files changed: 49 ins; 105 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/24574.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574 PR: https://git.openjdk.org/jdk/pull/24574 From pminborg at openjdk.org Thu May 8 10:42:54 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 10:42:54 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v9] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: On Thu, 8 May 2025 09:21:42 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 15520: > >> 15518: >> 15519: >> 15520: > > Spurious commit? OOops! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079464125 From pminborg at openjdk.org Thu May 8 10:50:55 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 10:50:55 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v10] In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Revert more incidental changes - Revert incidental change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25043/files - new: https://git.openjdk.org/jdk/pull/25043/files/9772c703..4a6ae69e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=08-09 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043 PR: https://git.openjdk.org/jdk/pull/25043 From vklang at openjdk.org Thu May 8 12:04:53 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 May 2025 12:04:53 GMT Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote: >> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies. > >> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies. > > It seems to about nested parking that can arise with the first use of LockSupport.park from a class with a defining class loader that is not the boot loader. The first usage, say an invokestatic to call the park method, will call the loadClass on caller's defining class loader. For the app class loader, and many other custom class loaders, that are parallel capable, then there will be a CHM to support the mapping of class names to locks. Contention on the CHM seems to have lead to the nested park. CHM and a lot of other code has changed since and not clear that it will duplicate easily now. Martin's ParkLoops test from the 2015 issue is in the test tree but it might be that a variant of this that uses a custom class loader that overrides getClassLoadingLock or parks in loadClass might be able to trigger it. As a custom class loader's loadClass can do anything then it almost feels like creating a class loader needs it have it recorded immediately as an initiating class loader. Hop efully David will remember more of this when he gets back. I'll second @AlanBateman 's sentiments here. I think a systemic issue needs a wholesale solution, otherwise it'll just lead to endless sprinkling of eager initializations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2862799361 From jpai at openjdk.org Thu May 8 12:12:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 May 2025 12:12:05 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry Message-ID: Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799? `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix. tier testing is currently in progress. ------------- Commit messages: - 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry - 8354799: add test Changes: https://git.openjdk.org/jdk/pull/25116/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354799 Stats: 169 lines in 2 files changed: 168 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25116.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25116/head:pull/25116 PR: https://git.openjdk.org/jdk/pull/25116 From alanb at openjdk.org Thu May 8 12:28:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 12:28:51 GMT Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote: >> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies. > >> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies. > > It seems to about nested parking that can arise with the first use of LockSupport.park from a class with a defining class loader that is not the boot loader. The first usage, say an invokestatic to call the park method, will call the loadClass on caller's defining class loader. For the app class loader, and many other custom class loaders, that are parallel capable, then there will be a CHM to support the mapping of class names to locks. Contention on the CHM seems to have lead to the nested park. CHM and a lot of other code has changed since and not clear that it will duplicate easily now. Martin's ParkLoops test from the 2015 issue is in the test tree but it might be that a variant of this that uses a custom class loader that overrides getClassLoadingLock or parks in loadClass might be able to trigger it. As a custom class loader's loadClass can do anything then it almost feels like creating a class loader needs it have it recorded immediately as an initiating class loader. Hop efully David will remember more of this when he gets back. > I'll second @AlanBateman 's sentiments here. I think a systemic issue needs a wholesale solution, otherwise it'll just lead to endless sprinkling of eager initializations. Right, and even then, the issue is deeper than this. It's when the reference to LockSupport is from a class with a non-null defining class loader. In that scenario, the non-null class loader is the initiating class loader and any parking in the delegation chain to get to the boot loader could potentially consume the park permit. I don't think we should go down the road of supporting nested parking, instead it may be that we need some eager setup. I think we can close this PR for now as it doesn't really address the issue (LockSupport is already loaded before any user code executes). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2862877836 From alanb at openjdk.org Thu May 8 13:03:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 13:03:53 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry In-Reply-To: References: Message-ID: On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799? > > `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix. > > tier testing is currently in progress. Do you have any sense on whether there are JAR files in use that have wrong CRCs for empty entries? I'm just wondering if there are any wonky tools or plugins in the eco system, the output of which could be impacted by the more strict check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2862971376 From jpai at openjdk.org Thu May 8 13:13:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 May 2025 13:13:57 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:01:38 GMT, Alan Bateman wrote: > I'm just wondering if there are any wonky tools or plugins in the eco system, the output of which could be impacted by the more strict check. I'll run some experiments and see what it shows up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863017735 From pminborg at openjdk.org Thu May 8 13:16:25 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 13:16:25 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v10] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add composition of functions and MHs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/e928591a..1628b264 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=08-09 Stats: 292 lines in 4 files changed: 157 ins; 45 del; 90 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From nbenalla at openjdk.org Thu May 8 13:18:07 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 8 May 2025 13:18:07 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - feedback: never bump ASM version - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274 + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274 + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274 + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274 + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274 - Update --release 25 symbol information for JDK 24 build 20 The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/ - initial commit start-of-JDK-26 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=01 Stats: 1390 lines in 53 files changed: 1299 ins; 16 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Thu May 8 13:18:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 8 May 2025 13:18:08 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:42:04 GMT, Joe Darcy wrote: >> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50: >> >>> 48: public class HelpOutputColumnWidthTest extends TestRunner { >>> 49: >>> 50: public static final int MAX_COLUMNS = 84; >> >> What is this for? > > It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26". > > Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch. I'll split the releases over two lines in the next update. The line is a little too long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2079697514 From pminborg at openjdk.org Thu May 8 13:28:56 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 13:28:56 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v3] In-Reply-To: References: Message-ID: <59OdbQo1ngGTIk-vHURu151vFfblIVyHRATwhTGqFY0=.e5a6c409-e23d-435c-a86c-4847ac392ef1@github.com> On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Prefix touched methods with `unchecked` LGTM ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825136323 From alanb at openjdk.org Thu May 8 13:31:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 13:31:51 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:10:57 GMT, Jaikiran Pai wrote: > I'll run some experiments and see what it shows up. Thanks as that will help inform as to whether this will need a compatibility knob. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863078781 From vromero at openjdk.org Thu May 8 13:33:45 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 May 2025 13:33:45 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Merge branch 'master' into JDK-8354556 - addressing review comment - changes to test - Merge branch 'master' into JDK-8354556 - updating test - final adjustments - additional refactorings - removing unneeded changes - more refactorings - more refactorings and tests - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0 ------------- Changes: https://git.openjdk.org/jdk/pull/24746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=05 Stats: 497 lines in 25 files changed: 471 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From eirbjo at openjdk.org Thu May 8 13:34:53 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 8 May 2025 13:34:53 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry In-Reply-To: References: Message-ID: On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799? > > `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix. > > tier testing is currently in progress. I found ?empty ZipEntry? in the title here somewhat confusing since that?s an API class and can?t be ?empty? as such. We think ?ZIP entry with empty file data? would be more correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863085922 From lancea at openjdk.org Thu May 8 13:39:55 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 8 May 2025 13:39:55 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry In-Reply-To: References: Message-ID: On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799? > > `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix. > > tier testing is currently in progress. Hi Jai, I think the changes overall look good. You could simplify the test by creating a zip then converting the bytes to a Hex string/byte array and store it in the test. I mention this as you are searching for a Data Descriptor signature that is optional in the test. If you capture the byte array/Hex String and then write it out as part of the start of the test. The hex offsets from ZipDetails will be accurate. Again, not a big deal either way, but wanted to mention it test/jdk/java/util/zip/ZipInputStream/ZipInputStreamCRCCheck.java line 99: > 97: final ZipEntry entry = zis.getNextEntry(); > 98: assertEquals(entryName, entry.getName(), "unexpected entry name"); > 99: try { I would consider changing this to something such as we did in open/test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java: ` ZipException ex = assertThrows(ZipException.class, () -> { readZipInputStream(invalidZip64); }); String msg = String.format("Expected exeption message to contain 'invalid entry size', was %s", ex.getMessage()); assertTrue(ex.getMessage().contains("invalid entry size"), msg); }` ------------- PR Review: https://git.openjdk.org/jdk/pull/25116#pullrequestreview-2825110440 PR Review Comment: https://git.openjdk.org/jdk/pull/25116#discussion_r2079701386 From lancea at openjdk.org Thu May 8 13:46:56 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 8 May 2025 13:46:56 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:29:36 GMT, Alan Bateman wrote: > > I'll run some experiments and see what it shows up. > > Thanks as that will help inform as to whether this will need a compatibility knob. The crc is calculated as part of the write of the entry and I have not seen any cases, where the CRC is not 0 for a directory/ 0-length file ------------- PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863124377 From duke at openjdk.org Thu May 8 13:49:54 2025 From: duke at openjdk.org (kabutz) Date: Thu, 8 May 2025 13:49:54 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com> References: <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com> Message-ID: On Thu, 8 May 2025 08:33:06 GMT, Viktor Klang wrote: > I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean? I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079757838 From duke at openjdk.org Thu May 8 13:55:54 2025 From: duke at openjdk.org (kabutz) Date: Thu, 8 May 2025 13:55:54 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Thu, 8 May 2025 08:41:52 GMT, Viktor Klang wrote: > We could likely check if there's any remaining capacity up front, and immediately return false? We could if you like. I wanted to make as few changes as possible, to not introduce unexpected changes. This particular bug was to stop a size overflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079769379 From alanb at openjdk.org Thu May 8 14:01:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 14:01:52 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Wed, 7 May 2025 19:05:17 GMT, Alan Bateman wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. > > Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system. > You might be correct. We'll see what @AlanBateman and others have to say about it. It's still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it helps us understand why it fails. As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL. There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2863176924 From duke at openjdk.org Thu May 8 14:30:57 2025 From: duke at openjdk.org (kabutz) Date: Thu, 8 May 2025 14:30:57 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Thu, 8 May 2025 08:59:59 GMT, Viktor Klang wrote: >> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR. >> >> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take >> >> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. >> >> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators >> >> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. >> >> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking. >> >> This can be fixed very easily by linking both f.prev and f.next back to f. >> >> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached >> >> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. >> >> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. >> >> 4. LinkedBlockingDeque allows us to overflow size with addAll() >> >> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst hol... > > src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 865: > >> 863: long n = 0; >> 864: for (E e : c) { >> 865: Objects.requireNonNull(e); > > This makes me wonder: Does it make sense to create new nodes if we don't track if they will still fit into the capacity? We could if you like, but that would subtly change the current behaviour. I tried to make as few changes as possible. > Out of curiosity, how does `it.remove()` work under these conditions? If we call it.remove() on the first element, it delegates to unlinkFirst() (if we are using an ascending iterator), and unlinkLast (if we are using a descending iterator). Similarly, if we call it.remove() on the last element it will call unlinkLast() or unlinkFirst(). With unlinkFirst(), it will make f.next = f (thus linking back to itself) and with unlinkLast(), it will make l.prev = l. If we call it.remove() on a middle element, then we simply link the p.next = n; n.prev = p; and does not do self-linking. Thus if we have an LBD with 1,2,3,4,5 with two iterators pointing onto 3, if one of them removes it, then the other will continue with 3 (cached), 4, 5, and it won't go back to the beginning and see duplicate elements. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079836006 PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079833797 From pminborg at openjdk.org Thu May 8 14:36:32 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 May 2025 14:36:32 GMT Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base` Message-ID: This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided. ------------- Commit messages: - Let ReverseOrderListView::reversed return base Changes: https://git.openjdk.org/jdk/pull/25120/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25120&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356486 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25120/head:pull/25120 PR: https://git.openjdk.org/jdk/pull/25120 From liach at openjdk.org Thu May 8 14:46:55 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 14:46:55 GMT Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base` In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote: > This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided. test/jdk/java/util/Collection/MOAT.java line 507: > 505: private static void testImmutableSeqColl(final SequencedCollection c, T t) { > 506: SequencedCollection r = c.reversed(); > 507: if (r instanceof List list && list.reversed() != c) { Shouldn't all double-reverse be identity? Why is this restricted to lists? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2079865444 From liach at openjdk.org Thu May 8 14:55:07 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 14:55:07 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v3] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Prefix touched methods with `unchecked` Reviewed missing copyright updates. Only files with comments need copyright year updates. Let's re-approve after copyright fix. src/java.base/share/classes/java/io/DataInputStream.java line 1: > 1: /* Copyright year src/java.base/share/classes/java/io/ObjectInputStream.java line 1: > 1: /* Copyright year src/java.base/share/classes/java/util/HexFormat.java line 1: > 1: /* Copyright year src/java.base/share/classes/java/util/zip/ZipCoder.java line 1: > 1: /* Copyright year src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 1: > 1: /* Copyright year src/java.base/share/classes/jdk/internal/util/HexDigits.java line 1: > 1: /* Copyright year src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1: > 1: /* Copyright year src/java.base/share/classes/sun/nio/cs/DoubleByte.java line 1: > 1: /* Copyright year src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 1: > 1: /* Copyright year src/java.base/share/classes/sun/nio/cs/SingleByte.java line 1: > 1: /* Copyright year src/java.base/share/classes/sun/nio/cs/US_ASCII.java line 1: > 1: /* Copyright year src/java.base/share/classes/sun/nio/cs/UTF_8.java line 1: > 1: /* Copyright year src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 1: > 1: /* Copyright year src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 1: > 1: /* Copyright year ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825397502 Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825413999 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079869063 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079869753 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079870851 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079871207 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079873366 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874098 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874388 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874760 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875143 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875444 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875789 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079876056 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079876669 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079877098 From lkorinth at openjdk.org Thu May 8 15:02:42 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 8 May 2025 15:02:42 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor Message-ID: This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. These fixes have been created when I have plown through testcases: JDK-8352719: Add an equals sign to the modules statement JDK-8352709: Remove bad timing annotations from WhileOpTest.java JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE CODETOOLS-7903961: Make default timeout configurable Sometime in the future I will also fix: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 for which I am awaiting: CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 *After the review I will revert the two first commits, and update the copyrights* ------------- Commit messages: - 8356171: Increase timeout for testcases as preparation for change of default timeout factor - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER - 8260555 Changes: https://git.openjdk.org/jdk/pull/25122/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356171 Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod Patch: https://git.openjdk.org/jdk/pull/25122.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122 PR: https://git.openjdk.org/jdk/pull/25122 From rgiulietti at openjdk.org Thu May 8 15:13:19 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 8 May 2025 15:13:19 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v3] In-Reply-To: References: Message-ID: > Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. > Further, add `unsignedMultiplyExact` methods as well. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Added tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25003/files - new: https://git.openjdk.org/jdk/pull/25003/files/2d3405f2..8c146e9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25003&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25003&range=01-02 Stats: 392 lines in 1 file changed: 392 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25003/head:pull/25003 PR: https://git.openjdk.org/jdk/pull/25003 From duke at openjdk.org Thu May 8 15:31:06 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 8 May 2025 15:31:06 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v10] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Thu, 8 May 2025 13:16:25 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add composition of functions and MHs test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 120: > 118: > 119: private static final ToIntFunction HASH_UPDATER = > 120: StableFieldUpdater.ofInt(LazyFoo.class, "hash", Very clean now. test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 183: > 181: static > 182: > 183: public final class MhFoo { I'm assuming this is explicitly the "behind the scenes" raw version of it in case anyone want's to step off the well-lit path. Hard to comment without seeing any surrounding docs. I don't suppose a link to the docs in which these are given can be added (just to give context for future maintainers)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2079941869 PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2079953010 From duke at openjdk.org Thu May 8 15:33:17 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 8 May 2025 15:33:17 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54] In-Reply-To: References: Message-ID: > This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24690/files - new: https://git.openjdk.org/jdk/pull/24690/files/009937b9..2e08f775 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=52-53 Stats: 21 lines in 2 files changed: 0 ins; 5 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24690.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690 PR: https://git.openjdk.org/jdk/pull/24690 From rgiulietti at openjdk.org Thu May 8 15:50:55 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 8 May 2025 15:50:55 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 15:33:17 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Suggested changes Please update the 2nd copyright year in `BigInteger`. Otherwise looks good. As soon as you as you feel comfortable with your changes, let me know so that I can approve. Thanks for yet another nice contribution! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863533055 From pchilanomate at openjdk.org Thu May 8 15:54:25 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 8 May 2025 15:54:25 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock Message-ID: Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/25119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346255 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25119/head:pull/25119 PR: https://git.openjdk.org/jdk/pull/25119 From jpai at openjdk.org Thu May 8 16:05:04 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 May 2025 16:05:04 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12] In-Reply-To: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> References: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> Message-ID: <8ntdUbcNZXlhpmPdasBRHkvBiJ_sytIXP144tDZ53JA=.95b23097-a3dd-43f7-986e-dcee4b2a6fb4@github.com> On Fri, 2 May 2025 15:17:25 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/ClassValue.java > > Co-authored-by: Shaojin Wen src/java.base/share/classes/java/lang/ClassValue.java line 241: > 239: } else { > 240: throw ex instanceof Error err ? err : new Error(ex); > 241: } Hello Chen, i think this if/else for exception type checks can instead just be replaced with an unconditional `throw ex`; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080019642 From smarks at openjdk.org Thu May 8 16:05:57 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 8 May 2025 16:05:57 GMT Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base` In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote: > This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided. I think there are already tests to ensure that list.reversed().reversed() returns the original list. See also https://github.com/openjdk/jdk/pull/24990 which adds some tests (but these are mostly about synchronized wrappers and propagation of RandomAccess). But we can assess the need for tests after 24990 is integrated. As I noted in the bug report ReverseOrderListView.reversed() really does end up returning base, but it does so in a roundabout fashion that could be cleaned up by adding the override as is done here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25120#issuecomment-2863573737 From stefank at openjdk.org Thu May 8 16:09:00 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 May 2025 16:09:00 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion. I made a cursory look through some GC files and I think that looked good. doc/testing.md line 385: > 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a > 384: certain amount of time will apply this factor. If we run in > 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) Maybe Suggestion: interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk) ------------- PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242 PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720 From liach at openjdk.org Thu May 8 16:09:00 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 16:09:00 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12] In-Reply-To: <8ntdUbcNZXlhpmPdasBRHkvBiJ_sytIXP144tDZ53JA=.95b23097-a3dd-43f7-986e-dcee4b2a6fb4@github.com> References: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> <8ntdUbcNZXlhpmPdasBRHkvBiJ_sytIXP144tDZ53JA=.95b23097-a3dd-43f7-986e-dcee4b2a6fb4@github.com> Message-ID: On Thu, 8 May 2025 16:01:51 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/ClassValue.java >> >> Co-authored-by: Shaojin Wen > > src/java.base/share/classes/java/lang/ClassValue.java line 241: > >> 239: } else { >> 240: throw ex instanceof Error err ? err : new Error(ex); >> 241: } > > Hello Chen, i think this if/else for exception type checks can instead just be replaced with an unconditional `throw ex`; I tried that and failed compilation before ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080032029 From smarks at openjdk.org Thu May 8 16:11:01 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 8 May 2025 16:11:01 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote: > This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. > > Unfortunately, this PR shows the total commit history for stable values. src/java.base/share/classes/java/util/ImmutableCollections.java line 954: > 952: return deepRoot(sub.root); > 953: } > 954: throw new InternalError("Should not reach here: " + list.getClass().getName()); Does this need to be recursive? There is logic to avoid nesting of sublists, and a sublist of a reversed view should end up being a reversed view of a sublist, so the most deep nesting that can occur is reversed(sublist(base)). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2080034660 From smarks at openjdk.org Thu May 8 16:15:54 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 8 May 2025 16:15:54 GMT Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base` In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote: > This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided. src/java.base/share/classes/java/util/ReverseOrderListView.java line 398: > 396: } > 397: > 398: @Override I don't use the Override annotation in collections. It can be useful for catching errors, but once the code is tested properly, having the annotation merely adds clutter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2080039319 From smarks at openjdk.org Thu May 8 16:15:56 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 8 May 2025 16:15:56 GMT Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base` In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:44:26 GMT, Chen Liang wrote: >> This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided. > > test/jdk/java/util/Collection/MOAT.java line 507: > >> 505: private static void testImmutableSeqColl(final SequencedCollection c, T t) { >> 506: SequencedCollection r = c.reversed(); >> 507: if (r instanceof List list && list.reversed() != c) { > > Shouldn't all double-reverse be identity? Why is this restricted to lists? This should already be covered by the testDoubleReverse() test in test/jdk/java/util/SequencedCollection/Basic.java. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2080043447 From jpai at openjdk.org Thu May 8 16:21:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 May 2025 16:21:56 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12] In-Reply-To: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> References: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> Message-ID: <4RbSYMakxOtOH_UBIhK1s2F_A03cf_tEOOq4MO8VOjc=.34548e69-dda1-4d8f-b378-2f7e70c374a1@github.com> On Fri, 2 May 2025 15:17:25 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/ClassValue.java > > Co-authored-by: Shaojin Wen src/java.base/share/classes/java/lang/ClassValue.java line 463: > 461: var updated = entry.refreshVersion(classValue.version); > 462: if (updated != entry) { > 463: put(classValue.identity, updated); This appears to associate a value and contradicts the `readAccess` method name and the comment on the method that says "A simple read access to this map". Did I misunderstand what `readAccess` is meant in the context of `ClassValue` semantics? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080052630 From dfuchs at openjdk.org Thu May 8 16:28:53 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 May 2025 16:28:53 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* @lkorinth have you run all the tiers where the old default timeout factor of 4 applied? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579 From jpai at openjdk.org Thu May 8 16:28:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 May 2025 16:28:55 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12] In-Reply-To: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> References: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> Message-ID: On Fri, 2 May 2025 15:17:25 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/ClassValue.java > > Co-authored-by: Shaojin Wen src/java.base/share/classes/java/lang/ClassValue.java line 222: > 220: } > 221: > 222: RemovalToken permission = (RemovalToken) accessed; // nullable This might be better if renamed to `removalToken` or just `token` instead of `permission`, in order to have a consistent terminology. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080064021 From duke at openjdk.org Thu May 8 16:44:55 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 8 May 2025 16:44:55 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Suggested changes > > Please update the 2nd copyright year in `BigInteger`. > > Otherwise looks good. > As soon as you feel comfortable with your changes, let me know so that I can approve. > > Thanks for yet another nice contribution! @rgiulietti Could be useful [this optimization](https://github.com/openjdk/jdk/pull/24690#issuecomment-2846711109) for `int` bases whose result does not fit in a `long`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863674473 From lkorinth at openjdk.org Thu May 8 16:45:56 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 8 May 2025 16:45:56 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Before this version, I had run tiers 1-8, with 11 fails. ** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700 ** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER ** DONE 03 tools/javac/util/IteratorsTest.java 480 ** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480 ** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER ** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER ** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480 ** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER ** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER ** DONE 10 java/foreign/TestMismatch.java 480 ** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER Six of those seems not related to my changes (marked `OTHER`), five I have updated for this run with new timeout. I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time. After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496 PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379 From liach at openjdk.org Thu May 8 16:46:00 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 16:46:00 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12] In-Reply-To: <4RbSYMakxOtOH_UBIhK1s2F_A03cf_tEOOq4MO8VOjc=.34548e69-dda1-4d8f-b378-2f7e70c374a1@github.com> References: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com> <4RbSYMakxOtOH_UBIhK1s2F_A03cf_tEOOq4MO8VOjc=.34548e69-dda1-4d8f-b378-2f7e70c374a1@github.com> Message-ID: On Thu, 8 May 2025 16:19:41 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/ClassValue.java >> >> Co-authored-by: Shaojin Wen > > src/java.base/share/classes/java/lang/ClassValue.java line 463: > >> 461: var updated = entry.refreshVersion(classValue.version); >> 462: if (updated != entry) { >> 463: put(classValue.identity, updated); > > This appears to associate a value and contradicts the `readAccess` method name and the comment on the method that says "A simple read access to this map". > > Did I misunderstand what `readAccess` is meant in the context of `ClassValue` semantics? Yep, this is unfortunately required for the cache mechanism - `refreshVersion` returns an equivalent entry, except its version is the latest, so the cache can trust this entry, if present in the cache array of a ClassValue, is up-to-date. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080089371 From duke at openjdk.org Thu May 8 16:48:40 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 8 May 2025 16:48:40 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55] In-Reply-To: References: Message-ID: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com> > This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Code simplification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24690/files - new: https://git.openjdk.org/jdk/pull/24690/files/2e08f775..261dd315 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=54 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=53-54 Stats: 39 lines in 1 file changed: 12 ins; 12 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/24690.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690 PR: https://git.openjdk.org/jdk/pull/24690 From erikj at openjdk.org Thu May 8 16:55:02 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 May 2025 16:55:02 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie 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' into go-full-utf8 > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2825782371 From lkorinth at openjdk.org Thu May 8 17:06:02 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 8 May 2025 17:06:02 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> References: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> Message-ID: On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson wrote: >> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). >> >> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have plown through testcases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> Sometime in the future I will also fix: >> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 >> >> for which I am awaiting: >> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 >> >> *After the review I will revert the two first commits, and update the copyrights* > > doc/testing.md line 385: > >> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a >> 384: certain amount of time will apply this factor. If we run in >> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) > > Maybe > Suggestion: > > interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk) Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016 From aph at openjdk.org Thu May 8 17:23:09 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 8 May 2025 17:23:09 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 12:48:08 GMT, Alan Bateman wrote: > @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this? Fixed now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863756144 From aph at openjdk.org Thu May 8 17:23:09 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 8 May 2025 17:23:09 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v5] In-Reply-To: References: Message-ID: > Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a null argument. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: ScopedValue::orElse() does not accept null as an argument. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24923/files - new: https://git.openjdk.org/jdk/pull/24923/files/8f626617..a80b034c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923 PR: https://git.openjdk.org/jdk/pull/24923 From aph at openjdk.org Thu May 8 17:29:08 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 8 May 2025 17:29:08 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v6] In-Reply-To: References: Message-ID: > Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a null argument. Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Fix merge - Merge from https://github.com/openjdk/jdk - ScopedValue::orElse() does not accept null as an argument. - Remove unnecessary @since 25 - Remove unnecessary @enablePreview in some tests - Since when? - ScopedValue::orElse() does not accept null as an argument. - 8355720: Implement JEP 506: Scoped Values - Implement JEP 506: Scoped Values ------------- Changes: https://git.openjdk.org/jdk/pull/24923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=05 Stats: 21 lines in 5 files changed: 3 ins; 11 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923 PR: https://git.openjdk.org/jdk/pull/24923 From aph at openjdk.org Thu May 8 17:33:09 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 8 May 2025 17:33:09 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: > Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a null argument. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Fix merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24923/files - new: https://git.openjdk.org/jdk/pull/24923/files/8354bcb5..7d354394 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923 PR: https://git.openjdk.org/jdk/pull/24923 From asemenyuk at openjdk.org Thu May 8 17:34:25 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 May 2025 17:34:25 GMT Subject: RFR: 8356562: SigningAppImageTwoStepsTest test fails Message-ID: Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). ------------- Commit messages: - Fix a bug in JPackageCommand.assertFileInAppImage() uncovered by running signing tests after JDK-8356219 fix. JDK-8356219 added a legit assert to JPackageCommand.assertFileInAppImage() and it failed. Changes: https://git.openjdk.org/jdk/pull/25126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356562 Stats: 13 lines in 1 file changed: 6 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25126/head:pull/25126 PR: https://git.openjdk.org/jdk/pull/25126 From asemenyuk at openjdk.org Thu May 8 17:34:25 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 May 2025 17:34:25 GMT Subject: RFR: 8356562: SigningAppImageTwoStepsTest test fails In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote: > Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/25126#issuecomment-2863779796 From dfuchs at openjdk.org Thu May 8 17:43:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 May 2025 17:43:54 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648 From duke at openjdk.org Thu May 8 17:43:31 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 8 May 2025 17:43:31 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman wrote: > > You might be correct. We'll see what @AlanBateman and others have to say about it. > > I'm still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it helps us understand why it fails. Yes, the mystery product is my code. :) It makes a JDK image with a tree of symlinks to a data directory. The regular files in the data directory do not have file extensions. > > As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL. I can see that removing the canonicalization could break the lock map. (Though I see the current deduplication and locking scheme doesn't handle hardlinks. Probably it would have to be keyed by `FileKey` to do that.) > There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix. I tried out this approach, and it solves my problem. I've now pushed the implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2863795234 From duke at openjdk.org Thu May 8 17:43:31 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 8 May 2025 17:43:31 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v2] In-Reply-To: References: Message-ID: <_4819zr4DrfeUquda3NCpnW7HQi5WjtofWHZT2Eoh1M=.f90ef3e4-bb86-4886-8241-b5943d71ee18@github.com> > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: new approach: append . to file name on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/46040f1f..f16626be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=00-01 Stats: 22 lines in 5 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From bpb at openjdk.org Thu May 8 17:49:58 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 May 2025 17:49:58 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v2] In-Reply-To: <_4819zr4DrfeUquda3NCpnW7HQi5WjtofWHZT2Eoh1M=.f90ef3e4-bb86-4886-8241-b5943d71ee18@github.com> References: <_4819zr4DrfeUquda3NCpnW7HQi5WjtofWHZT2Eoh1M=.f90ef3e4-bb86-4886-8241-b5943d71ee18@github.com> Message-ID: <56SUxew3Qq8TIh7Vb3O-IXpqpUo3vRSI6JYWuKHABqs=.43ac5e5c-d450-445e-b8f3-23d825481e9f@github.com> On Thu, 8 May 2025 17:43:31 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: > > new approach: append . to file name on Windows src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java line 110: > 108: * Add a dot to the end of the library file name ultimately passed to > 109: * LoadLibrary. This prevents LoadLibrary from > 110: * automatically infering a .DLL extension. `infering` -> `inferring` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080181799 From duke at openjdk.org Thu May 8 17:49:59 2025 From: duke at openjdk.org (Petr Portnov | PROgrm_JARvis) Date: Thu, 8 May 2025 17:49:59 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix merge src/java.base/share/classes/java/lang/ScopedValue.java line 613: > 611: */ > 612: public T orElse(T other) { > 613: Objects.requireNonNull(other); Shouldn't the NPE be specified in the Javadoc? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2080181692 From naoto at openjdk.org Thu May 8 17:54:58 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 8 May 2025 17:54:58 GMT Subject: RFR: 8356221: Clarify Console.charset() method description In-Reply-To: References: Message-ID: On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote: > Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied. Thanks for the review, Brian ------------- PR Comment: https://git.openjdk.org/jdk/pull/25103#issuecomment-2863826743 From naoto at openjdk.org Thu May 8 17:54:58 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 8 May 2025 17:54:58 GMT Subject: Integrated: 8356221: Clarify Console.charset() method description In-Reply-To: References: Message-ID: On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote: > Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied. This pull request has now been integrated. Changeset: e4ecda2b Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/e4ecda2b2563fbdff96d82fbbed6c022e28a49da Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8356221: Clarify Console.charset() method description Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/25103 From duke at openjdk.org Thu May 8 17:55:36 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 8 May 2025 17:55:36 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: fix spelling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/f16626be..70e943c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From liach at openjdk.org Thu May 8 18:05:55 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 18:05:55 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:47:12 GMT, Petr Portnov | PROgrm_JARvis wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix merge > > src/java.base/share/classes/java/lang/ScopedValue.java line 613: > >> 611: */ >> 612: public T orElse(T other) { >> 613: Objects.requireNonNull(other); > > Shouldn't the NPE be specified in the Javadoc? In the class specification, right above the API notes: *

    Unless otherwise specified, passing a {@code null} argument to a method in this * class will cause a {@link NullPointerException} to be thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2080203356 From jlu at openjdk.org Thu May 8 18:07:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 8 May 2025 18:07:42 GMT Subject: RFR: 8352755: Misconceptions about j.text.DecimalFormat digits during parsing [v3] In-Reply-To: References: Message-ID: <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com> > Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed. > > There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well. > > Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as > 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing. > 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation. 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 five additional commits since the last revision: - CSR review - directed inheritDoc; make 'concrete subclass' wording normative - Merge branch 'master' into JDK-8352755-limit-clarifications - Merge branch 'master' into JDK-8352755-limit-clarifications - Naoto's review: apiN -> implN. Rewording of maxintdig callout - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24265/files - new: https://git.openjdk.org/jdk/pull/24265/files/5fc8f37f..183356b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24265&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24265&range=01-02 Stats: 347915 lines in 3714 files changed: 120818 ins; 211994 del; 15103 mod Patch: https://git.openjdk.org/jdk/pull/24265.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24265/head:pull/24265 PR: https://git.openjdk.org/jdk/pull/24265 From liach at openjdk.org Thu May 8 18:20:54 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 18:20:54 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix merge I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863891143 From liach at openjdk.org Thu May 8 18:23:54 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 18:23:54 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: <1r-gaHy_VBrhT8yIqt2UIJ6g87BHJUJOWsSsxMOzTyA=.97592f84-858c-4a18-a19c-2a04885fdef3@github.com> On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix merge Reviewed the Javadoc and specification updates and `@enablePreview` removals for the end of preview. These are all related tests that can have the directive removed, aside from the thread flock test I asked about. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2825991095 From rgiulietti at openjdk.org Thu May 8 18:24:58 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 8 May 2025 18:24:58 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Suggested changes > > Please update the 2nd copyright year in `BigInteger`. > > Otherwise looks good. > As soon as you feel comfortable with your changes, let me know so that I can approve. > > Thanks for yet another nice contribution! > @rgiulietti Could be useful [this optimization](https://github.com/openjdk/jdk/pull/24690#issuecomment-2846711109) for `int` bases whose result does not fit in a `long`? There are endless optimizations and fast paths that one could conceive, but at some point we must decide to stop and turn our attention to other aspects of the platform. I think we have reached the turning point for this great PR. Besides, the performance gains of yet another fast-path might be negligible in general usage, at the cost of another 50 lines or so of code that would probably only benefit very narrow use cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863897562 From duke at openjdk.org Thu May 8 18:33:57 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 8 May 2025 18:33:57 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti wrote: > Otherwise looks good. As soon as you feel comfortable with your changes, let me know so that I can approve. @rgiulietti For me, now the code is ready. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863923412 From rgiulietti at openjdk.org Thu May 8 18:38:58 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 8 May 2025 18:38:58 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55] In-Reply-To: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com> References: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com> Message-ID: On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Code simplification Good. Let's give another 24 hours for people around the globe to chime in for last minute comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863949199 From alanb at openjdk.org Thu May 8 18:40:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 18:40:55 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:18:44 GMT, Chen Liang wrote: > I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead? ThreadFlock supports the inheritance of scoped values into structured concurrency contexts. No changes in this PR to that construct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863955030 From bpb at openjdk.org Thu May 8 18:53:52 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 May 2025 18:53:52 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: <6EUJaRSx-tXXQRqe1Eve3K4bXRqy05rtH4iK0drXH90=.135e0acb-c0a6-42ef-8d7b-9447ae31e03b@github.com> On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: > > fix spelling I built the JDK with the diff in 70e943c applied on Windows 11 and verified that it resolves the scenario presented in the issue description, namely that `jimage.dll` can be moved elsewhere, in this case `C:\Users\bpb\rando`, and a link created from `jimage.dll` to `rando` and with this config `java` and `jshell` can be run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2863982556 From vromero at openjdk.org Thu May 8 18:57:54 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 May 2025 18:57:54 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:33:45 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - Merge branch 'master' into JDK-8354556 > - addressing review comment > - changes to test > - Merge branch 'master' into JDK-8354556 > - updating test > - final adjustments > - additional refactorings > - removing unneeded changes > - more refactorings > - more refactorings and tests > - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0 note to reviewers: I had an offline discussion with Dan, I will introduce some changes to the implementation ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2863994317 From alanb at openjdk.org Thu May 8 19:00:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 19:00:54 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:18:12 GMT, Andrew Haley wrote: >> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this? > >> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this? > > Fixed now. @theRealAph One other test that will need attention is runtime/ClassFile/ClassFileVersionTest.java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2864000920 From naoto at openjdk.org Thu May 8 19:01:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 8 May 2025 19:01:55 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie 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' into go-full-utf8 > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2826102855 From alanb at openjdk.org Thu May 8 19:02:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 19:02:53 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: > > fix spelling src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124: > 122: return null; > 123: } > 124: name = file.getCanonicalPath() + ClassLoaderHelper.nativeLoaderFileNameSuffix(); For this proposal then the appending needs to conditional. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080306580 From duke at openjdk.org Thu May 8 19:09:01 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 8 May 2025 19:09:01 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:00:26 GMT, Alan Bateman wrote: >> Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision: >> >> fix spelling > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124: > >> 122: return null; >> 123: } >> 124: name = file.getCanonicalPath() + ClassLoaderHelper.nativeLoaderFileNameSuffix(); > > For this proposal then the appending needs to conditional. Conditional on what? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080313366 From alanb at openjdk.org Thu May 8 19:16:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 19:16:53 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:05:56 GMT, Benjamin Peterson wrote: >> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124: >> >>> 122: return null; >>> 123: } >>> 124: name = file.getCanonicalPath() + ClassLoaderHelper.nativeLoaderFileNameSuffix(); >> >> For this proposal then the appending needs to conditional. > > Conditional on what? The appending of the "." is specific to the case where there isn't a .dll suffix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080323162 From alanb at openjdk.org Thu May 8 19:19:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 May 2025 19:19:51 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). > > I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). > > I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. > > Thanks, > Patricio test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99: > 97: System.out.println("Waiting for thread1 and thread2 to deadlock ..."); > 98: awaitBlocked(thread1, reached1); > 99: awaitBlocked(thread2, reached2); This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2080327776 From duke at openjdk.org Thu May 8 19:41:53 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Thu, 8 May 2025 19:41:53 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:13:46 GMT, Alan Bateman wrote: >> Conditional on what? > > The appending of the "." is specific to the case where there isn't a .dll suffix. `LoadLibrary` appears to happily load files with a `.dll` extension even if a trailing `.` is appended. So, special casing doesn't appear necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080359521 From pchilanomate at openjdk.org Thu May 8 19:52:17 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 8 May 2025 19:52:17 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: References: Message-ID: > Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). > > I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). > > I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Rename awaitBlocked to awaitTrueAndBlocked ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25119/files - new: https://git.openjdk.org/jdk/pull/25119/files/7c067865..c36728d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25119/head:pull/25119 PR: https://git.openjdk.org/jdk/pull/25119 From pchilanomate at openjdk.org Thu May 8 19:52:17 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 8 May 2025 19:52:17 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: References: Message-ID: <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com> On Thu, 8 May 2025 19:17:19 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename awaitBlocked to awaitTrueAndBlocked > > test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99: > >> 97: System.out.println("Waiting for thread1 and thread2 to deadlock ..."); >> 98: awaitBlocked(thread1, reached1); >> 99: awaitBlocked(thread2, reached2); > > This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. > > An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too. Yes, I actually had that in an initial version. Then I thought it was cleaner to just have all waiting logic in awaitBlocked so I changed it. I renamed `awaitBlocked` to `awaitTrueAndBlocked` for now. But let me know if you prefer the two volatile booleans instead. Also, we could remove the `CyclicBarrier` and have each thread poll the other?s thread flag now, but given this bug was found due to the barrier I left it as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2080371142 From liach at openjdk.org Thu May 8 19:53:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 19:53:53 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix merge May I provide a quick patch to use an alternative mechanism to test preview class file versions for that class instead of changing that in this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2864114798 From prr at openjdk.org Thu May 8 20:02:52 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 8 May 2025 20:02:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* test/jdk/java/awt/font/NumericShaper/MTTest.java - * @run main/timeout=300/othervm MTTest + * @run main/timeout=1200/othervm MTTest I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java So 300 was fine, and 1200 isn't needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534 From kevinw at openjdk.org Thu May 8 20:10:53 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 May 2025 20:10:53 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). >> >> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). >> >> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Rename awaitBlocked to awaitTrueAndBlocked Hi, looks good! (The flag is easier than trying to look at the name of the thing they are blocked on.) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2826251302 From naoto at openjdk.org Thu May 8 21:06:31 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 8 May 2025 21:06:31 GMT Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550 Message-ID: Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case. Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/25130/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25130&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356450 Stats: 10 lines in 1 file changed: 7 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25130/head:pull/25130 PR: https://git.openjdk.org/jdk/pull/25130 From darcy at openjdk.org Thu May 8 21:11:00 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 8 May 2025 21:11:00 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal Message-ID: Fix javadoc tags. ------------- Commit messages: - JDK-8356555: Incorrect use of {@link} in BigDecimal Changes: https://git.openjdk.org/jdk/pull/25131/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356555 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25131.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25131/head:pull/25131 PR: https://git.openjdk.org/jdk/pull/25131 From asemenyuk at openjdk.org Thu May 8 21:17:37 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 May 2025 21:17:37 GMT Subject: RFR: 8333568: Test that jpackage doesn't modify R/O files/directories In-Reply-To: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com> References: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com> Message-ID: On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote: > Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/25129#issuecomment-2864322876 From asemenyuk at openjdk.org Thu May 8 21:17:37 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 May 2025 21:17:37 GMT Subject: RFR: 8333568: Test that jpackage doesn't modify R/O files/directories Message-ID: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com> Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test. ------------- Commit messages: - Verify jpackage doesn't modify external directories passed to jpackage Changes: https://git.openjdk.org/jdk/pull/25129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333568 Stats: 190 lines in 2 files changed: 185 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25129/head:pull/25129 PR: https://git.openjdk.org/jdk/pull/25129 From vlivanov at openjdk.org Thu May 8 21:22:52 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 8 May 2025 21:22:52 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes [v2] In-Reply-To: References: Message-ID: <0oWJ3zW0ykhbon1An-cbaib2XDdv-qBJS23f0CZkxcg=.faf3d22c-c6a1-4dd3-802c-40fde0a07846@github.com> On Mon, 5 May 2025 23:50:31 GMT, Ioi Lam wrote: >> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). >> >> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues) >> >> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table. >> >> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Comments from @liach and @ExE-Boss Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24956#pullrequestreview-2826395240 From iris at openjdk.org Thu May 8 21:23:52 2025 From: iris at openjdk.org (Iris Clark) Date: Thu, 8 May 2025 21:23:52 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal In-Reply-To: References: Message-ID: <2k9DA41pta5T-PEwj8lw5bl7Ux7OvIJ-6KUyCQ8k6TE=.3a042137-e6a1-4a6b-846b-ac65a3cf11ab@github.com> On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826397554 From bpb at openjdk.org Thu May 8 21:29:51 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 May 2025 21:29:51 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal In-Reply-To: References: Message-ID: On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826409763 From jlu at openjdk.org Thu May 8 21:37:53 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 8 May 2025 21:37:53 GMT Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550 In-Reply-To: References: Message-ID: On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case. > Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater. lgtm ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826420607 From bpb at openjdk.org Thu May 8 21:37:52 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 May 2025 21:37:52 GMT Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550 In-Reply-To: References: Message-ID: On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case. > Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater. Looks all right to me. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826417729 From jwaters at openjdk.org Thu May 8 21:43:02 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 8 May 2025 21:43:02 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v7] In-Reply-To: References: Message-ID: <3JOhI_-acxlyIreUPgbY5reRbuy4o0Rdh99q9JDgkfw=.0d792d1c-b156-46e2-aa80-3c07d3c183fe@github.com> On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into unused > - Neater warning silencer in proc_md.h > - Revert _WIN32 workaround in log_messages.c > - Copyright in VersionInfo.cpp > - Remove neutralLangId in VersionInfo.cpp > - Remove global memHandle, would've liked to keep it as a comment :( > - Merge branch 'master' into unused > - 8342682 Keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2864379663 From dholmes at openjdk.org Thu May 8 22:01:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 22:01:51 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). >> >> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). >> >> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Rename awaitBlocked to awaitTrueAndBlocked > we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). No, because that is an internal implementation detail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2864508184 From joehw at openjdk.org Thu May 8 22:05:52 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 8 May 2025 22:05:52 GMT Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550 In-Reply-To: References: Message-ID: On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case. > Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater. Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826461648 From almatvee at openjdk.org Thu May 8 22:08:52 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 8 May 2025 22:08:52 GMT Subject: RFR: 8356562: SigningAppImageTwoStepsTest test fails In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote: > Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25126#pullrequestreview-2826464922 From dholmes at openjdk.org Thu May 8 22:09:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 22:09:51 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). >> >> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). >> >> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Rename awaitBlocked to awaitTrueAndBlocked Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2826465546 From jwaters at openjdk.org Thu May 8 22:14:58 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 8 May 2025 22:14:58 GMT Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code. Thanks both for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24868#issuecomment-2864546595 From jwaters at openjdk.org Thu May 8 22:14:58 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 8 May 2025 22:14:58 GMT Subject: Integrated: 8355573: Remove kludge_c++11.h from jpackage code In-Reply-To: References: Message-ID: <4OHM8zzh2z1YR5YKktFQkwMt2EsMmXLBDvmhPmsZ7So=.984c015e-430a-476b-9a4e-731645e9a902@github.com> On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code. This pull request has now been integrated. Changeset: c2a4fa1d Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/c2a4fa1d83bd690e4e453eb1dbe59c6503b5281d Stats: 183 lines in 8 files changed: 1 ins; 182 del; 0 mod 8355573: Remove kludge_c++11.h from jpackage code Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/24868 From asemenyuk at openjdk.org Thu May 8 22:21:57 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 May 2025 22:21:57 GMT Subject: Integrated: 8356562: SigningAppImageTwoStepsTest test fails In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote: > Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). This pull request has now been integrated. Changeset: 8a8893ec Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/8a8893ec030b19583efd65bd0751e66254689ead Stats: 13 lines in 1 file changed: 6 ins; 4 del; 3 mod 8356562: SigningAppImageTwoStepsTest test fails Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/25126 From almatvee at openjdk.org Thu May 8 22:39:50 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 8 May 2025 22:39:50 GMT Subject: RFR: 8333568: Test that jpackage doesn't modify R/O files/directories In-Reply-To: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com> References: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com> Message-ID: <3fl9BqEDeRLc6T4fEfI1mV2gG2GbN5nNls975AQpx4Y=.2567c1bc-0850-4848-abd3-cb630e2320ef@github.com> On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote: > Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25129#pullrequestreview-2826499148 From jlu at openjdk.org Thu May 8 23:00:26 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 8 May 2025 23:00:26 GMT Subject: RFR: 8348351: Improve lazy initialization of the available currencies set Message-ID: Please review this PR which stems from discussion in the PR of JDK-8347949. The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.) ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/25134/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348351 Stats: 46 lines in 1 file changed: 3 ins; 2 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/25134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25134/head:pull/25134 PR: https://git.openjdk.org/jdk/pull/25134 From liach at openjdk.org Thu May 8 23:10:52 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 23:10:52 GMT Subject: RFR: 8348351: Improve lazy initialization of the available currencies set In-Reply-To: References: Message-ID: On Thu, 8 May 2025 22:55:34 GMT, Justin Lu wrote: > Please review this PR which stems from discussion in the PR of JDK-8347949. > > The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. > > (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.) src/java.base/share/classes/java/util/Currency.java line 471: > 469: > 470: // Builds and returns the set of available Currencies > 471: private static HashSet getCurrencies() { I think we should rename this to `computeCurrencies` or `makeCurrencies` to indicate we are creating a new instance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25134#discussion_r2080606583 From lmesnik at openjdk.org Thu May 8 23:12:52 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 May 2025 23:12:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> Message-ID: On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth wrote: >> doc/testing.md line 385: >> >>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a >>> 384: certain amount of time will apply this factor. If we run in >>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) >> >> Maybe >> Suggestion: >> >> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk) > > Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk. yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853 From jlu at openjdk.org Thu May 8 23:30:06 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 8 May 2025 23:30:06 GMT Subject: RFR: 8348351: Improve lazy initialization of the available currencies set [v2] In-Reply-To: References: Message-ID: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com> > Please review this PR which stems from discussion in the PR of JDK-8347949. > > The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. > > (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.) Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Chen's review - method name clarification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25134/files - new: https://git.openjdk.org/jdk/pull/25134/files/f9e9c6b2..e2672ba1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25134&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25134&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25134/head:pull/25134 PR: https://git.openjdk.org/jdk/pull/25134 From liach at openjdk.org Thu May 8 23:30:06 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 23:30:06 GMT Subject: RFR: 8348351: Improve lazy initialization of the available currencies set [v2] In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com> References: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com> Message-ID: <8fE6Y01KMk7bPnaE1KLFGMagSIZYdykjOMQdWsdk-X8=.8f190772-2f47-4a72-95eb-177c111d0799@github.com> On Thu, 8 May 2025 23:26:57 GMT, Justin Lu wrote: >> Please review this PR which stems from discussion in the PR of JDK-8347949. >> >> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. >> >> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.) > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Chen's review - method name clarification Looks great to me. Thanks! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25134#pullrequestreview-2826594504 From jlu at openjdk.org Thu May 8 23:30:06 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 8 May 2025 23:30:06 GMT Subject: RFR: 8348351: Improve lazy initialization of the available currencies set [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 23:08:27 GMT, Chen Liang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Chen's review - method name clarification > > src/java.base/share/classes/java/util/Currency.java line 471: > >> 469: >> 470: // Builds and returns the set of available Currencies >> 471: private static HashSet getCurrencies() { > > I think we should rename this to `computeCurrencies` or `makeCurrencies` to indicate we are creating a new instance. Definitely; updated in https://github.com/openjdk/jdk/pull/25134/commits/e2672ba1846c17b723d6bcbee0ef20488c0dca24. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25134#discussion_r2080621783 From naoto at openjdk.org Thu May 8 23:38:50 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 8 May 2025 23:38:50 GMT Subject: RFR: 8348351: Improve lazy initialization of the available currencies set [v2] In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com> References: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com> Message-ID: <3Lj7qiOyPZvgDYuu8-O2INL8jaNVuTzRDbKxf3lhqeg=.71db798a-2fee-45c1-9ca2-639061127015@github.com> On Thu, 8 May 2025 23:30:06 GMT, Justin Lu wrote: >> Please review this PR which stems from discussion in the PR of JDK-8347949. >> >> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. >> >> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.) > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Chen's review - method name clarification LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25134#pullrequestreview-2826610413 From nbenalla at openjdk.org Fri May 9 00:08:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 9 May 2025 00:08:51 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal In-Reply-To: References: Message-ID: On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. I think this looks good. ------------- Marked as reviewed by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826639744 From asemenyuk at openjdk.org Fri May 9 00:08:56 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 May 2025 00:08:56 GMT Subject: Integrated: 8333568: Test that jpackage doesn't modify R/O files/directories In-Reply-To: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com> References: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com> Message-ID: On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote: > Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test. This pull request has now been integrated. Changeset: cc3a366e Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/cc3a366e2a616226b776f683dbfb7cddaf2270d3 Stats: 190 lines in 2 files changed: 185 ins; 1 del; 4 mod 8333568: Test that jpackage doesn't modify R/O files/directories Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/25129 From almatvee at openjdk.org Fri May 9 00:13:51 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 May 2025 00:13:51 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v3] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 12:26:54 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8352480: [macos] Don't follow symlinks in additional content for app images [v5] > > test/jdk/tools/jpackage/share/AppContentTest.java line 116: > >> 114: private static Path getAppContentPath(JPackageCommand cmd, Path name) { >> 115: Path contentDir = cmd.appLayout().contentDirectory(); >> 116: // Links are always created in "Resources" > >> Links are always created in "Resources" > > All additional content on macOS is created in the "Resources" directory. On Linux there is no such requirement. > > The return value of `getAppContentPath()` is not supposed to depend on the additional content type; the new "name" parameter doesn't make sense to me. For links we creating link and corresponding text file, so for it we should put both files into folder and add it to `--app-content app-content-0/Resources`. Note `app-content-0` is temp folder with random name and if we using it directly we end up copying `app-content-0` into application bundle. In such case it will not be possible to figure out location of link without putting it under known folder name such as "Resources". "name" is to figure out if it link and if link it should be under "Resources". > test/jdk/tools/jpackage/share/AppContentTest.java line 147: > >> 145: >> 146: private static Path copyAppContentPath(Path appContentPath) throws IOException { >> 147: Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources"); > > This is a redundant change Fixed. > test/jdk/tools/jpackage/share/AppContentTest.java line 149: > >> 147: Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources"); >> 148: var srcPath = TKit.TEST_SRC_ROOT.resolve(appContentPath); >> 149: Path dstPath = appContentArg.resolve(srcPath.getFileName()); > > This is a redundant change Fixed. > test/jdk/tools/jpackage/share/AppContentTest.java line 164: > >> 162: private static List initAppContentPaths(List appContentPaths) { >> 163: boolean copy = (copyInResources || appContentPaths.stream() >> 164: .anyMatch(s -> s.toString().contains("Link"))); > > `s.toString().contains("Link")` is a lousy way to detect if the path is a symlink. "s" can be an absolute path (to the local OpenJDK repo) that may have a "Link" substring in one of path components, like "/home/BLink/my-projects/open/test/jdk/tools/jpackage/non-existant". The test will fail, and we will have a very hard time figuring out the cause. I'd fix it by narrowing the scope from the full path to the filename; create a dedicated function for detecting if the given path is supposed to be a symlink instead of repeating `.toString().contains("Link")`: > > private static boolean isSymlinkPath(Path v) { > return v.getFileName().toString().contains("Link"); > } Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659287 PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659397 PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659613 PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659694 From rriggs at openjdk.org Fri May 9 00:20:19 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 May 2025 00:20:19 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v7] In-Reply-To: References: Message-ID: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add an assert to inflateToUTF16 method Add doc of preconditions to appendChars... methods Correct misc javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/efd6fed1..1404fa9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=05-06 Stats: 15 lines in 1 file changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From lmesnik at openjdk.org Fri May 9 00:55:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 May 2025 00:55:54 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com> On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth wrote: >> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). >> >> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have plown through testcases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> Sometime in the future I will also fix: >> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 >> >> for which I am awaiting: >> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 >> >> *After the review I will revert the two first commits, and update the copyrights* > > After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again. @lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990 From almatvee at openjdk.org Fri May 9 01:39:07 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 May 2025 01:39:07 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v4] In-Reply-To: References: Message-ID: > - Symbolic links will not be followed for `--app-content` on all platforms. > - Added test to cover this case. > - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8352480: [macos] Don't follow symlinks in additional content for app images [v6] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24974/files - new: https://git.openjdk.org/jdk/pull/24974/files/166c3ffa..5c8dc6d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=02-03 Stats: 56 lines in 1 file changed: 23 ins; 2 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/24974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24974/head:pull/24974 PR: https://git.openjdk.org/jdk/pull/24974 From almatvee at openjdk.org Fri May 9 01:40:50 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 May 2025 01:40:50 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v3] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev wrote: >> - Symbolic links will not be followed for `--app-content` on all platforms. >> - Added test to cover this case. >> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8352480: [macos] Don't follow symlinks in additional content for app images [v5] 8352480: [macos] Don't follow symlinks in additional content for app images [v6] - Fixed latest comments. - Link will be created under "Links" folder to avoid confusion with reusing "Resources" - Link creation moved under separate function `createAppContentLink` from `copyAppContentPath` to avoid confusion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24974#issuecomment-2864851703 From asemenyuk at openjdk.org Fri May 9 01:56:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 May 2025 01:56:52 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v4] In-Reply-To: References: Message-ID: <6xerWH9jtlW78EFeGGELdg66ZseR6xMQq7H0j0NFmL0=.8c2b0f90-0f62-43bf-b063-b8256ecee014@github.com> On Fri, 9 May 2025 01:39:07 GMT, Alexander Matveev wrote: >> - Symbolic links will not be followed for `--app-content` on all platforms. >> - Added test to cover this case. >> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8352480: [macos] Don't follow symlinks in additional content for app images [v6] Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24974#pullrequestreview-2826761214 From asemenyuk at openjdk.org Fri May 9 01:56:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 May 2025 01:56:52 GMT Subject: RFR: 8352480: Don't follow symlinks in additional content for app images [v3] In-Reply-To: References: Message-ID: <-XJNPKRmCHHRZnGdNEFKmOwDptTvMjO24F0jXMGMl1I=.62c2f09e-ee47-4fdb-b636-951a340618fa@github.com> On Fri, 9 May 2025 00:10:34 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/share/AppContentTest.java line 116: >> >>> 114: private static Path getAppContentPath(JPackageCommand cmd, Path name) { >>> 115: Path contentDir = cmd.appLayout().contentDirectory(); >>> 116: // Links are always created in "Resources" >> >>> Links are always created in "Resources" >> >> All additional content on macOS is created in the "Resources" directory. On Linux there is no such requirement. >> >> The return value of `getAppContentPath()` is not supposed to depend on the additional content type; the new "name" parameter doesn't make sense to me. > > For links we creating link and corresponding text file, so for it we should put both files into folder and add it to `--app-content app-content-0/Resources`. Note `app-content-0` is temp folder with random name and if we using it directly we end up copying `app-content-0` into application bundle. In such case it will not be possible to figure out location of link without putting it under known folder name such as "Resources". > > "name" is to figure out if it link and if link it should be under "Resources". I can see you reverted the `getAppContentPath()` back. I guess it happened after your comment :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080753720 From dholmes at openjdk.org Fri May 9 02:08:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 02:08:58 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:18:07 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Update release date > - Update --release 25 symbol information for JDK 25 build 21 > The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > > # Conflicts: > # test/langtools/tools/javac/versions/Versions.java > - feedback: never bump ASM version > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/... Hotspot source and test changes look trivially good. ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2826771967 From dholmes at openjdk.org Fri May 9 02:47:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 02:47:53 GMT Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote: > Hopefully David will remember more of this when he gets back. Sadly I have to page in all the details again like everyone else. The underlying issue is nested-parking as Alan notes. From re-reading 8074773, pre-loading in any class loaded by the boot loader, has no affect on the bug. The issue was the action taken by the AppLoader that involved creating an entry in the lockMap CHM. That particular bug-path was closed when CHM was rewritten to use object monitors (did it re-open again when Loom came along?). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2864931853 From iklam at openjdk.org Fri May 9 03:10:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 03:10:41 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes [v3] In-Reply-To: References: Message-ID: > This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). > > AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues) > > In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table. > > I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase. Ioi Lam 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 branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes - Comments from @liach and @ExE-Boss - Added more test case to increase coverage on possible core-lib usage patterns for MethodHandles - Merge branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes - 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes - @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled() - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup() - @DanHeidinga comments - @fisk comment - ... and 10 more: https://git.openjdk.org/jdk/compare/9a0e6f33...0571ddc3 ------------- Changes: https://git.openjdk.org/jdk/pull/24956/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24956&range=02 Stats: 181 lines in 8 files changed: 169 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24956/head:pull/24956 PR: https://git.openjdk.org/jdk/pull/24956 From dholmes at openjdk.org Fri May 9 04:57:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 04:57:50 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in. ** though another option would be to update the jtreg default timeout instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247 From alanb at openjdk.org Fri May 9 05:56:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 05:56:51 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:51:12 GMT, Chen Liang wrote: > May I provide a quick patch to use an alternative mechanism to test preview class file versions for that class instead of changing that in this PR? That would be good as it shouldn't depend on ScopedValue being a preview API class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865223857 From iklam at openjdk.org Fri May 9 06:03:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 06:03:02 GMT Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 23:50:41 GMT, Chen Liang wrote: >> Ioi Lam 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 branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes >> - Comments from @liach and @ExE-Boss >> - Added more test case to increase coverage on possible core-lib usage patterns for MethodHandles >> - Merge branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes >> - 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes >> - @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled() >> - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache >> - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup() >> - @DanHeidinga comments >> - @fisk comment >> - ... and 10 more: https://git.openjdk.org/jdk/compare/9a0e6f33...0571ddc3 > > The Java code change and the BSM coverage looks good to me. Requiring another reviewer for hotspot changes. Thanks @liach @iwanowww for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24956#issuecomment-2865231404 From iklam at openjdk.org Fri May 9 06:03:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 06:03:02 GMT Subject: Integrated: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam wrote: > This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). > > AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues) > > In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table. > > I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase. This pull request has now been integrated. Changeset: 591e71eb Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/591e71ebe501e6e88249f46efda4134277f29b08 Stats: 181 lines in 8 files changed: 169 ins; 5 del; 7 mod 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes Reviewed-by: liach, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/24956 From pminborg at openjdk.org Fri May 9 06:27:54 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 May 2025 06:27:54 GMT Subject: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` In-Reply-To: References: Message-ID: On Thu, 8 May 2025 16:13:19 GMT, Stuart Marks wrote: >> test/jdk/java/util/Collection/MOAT.java line 507: >> >>> 505: private static void testImmutableSeqColl(final SequencedCollection c, T t) { >>> 506: SequencedCollection r = c.reversed(); >>> 507: if (r instanceof List list && list.reversed() != c) { >> >> Shouldn't all double-reverse be identity? Why is this restricted to lists? > > This should already be covered by the testDoubleReverse() test in test/jdk/java/util/SequencedCollection/Basic.java. There are some new collections (such as StableList) that are not covered in Basic. But maybe they should have their separate tests? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2081013384 From alanb at openjdk.org Fri May 9 06:34:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 06:34:51 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: References: Message-ID: <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com> On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). >> >> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). >> >> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Rename awaitBlocked to awaitTrueAndBlocked Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2827165376 From alanb at openjdk.org Fri May 9 06:34:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 06:34:52 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com> References: <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com> Message-ID: On Thu, 8 May 2025 19:49:05 GMT, Patricio Chilano Mateo wrote: >> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99: >> >>> 97: System.out.println("Waiting for thread1 and thread2 to deadlock ..."); >>> 98: awaitBlocked(thread1, reached1); >>> 99: awaitBlocked(thread2, reached2); >> >> This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. >> >> An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too. > > Yes, I actually had that in an initial version. Then I thought it was cleaner to just have all waiting logic in awaitBlocked so I changed it. I renamed `awaitBlocked` to `awaitTrueAndBlocked` for now. But let me know if you prefer the two volatile booleans instead. > > Also, we could remove the `CyclicBarrier` and have each thread poll the other?s thread flag now, but given this bug was found due to the barrier I left it as is. Okay, I think what you have is good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2081022353 From alanb at openjdk.org Fri May 9 06:40:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 06:40:00 GMT Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class In-Reply-To: References: Message-ID: On Fri, 9 May 2025 02:45:16 GMT, David Holmes wrote: > The underlying issue is nested-parking as Alan notes. From re-reading 8074773, pre-loading in any class loaded by the boot loader, has no affect on the bug. The issue was the action taken by the AppLoader that involved creating an entry in the lockMap CHM. That particular bug-path was closed when CHM was rewritten to use object monitors (did it re-open again when Loom came along?). No, it will still uses synchronized if there is contention and this will not consume the park permit when it's a virtual thread. Im not sure if Heinz ran into an issue, or just remember the issue from 2015, Heinz? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2865320135 From david.holmes at oracle.com Fri May 9 06:44:43 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 May 2025 16:44:43 +1000 Subject: Runtime.exec and SIGPIPE + SIG_IGN In-Reply-To: References: Message-ID: Hi Thomas, On 29/04/2025 7:04 pm, Thomas St?fe wrote: > Hi, > > I would like to gauge opinions on whether the following scenario is a > bug to fix or whether to accept it as standard behavior. > > --- > > A customer has the following problem: > > - The JVM invokes a third-party JNI library that sets the signal > disposition of SIGPIPE to SIG_IGN (Boo! in this case, it is the FIPS > nspr library, which does this unconditionally.) > - The JVM then spawns child processes > - All child processes now ignore SIGPIPE, which leads to failures in > automation scripts > > I was surprised. I always assumed the signal disposition of all signals > would be reset to SIG_DFL when exec'ing. However, seems I was wrong when > it came to SIG_IGN. Posix documents for execve() states [1]: > > 1) " Signals set to the default action (SIG_DFL) in the calling process > image shall be set to the default action in the new process image." > > and > > 2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the > calling process image shall be set to be ignored by the new process image." > > and > > 3) "Signals set to be caught by the calling process image shall be set > to the default action in the new process image (see // > )." > > (2) and (3) are the interesting parts. (2) means that if the parent > process ignores SIGPIPE, child processes will also ignore SIGPIPE. (3) > means that if the parent process has a custom handler installed for > SIGPIPE, child processes will be started with SIG_DFL (default action) > for SIGPIPE. The default action for SIGPIPE is "terminate process". > > The libjvm handles SIGPIPE. We install our `javaSignalHandler`. We do > this to eat up and ignore SIGPIPE. That we "manually" ignore the signal > beside the point here - what counts is that we set a custom signal > handler for SIGPIPE. Therefore, on execve, we behave according to rule > (3) and start the child with SIG_DFL as SIGPIPE disposition. As it > should be. > > If third-party code sets the handler to SIG_IGN as in this example, > exeve will behave according to rule (2) and the child will start with > SIG_IGN as SIGPIPE disposition. > > The libjig can be used to workaround this scenario, but I wonder if that > is more of an accident. The libjsig.so will preserve the JVM's SIGPIPE > handler even if third-party code attempts to set it to SIG_IGN. That > means that exeve still behaves according to rule (2): sets child's > SIGPIPE disposition to SIG_DFL. > > ---- > > But I wonder whether this should not be considered a bug to fix > regardless of the jsig.so workaround? In jspawnhelper, we clean the > environment from various effects when exec'ing; among other things, we > reset the signal block mask for the process. The "ignore" state of > processes could be considered along the same line. We could reset all > signal handlers to SIG_DFL before execing the child. > > I know that this area is super-tricky and problems are notoriously > difficult to analyze; we should therefore be extremely careful not to > break downward compatibility. Still, what do people think? Should be fix > this in jspawnhelper? I think at most, the exec'ing code could restore the signals the VM has modified to their default disposition - which in practice would mean only those set to SIG_IGN would need to explicitly be changed, which in turn may mean only SIGPIPE is affected? Even so, a library/application that ignores SIGPIPE and exec's other processes which it expects also ignore SIGPIPE, would not be happy with such a change. In the customer scenario described maybe the simplest fix is to have them use libjsig. Cheers, David > > Thanks, Thomas > > (cc'ing Roger) > > [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html > From thomas.stuefe at gmail.com Fri May 9 07:02:13 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 9 May 2025 09:02:13 +0200 Subject: Runtime.exec and SIGPIPE + SIG_IGN In-Reply-To: References: Message-ID: Hi David, On Fri, May 9, 2025 at 8:44?AM David Holmes wrote: > Hi Thomas, > > On 29/04/2025 7:04 pm, Thomas St?fe wrote: > > Hi, > > > > I would like to gauge opinions on whether the following scenario is a > > bug to fix or whether to accept it as standard behavior. > > > > --- > > > > A customer has the following problem: > > > > - The JVM invokes a third-party JNI library that sets the signal > > disposition of SIGPIPE to SIG_IGN (Boo! in this case, it is the FIPS > > nspr library, which does this unconditionally.) > > - The JVM then spawns child processes > > - All child processes now ignore SIGPIPE, which leads to failures in > > automation scripts > > > > I was surprised. I always assumed the signal disposition of all signals > > would be reset to SIG_DFL when exec'ing. However, seems I was wrong when > > it came to SIG_IGN. Posix documents for execve() states [1]: > > > > 1) " Signals set to the default action (SIG_DFL) in the calling process > > image shall be set to the default action in the new process image." > > > > and > > > > 2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the > > calling process image shall be set to be ignored by the new process > image." > > > > and > > > > 3) "Signals set to be caught by the calling process image shall be set > > to the default action in the new process image (see // > > >)." > > > > (2) and (3) are the interesting parts. (2) means that if the parent > > process ignores SIGPIPE, child processes will also ignore SIGPIPE. (3) > > means that if the parent process has a custom handler installed for > > SIGPIPE, child processes will be started with SIG_DFL (default action) > > for SIGPIPE. The default action for SIGPIPE is "terminate process". > > > > The libjvm handles SIGPIPE. We install our `javaSignalHandler`. We do > > this to eat up and ignore SIGPIPE. That we "manually" ignore the signal > > beside the point here - what counts is that we set a custom signal > > handler for SIGPIPE. Therefore, on execve, we behave according to rule > > (3) and start the child with SIG_DFL as SIGPIPE disposition. As it > > should be. > > > > If third-party code sets the handler to SIG_IGN as in this example, > > exeve will behave according to rule (2) and the child will start with > > SIG_IGN as SIGPIPE disposition. > > > > The libjig can be used to workaround this scenario, but I wonder if that > > is more of an accident. The libjsig.so will preserve the JVM's SIGPIPE > > handler even if third-party code attempts to set it to SIG_IGN. That > > means that exeve still behaves according to rule (2): sets child's > > SIGPIPE disposition to SIG_DFL. > > > > ---- > > > > But I wonder whether this should not be considered a bug to fix > > regardless of the jsig.so workaround? In jspawnhelper, we clean the > > environment from various effects when exec'ing; among other things, we > > reset the signal block mask for the process. The "ignore" state of > > processes could be considered along the same line. We could reset all > > signal handlers to SIG_DFL before execing the child. > > > > I know that this area is super-tricky and problems are notoriously > > difficult to analyze; we should therefore be extremely careful not to > > break downward compatibility. Still, what do people think? Should be fix > > this in jspawnhelper? > > I think at most, the exec'ing code could restore the signals the VM has > modified to their default disposition - which in practice would mean > only those set to SIG_IGN would need to explicitly be changed, which in > turn may mean only SIGPIPE is affected? > Agreed, if I fix this in jspawnhelper, I fix it very conservatively for only this signal. > > Even so, a library/application that ignores SIGPIPE and exec's other > processes which it expects also ignore SIGPIPE, would not be happy with > such a change. > > The problem is that libjsig, albeit working, is clunky to use in practice and requires control of the environment the customer may not have. And there are no good solutions, since whatever decision one does it won't work for a portion of customers. The way it works now is broken for at least all accidental users of this FIPS library. They may not even know that they use this library. And it is inconsistent, since the behavior is different depending on whether the SIG_IGN had been set before or after VM creation. So, it differs for custom launchers e.g. that set up signal handling upfront before loading the libjvm. My guess would be that the behavior now bothers more customers than a reset to SIG_DFL for SIGPIPE would. Cheers, Thomas P.S. before doing any behavioral change, I plan to add good extensive tracing to jspawnhelper, in order to make it simple to analyze situations like this. In the customer scenario described maybe the simplest fix is to have > them use libjsig. > > Cheers, > David > > > > > Thanks, Thomas > > > > (cc'ing Roger) > > > > [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Fri May 9 07:05:56 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 May 2025 07:05:56 GMT Subject: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` In-Reply-To: References: Message-ID: On Fri, 9 May 2025 06:24:50 GMT, Per Minborg wrote: >> This should already be covered by the testDoubleReverse() test in test/jdk/java/util/SequencedCollection/Basic.java. > > There are some new collections (such as StableList) that are not covered in Basic. But maybe they should have their separate tests? `UnmodifiableSequencedCollection` double-reversed is not an identity function. But at least, it does not nest, as it returns a new USC with the underlying collection reversed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2081060529 From jpai at openjdk.org Fri May 9 07:07:38 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 9 May 2025 07:07:38 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with empty file data [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799? > > `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix. > > tier testing is currently in progress. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Lance's suggestion - use assertThrows() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25116/files - new: https://git.openjdk.org/jdk/pull/25116/files/b2c011d1..0aea22fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=00-01 Stats: 14 lines in 1 file changed: 2 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25116.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25116/head:pull/25116 PR: https://git.openjdk.org/jdk/pull/25116 From dfuchs at openjdk.org Fri May 9 07:18:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 9 May 2025 07:18:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs wrote: > Thank you. I have imported your PR locally and running some HTTP client tests in the CI. > Tests have not finished running - but I already see one intermittent failure: > `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. > It would be good to flush out any such intermittent failures before this PR is integrated. > This might require multiple runs before we can get confidence. Results came back - another intermittent timeout failure (much more frequent) observed in: `java/net/httpclient/CancelledResponse.java` on macOS x64 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003 From cstein at openjdk.org Fri May 9 07:36:51 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 9 May 2025 07:36:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Fri, 9 May 2025 04:54:52 GMT, David Holmes wrote: > [...] > ** though another option would be to update the jtreg default timeout instead. And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908 From xgong at openjdk.org Fri May 9 07:44:27 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 9 May 2025 07:44:27 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API Message-ID: JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). Two key areas require improvement: 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. Main changes: 1. Java-side API refactoring: - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on architectures like AArch64. 2. C2 compiler IR refactoring: - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. 3. Backend changes: - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. Performance: The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: Benchmark Mode Cnt Unit SIZE Before After Gain GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.312 935.269 1.02 GatherOperationsBenchmark.microByteGather128_MASK thrpt 30 ops/ms 64 43040.148 44605.580 1.03 GatherOperationsBenchmark.microByteGather128_MASK thrpt 30 ops/ms 256 12445.650 12928.102 1.03 GatherOperationsBenchmark.microByteGather128_MASK thrpt 30 ops/ms 1024 3143.728 3294.173 1.04 GatherOperationsBenchmark.microByteGather128_MASK thrpt 30 ops/ms 4096 801.516 842.951 1.05 GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF thrpt 30 ops/ms 64 40379.343 45255.490 1.12 GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF thrpt 30 ops/ms 256 11103.537 12971.581 1.16 GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF thrpt 30 ops/ms 1024 2767.870 3299.453 1.19 GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF thrpt 30 ops/ms 4096 704.610 840.908 1.19 GatherOperationsBenchmark.microByteGather128_NZ_OFF thrpt 30 ops/ms 64 49066.340 53365.591 1.08 GatherOperationsBenchmark.microByteGather128_NZ_OFF thrpt 30 ops/ms 256 14063.326 14286.067 1.01 GatherOperationsBenchmark.microByteGather128_NZ_OFF thrpt 30 ops/ms 1024 3617.992 3621.272 1.00 GatherOperationsBenchmark.microByteGather128_NZ_OFF thrpt 30 ops/ms 4096 861.026 938.055 1.08 GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 64 55844.814 48311.847 0.86 GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 256 15139.459 13009.848 0.85 GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 1024 3861.834 3284.944 0.85 GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 4096 938.665 817.673 0.87 GatherOperationsBenchmark.microByteGather256_MASK thrpt 30 ops/ms 64 43942.924 43144.065 0.98 GatherOperationsBenchmark.microByteGather256_MASK thrpt 30 ops/ms 256 12461.170 11580.981 0.92 GatherOperationsBenchmark.microByteGather256_MASK thrpt 30 ops/ms 1024 3168.598 2945.698 0.92 GatherOperationsBenchmark.microByteGather256_MASK thrpt 30 ops/ms 4096 803.515 738.049 0.91 GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF thrpt 30 ops/ms 64 42197.440 43209.913 1.02 GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF thrpt 30 ops/ms 256 11456.761 11713.265 1.02 GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF thrpt 30 ops/ms 1024 2732.576 2949.724 1.07 GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF thrpt 30 ops/ms 4096 726.062 744.774 1.02 GatherOperationsBenchmark.microByteGather256_NZ_OFF thrpt 30 ops/ms 64 52915.781 49520.027 0.93 GatherOperationsBenchmark.microByteGather256_NZ_OFF thrpt 30 ops/ms 256 14481.921 13496.835 0.93 GatherOperationsBenchmark.microByteGather256_NZ_OFF thrpt 30 ops/ms 1024 3632.065 3362.372 0.92 GatherOperationsBenchmark.microByteGather256_NZ_OFF thrpt 30 ops/ms 4096 892.825 845.809 0.94 GatherOperationsBenchmark.microByteGather512 thrpt 30 ops/ms 64 54528.404 54478.751 0.99 GatherOperationsBenchmark.microByteGather512 thrpt 30 ops/ms 256 15018.181 14673.727 0.97 GatherOperationsBenchmark.microByteGather512 thrpt 30 ops/ms 1024 3824.690 3589.530 0.93 GatherOperationsBenchmark.microByteGather512 thrpt 30 ops/ms 4096 923.601 906.245 0.98 GatherOperationsBenchmark.microByteGather512_MASK thrpt 30 ops/ms 64 41248.192 42201.455 1.02 GatherOperationsBenchmark.microByteGather512_MASK thrpt 30 ops/ms 256 11481.408 11559.655 1.00 GatherOperationsBenchmark.microByteGather512_MASK thrpt 30 ops/ms 1024 2901.592 2912.954 1.00 GatherOperationsBenchmark.microByteGather512_MASK thrpt 30 ops/ms 4096 732.899 730.381 0.99 GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF thrpt 30 ops/ms 64 42287.123 43779.227 1.03 GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF thrpt 30 ops/ms 256 11486.167 11448.966 0.99 GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF thrpt 30 ops/ms 1024 2888.047 2928.612 1.01 GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF thrpt 30 ops/ms 4096 731.056 738.300 1.00 GatherOperationsBenchmark.microByteGather512_NZ_OFF thrpt 30 ops/ms 64 51777.670 54368.797 1.05 GatherOperationsBenchmark.microByteGather512_NZ_OFF thrpt 30 ops/ms 256 14558.532 14662.164 1.00 GatherOperationsBenchmark.microByteGather512_NZ_OFF thrpt 30 ops/ms 1024 3726.910 3714.448 0.99 GatherOperationsBenchmark.microByteGather512_NZ_OFF thrpt 30 ops/ms 4096 907.863 903.544 0.99 GatherOperationsBenchmark.microByteGather64 thrpt 30 ops/ms 64 52980.507 54970.689 1.03 GatherOperationsBenchmark.microByteGather64 thrpt 30 ops/ms 256 15044.443 15828.237 1.05 GatherOperationsBenchmark.microByteGather64 thrpt 30 ops/ms 1024 3869.028 4098.172 1.05 GatherOperationsBenchmark.microByteGather64 thrpt 30 ops/ms 4096 912.372 1002.065 1.09 GatherOperationsBenchmark.microByteGather64_MASK thrpt 30 ops/ms 64 44267.641 45864.381 1.03 GatherOperationsBenchmark.microByteGather64_MASK thrpt 30 ops/ms 256 12303.206 12920.113 1.05 GatherOperationsBenchmark.microByteGather64_MASK thrpt 30 ops/ms 1024 3100.867 3115.636 1.00 GatherOperationsBenchmark.microByteGather64_MASK thrpt 30 ops/ms 4096 792.004 832.623 1.05 GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF thrpt 30 ops/ms 64 40417.638 45844.634 1.13 GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF thrpt 30 ops/ms 256 11628.508 12913.170 1.11 GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF thrpt 30 ops/ms 1024 2911.508 3260.388 1.11 GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF thrpt 30 ops/ms 4096 709.017 835.084 1.17 GatherOperationsBenchmark.microByteGather64_NZ_OFF thrpt 30 ops/ms 64 48868.987 53585.210 1.09 GatherOperationsBenchmark.microByteGather64_NZ_OFF thrpt 30 ops/ms 256 13617.963 15754.029 1.15 GatherOperationsBenchmark.microByteGather64_NZ_OFF thrpt 30 ops/ms 1024 3504.745 3857.926 1.10 GatherOperationsBenchmark.microByteGather64_NZ_OFF thrpt 30 ops/ms 4096 818.439 958.751 1.17 GatherOperationsBenchmark.microShortGather128 thrpt 30 ops/ms 64 41351.719 44337.947 1.07 GatherOperationsBenchmark.microShortGather128 thrpt 30 ops/ms 256 11175.501 12302.557 1.10 GatherOperationsBenchmark.microShortGather128 thrpt 30 ops/ms 1024 2854.546 3158.973 1.10 GatherOperationsBenchmark.microShortGather128 thrpt 30 ops/ms 4096 744.816 790.304 1.06 GatherOperationsBenchmark.microShortGather128_MASK thrpt 30 ops/ms 64 35012.934 35728.068 1.02 GatherOperationsBenchmark.microShortGather128_MASK thrpt 30 ops/ms 256 9408.162 9854.849 1.04 GatherOperationsBenchmark.microShortGather128_MASK thrpt 30 ops/ms 1024 2352.723 2489.161 1.05 GatherOperationsBenchmark.microShortGather128_MASK thrpt 30 ops/ms 4096 595.827 634.225 1.06 GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt 30 ops/ms 64 31405.646 35728.077 1.13 GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt 30 ops/ms 256 8459.702 9865.482 1.16 GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt 30 ops/ms 1024 2095.461 2489.927 1.18 GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt 30 ops/ms 4096 535.715 631.614 1.17 GatherOperationsBenchmark.microShortGather128_NZ_OFF thrpt 30 ops/ms 64 39996.604 43811.259 1.09 GatherOperationsBenchmark.microShortGather128_NZ_OFF thrpt 30 ops/ms 256 11058.636 12261.463 1.10 GatherOperationsBenchmark.microShortGather128_NZ_OFF thrpt 30 ops/ms 1024 2847.482 3157.450 1.10 GatherOperationsBenchmark.microShortGather128_NZ_OFF thrpt 30 ops/ms 4096 712.089 790.143 1.10 GatherOperationsBenchmark.microShortGather256 thrpt 30 ops/ms 64 51893.730 51975.295 1.00 GatherOperationsBenchmark.microShortGather256 thrpt 30 ops/ms 256 14226.104 14720.390 1.03 GatherOperationsBenchmark.microShortGather256 thrpt 30 ops/ms 1024 3491.958 3714.266 1.06 GatherOperationsBenchmark.microShortGather256 thrpt 30 ops/ms 4096 852.278 905.330 1.06 GatherOperationsBenchmark.microShortGather256_MASK thrpt 30 ops/ms 64 38736.351 41797.516 1.07 GatherOperationsBenchmark.microShortGather256_MASK thrpt 30 ops/ms 256 10250.508 11790.235 1.15 GatherOperationsBenchmark.microShortGather256_MASK thrpt 30 ops/ms 1024 2558.449 2956.936 1.15 GatherOperationsBenchmark.microShortGather256_MASK thrpt 30 ops/ms 4096 648.882 745.885 1.14 GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt 30 ops/ms 64 38315.594 39547.847 1.03 GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt 30 ops/ms 256 10471.955 11779.499 1.12 GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt 30 ops/ms 1024 2618.623 2679.970 1.02 GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt 30 ops/ms 4096 655.803 760.392 1.15 GatherOperationsBenchmark.microShortGather256_NZ_OFF thrpt 30 ops/ms 64 47674.080 51325.185 1.07 GatherOperationsBenchmark.microShortGather256_NZ_OFF thrpt 30 ops/ms 256 13446.700 14438.516 1.07 GatherOperationsBenchmark.microShortGather256_NZ_OFF thrpt 30 ops/ms 1024 3371.433 3664.720 1.08 GatherOperationsBenchmark.microShortGather256_NZ_OFF thrpt 30 ops/ms 4096 814.540 895.182 1.09 GatherOperationsBenchmark.microShortGather512 thrpt 30 ops/ms 64 48183.553 48374.790 1.01 GatherOperationsBenchmark.microShortGather512 thrpt 30 ops/ms 256 13669.806 12940.433 0.94 GatherOperationsBenchmark.microShortGather512 thrpt 30 ops/ms 1024 3371.708 3318.627 0.98 GatherOperationsBenchmark.microShortGather512 thrpt 30 ops/ms 4096 847.620 805.313 0.95 GatherOperationsBenchmark.microShortGather512_MASK thrpt 30 ops/ms 64 39566.443 42845.296 1.08 GatherOperationsBenchmark.microShortGather512_MASK thrpt 30 ops/ms 256 11926.440 10308.223 0.86 GatherOperationsBenchmark.microShortGather512_MASK thrpt 30 ops/ms 1024 3008.542 2546.197 0.84 GatherOperationsBenchmark.microShortGather512_MASK thrpt 30 ops/ms 4096 764.497 647.276 0.84 GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt 30 ops/ms 64 38106.800 42835.120 1.12 GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt 30 ops/ms 256 10405.171 11125.164 1.06 GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt 30 ops/ms 1024 2526.827 2799.209 1.10 GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt 30 ops/ms 4096 655.044 715.519 1.09 GatherOperationsBenchmark.microShortGather512_NZ_OFF thrpt 30 ops/ms 64 48108.682 46654.427 0.96 GatherOperationsBenchmark.microShortGather512_NZ_OFF thrpt 30 ops/ms 256 13197.197 12957.497 0.98 GatherOperationsBenchmark.microShortGather512_NZ_OFF thrpt 30 ops/ms 1024 3397.959 3244.415 0.95 GatherOperationsBenchmark.microShortGather512_NZ_OFF thrpt 30 ops/ms 4096 824.034 820.536 0.99 GatherOperationsBenchmark.microShortGather64 thrpt 30 ops/ms 64 44815.622 46913.289 1.04 GatherOperationsBenchmark.microShortGather64 thrpt 30 ops/ms 256 12317.166 13536.731 1.09 GatherOperationsBenchmark.microShortGather64 thrpt 30 ops/ms 1024 3157.683 3539.991 1.12 GatherOperationsBenchmark.microShortGather64 thrpt 30 ops/ms 4096 775.626 878.304 1.13 GatherOperationsBenchmark.microShortGather64_MASK thrpt 30 ops/ms 64 37064.157 35649.776 0.96 GatherOperationsBenchmark.microShortGather64_MASK thrpt 30 ops/ms 256 10120.291 9403.1319 0.92 GatherOperationsBenchmark.microShortGather64_MASK thrpt 30 ops/ms 1024 2546.723 2642.781 1.03 GatherOperationsBenchmark.microShortGather64_MASK thrpt 30 ops/ms 4096 644.270 648.432 1.00 GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF thrpt 30 ops/ms 64 34386.819 37883.550 1.10 GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF thrpt 30 ops/ms 256 9316.097 10500.473 1.12 GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF thrpt 30 ops/ms 1024 2344.570 2643.114 1.12 GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF thrpt 30 ops/ms 4096 594.445 595.301 1.00 GatherOperationsBenchmark.microShortGather64_NZ_OFF thrpt 30 ops/ms 64 40240.772 48435.477 1.20 GatherOperationsBenchmark.microShortGather64_NZ_OFF thrpt 30 ops/ms 256 11082.392 13736.985 1.23 GatherOperationsBenchmark.microShortGather64_NZ_OFF thrpt 30 ops/ms 1024 2777.065 3549.704 1.27 GatherOperationsBenchmark.microShortGather64_NZ_OFF thrpt 30 ops/ms 4096 697.671 877.411 1.25 Note that this patch is splitted from https://github.com/openjdk/jdk/pull/24679. A follow-up PR will implement the SVE subword gather load operations after this PR is merged. [1] https://bugs.openjdk.org/browse/JDK-8318650 [2] https://developer.arm.com/documentation/ddi0602/2024-12/SVE-Instructions/LD1B--scalar-plus-vector---Gather-load-unsigned-bytes-to-vector--vector-index--?lang=en [3] https://developer.arm.com/documentation/ddi0602/2024-12/SVE-Instructions/LD1H--scalar-plus-vector---Gather-load-unsigned-halfwords-to-vector--vector-index--?lang=en ------------- Commit messages: - 8355563: VectorAPI: Refactor current implementation of subword gather load API Changes: https://git.openjdk.org/jdk/pull/25138/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355563 Stats: 441 lines in 15 files changed: 105 ins; 176 del; 160 mod Patch: https://git.openjdk.org/jdk/pull/25138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25138/head:pull/25138 PR: https://git.openjdk.org/jdk/pull/25138 From xgong at openjdk.org Fri May 9 07:44:27 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 9 May 2025 07:44:27 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong wrote: > JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). > > Two key areas require improvement: > 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. > 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. > > This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. > > Main changes: > 1. Java-side API refactoring: > - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on > architectures like AArch64. > 2. C2 compiler IR refactoring: > - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. > 3. Backend changes: > - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. > > Performance: > The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: > > Benchmark Mode Cnt Unit SIZE Before After Gain > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.312 935.269 1.02 > GatherOperationsBenchmark.micr... Hi @eme64 , could you please help take a look at this PR, which is a part of https://github.com/openjdk/jdk/pull/24679 ? Thanks a lot in advance! Hi @jatin-bhateja , could you please kindly review this PR, especially the X86 codegen part? Thanks a lot in advance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2865493287 PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2865495716 From pminborg at openjdk.org Fri May 9 07:50:29 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 May 2025 07:50:29 GMT Subject: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` [v2] In-Reply-To: References: Message-ID: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com> > This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Remove spurious class - Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25120/files - new: https://git.openjdk.org/jdk/pull/25120/files/546169f4..c21b9108 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25120&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25120&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25120/head:pull/25120 PR: https://git.openjdk.org/jdk/pull/25120 From alanb at openjdk.org Fri May 9 08:12:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 08:12:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth wrote: >> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). >> >> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have plown through testcases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> Sometime in the future I will also fix: >> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 >> >> for which I am awaiting: >> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 >> >> *After the review I will revert the two first commits, and update the copyrights* > > After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again. @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927 From aph at openjdk.org Fri May 9 08:28:00 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 9 May 2025 08:28:00 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:18:44 GMT, Chen Liang wrote: > I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead? > > Context: test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java That's an interesting question that I'll leave to @AlanBateman . ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865632535 From godmlzkf1 at naver.com Fri May 9 08:31:21 2025 From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=) Date: Fri, 09 May 2025 17:31:21 +0900 Subject: =?utf-8?B?VW5uZWNlc3NhcnkgbG9naWMgaXMgYWRkZWQgdG8gcmVtb3ZlRmlyc3QgYW5kIHJlbW92ZQ==?= =?utf-8?B?TGFzdCBvZiBBcnJheUxpc3Qu?= Message-ID: <7e491593f46d08db170661bf75f8f15@cweb006.nm> Hi. In removeFirst, if size is not 0, the logic is the same as the remove logic. removeLast also has the same logic as remove when size is not exceeded. I want to fix this. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyazici at openjdk.org Fri May 9 08:31:35 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 9 May 2025 08:31:35 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v4] In-Reply-To: References: Message-ID: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Fix copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24982/files - new: https://git.openjdk.org/jdk/pull/24982/files/4d237efa..121005ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=02-03 Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From vyazici at openjdk.org Fri May 9 08:31:38 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 9 May 2025 08:31:38 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:46:29 GMT, Chen Liang wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Prefix touched methods with `unchecked` > > src/java.base/share/classes/java/io/DataInputStream.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/java/io/ObjectInputStream.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/java/util/HexFormat.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/java/util/zip/ZipCoder.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/jdk/internal/util/HexDigits.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/sun/nio/cs/DoubleByte.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/sun/nio/cs/SingleByte.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/sun/nio/cs/US_ASCII.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/share/classes/sun/nio/cs/UTF_8.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. > src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 1: > >> 1: /* > > Copyright year Fixed in 121005eed50. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190069 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190301 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190552 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190701 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190811 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190928 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191033 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191280 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191511 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191686 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191903 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192125 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192310 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192487 From lkorinth at openjdk.org Fri May 9 08:32:55 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 08:32:55 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966 From alanb at openjdk.org Fri May 9 08:32:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 08:32:57 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 08:28:37 GMT, Alan Bateman wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix merge > >> I'm getting a test failure in [ClassFileVersionTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java#45) because `ScopedValue` is not a Preview API. Should I just fix the test to use some other Preview Class? > > Chen offered to change this test to use the ClassFile API and construct the class with the preview minor number. The PR to change this test is reviewed so I think all good, nothing more to do here. > That's an interesting question that I'll leave to @AlanBateman . Nothing to do as the test uses StructureViolationException so needs to continue to be compile/run with preview features enabled. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865643883 From alanb at openjdk.org Fri May 9 08:32:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 08:32:56 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix merge > I'm getting a test failure in [ClassFileVersionTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java#45) because `ScopedValue` is not a Preview API. Should I just fix the test to use some other Preview Class? Chen offered to change this test to use the ClassFile API and construct the class with the preview minor number. The PR to change this test is reviewed so I think all good, nothing more to do here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865640747 From vyazici at openjdk.org Fri May 9 08:33:58 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 9 May 2025 08:33:58 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:48 GMT, Chen Liang wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Prefix touched methods with `unchecked` > > Let's re-approve after copyright fix. @liach, @minborg, I've fixed the copyright years. I'd appreciate it if you can approve one last time. This last copyright year fiasco made me do this: alias git-license-year-violations='git diff --name-only upstream/master...HEAD | { y=$(date +%Y); while read f; do grep -qE "Copyright \(c\)( [0-9]{4},)? $y, Oracle" $f || echo $f; done; }' ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2865648371 From godmlzkf1 at naver.com Fri May 9 08:33:30 2025 From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=) Date: Fri, 09 May 2025 17:33:30 +0900 Subject: =?utf-8?B?VW5uZWNlc3NhcnkgbG9naWMgaXMgYWRkZWQgdG8gcmVtb3ZlRmlyc3QgYW5kIHJlbW92ZQ==?= =?utf-8?B?TGFzdCBvZiBBcnJheUxpc3Qu?= Message-ID: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm> Hi. In removeFirst, if size is not 0, the logic is the same as the remove logic. removeLast also has the same logic as remove when size is not exceeded. I want to fix this. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Fri May 9 08:38:39 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 May 2025 08:38:39 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v11] In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. 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 24 additional commits since the last revision: - Revert unintended change - Revert unintended change - Remove unused factories and add comment - Merge branch 'master' into stable-updaters - Add composition of functions and MHs - Revert changes in stable classes - Add lazy CallSite methods - Reformat - Add convenience methods and documentations - Add low level variants - ... and 14 more: https://git.openjdk.org/jdk/compare/6916dfd3...9a58db6a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25040/files - new: https://git.openjdk.org/jdk/pull/25040/files/1628b264..9a58db6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=09-10 Stats: 3102 lines in 128 files changed: 2035 ins; 528 del; 539 mod Patch: https://git.openjdk.org/jdk/pull/25040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040 PR: https://git.openjdk.org/jdk/pull/25040 From pminborg at openjdk.org Fri May 9 08:38:39 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 May 2025 08:38:39 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v10] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: <3Nb4WpG8VD6QdUuloCkv5v5MClYc-LU6PAbiZ_eOs54=.2c55b650-fe76-4494-bea9-706020015ccf@github.com> On Thu, 8 May 2025 15:28:20 GMT, David Beaumont wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add composition of functions and MHs > > test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 183: > >> 181: static >> 182: >> 183: public final class MhFoo { > > I'm assuming this is explicitly the "behind the scenes" raw version of it in case anyone want's to step off the well-lit path. Hard to comment without seeing any surrounding docs. I don't suppose a link to the docs in which these are given can be added (just to give context for future maintainers)? I have removed the unchecked factories now. I do not think we need them, and if we do, we could always add them back later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081205297 From lkorinth at openjdk.org Fri May 9 08:42:58 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 08:42:58 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs wrote: > Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence. My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066 From stefank at openjdk.org Fri May 9 08:48:51 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 May 2025 08:48:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote: > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration. Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701 From raffaello.giulietti at oracle.com Fri May 9 08:55:38 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Fri, 9 May 2025 10:55:38 +0200 Subject: Unnecessary logic is added to removeFirst and removeLast of ArrayList. In-Reply-To: <7e491593f46d08db170661bf75f8f15@cweb006.nm> References: <7e491593f46d08db170661bf75f8f15@cweb006.nm> Message-ID: Hi, when the size if not zero, the logic in removeFirst() avoids an index check, which however must be enforced in remove(int). There's no need for a "fix". On 2025-05-09 10:31, ??? wrote: > Hi. > > In removeFirst, if size is not 0, the logic is the same as the remove logic. > > removeLast also has the same logic as remove when size is not exceeded. > > I want to fix this. > > thank you. > From lkorinth at openjdk.org Fri May 9 09:02:55 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 09:02:55 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> On Thu, 8 May 2025 20:00:21 GMT, Phil Race wrote: > test/jdk/java/awt/font/NumericShaper/MTTest.java > > * * @run main/timeout=300/othervm MTTest > > > * * @run main/timeout=1200/othervm MTTest > > > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. > > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java > > So 300 was fine, and 1200 isn't needed. I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871 From ihse at openjdk.org Fri May 9 09:09:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 09:09:02 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie 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' into go-full-utf8 > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db It seems to be difficult to find someone to get this tested on a Chinese locale on Windows. I'll integrate this, and handle any problems that might arise as followups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2865761193 From ihse at openjdk.org Fri May 9 09:09:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 09:09:03 GMT Subject: Integrated: 8301971: Make JDK source code UTF-8 In-Reply-To: References: Message-ID: <1fDziF7qdWQ1gvZZ2pPh0MYEqRKAS0w3lPQbuYVUOa0=.f9283dc7-b8a0-4bfc-8dd5-4d124b225aa1@github.com> On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie wrote: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). This pull request has now been integrated. Changeset: 3aa2ea7e Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/3aa2ea7e67c879dafa0f967073c2d8b98d62c996 Stats: 177 lines in 13 files changed: 49 ins; 105 del; 23 mod 8301971: Make JDK source code UTF-8 8338973: Document need to have UTF-8 locale available to build the JDK Reviewed-by: erikj, naoto, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/24574 From lkorinth at openjdk.org Fri May 9 09:12:19 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 09:12:19 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> References: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com> On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth wrote: >> test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> - * @run main/timeout=300/othervm MTTest >> + * @run main/timeout=1200/othervm MTTest >> >> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. >> >> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> So 300 was fine, and 1200 isn't needed. > >> test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> * * @run main/timeout=300/othervm MTTest >> >> >> * * @run main/timeout=1200/othervm MTTest >> >> >> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. >> >> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> So 300 was fine, and 1200 isn't needed. > > I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough? > @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs. The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times? At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064 From alanb at openjdk.org Fri May 9 09:12:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 09:12:59 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:39:17 GMT, Benjamin Peterson wrote: >> The appending of the "." is specific to the case where there isn't a .dll suffix. > > `LoadLibrary` appears to happily load files with a `.dll` extension even if a trailing `.` is appended. So, special casing doesn't appear necessary. Is this documented in the Microsoft document for LoadLibrary? We don't want to rely on undocumented behavior as it could break at any time. For the prototype, I think you can replace nativeLoaderFileNameSuffix() with mapToNativeLibraryName(String) so that other platforms can "return this". This would give the flexibility to prefix or do other mangling. That said, I'm not so sure that we should changing the JDK to work in this unusual environment. Are you able to name the product that is move-renaming the DLLs and replacing them with sym links? Just trying to get some sense as to whether this is something that many people might run into it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2081271000 From cstein at openjdk.org Fri May 9 09:15:51 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 9 May 2025 09:15:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com> References: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com> Message-ID: On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth wrote: > At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork. Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769 From lkorinth at openjdk.org Fri May 9 09:15:52 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 09:15:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> References: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> Message-ID: On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson wrote: > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration. > > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1? I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195 From stefank at openjdk.org Fri May 9 09:19:51 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 May 2025 09:19:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> Message-ID: On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth wrote: > > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration. > > > > > > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1? > > I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert. I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474 From vklang at openjdk.org Fri May 9 09:23:56 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 9 May 2025 09:23:56 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v11] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Fri, 9 May 2025 08:38:39 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. > > 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 24 additional commits since the last revision: > > - Revert unintended change > - Revert unintended change > - Remove unused factories and add comment > - Merge branch 'master' into stable-updaters > - Add composition of functions and MHs > - Revert changes in stable classes > - Add lazy CallSite methods > - Reformat > - Add convenience methods and documentations > - Add low level variants > - ... and 14 more: https://git.openjdk.org/jdk/compare/a3634a30...9a58db6a src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 697: > 695: return f; > 696: } > 697: } Is there a specific reason not to use `Class::getDeclaredField(name)`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081288110 From pminborg at openjdk.org Fri May 9 09:34:00 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 May 2025 09:34:00 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values In-Reply-To: References: Message-ID: On Thu, 8 May 2025 16:08:24 GMT, Stuart Marks wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Unfortunately, this PR shows the total commit history for stable values. > > src/java.base/share/classes/java/util/ImmutableCollections.java line 954: > >> 952: return deepRoot(sub.root); >> 953: } >> 954: throw new InternalError("Should not reach here: " + list.getClass().getName()); > > Does this need to be recursive? There is logic to avoid nesting of sublists, and a sublist of a reversed view should end up being a reversed view of a sublist, so the most deep nesting that can occur is reversed(sublist(base)). Actually, this introduces a bug. If there is a reversed(sublist(base)) op, then the sublist is disregarded. So we need to remove this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081303938 From dfuchs at openjdk.org Fri May 9 09:33:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 9 May 2025 09:33:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote: > The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE) Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069 From duke at openjdk.org Fri May 9 09:40:54 2025 From: duke at openjdk.org (erifan) Date: Fri, 9 May 2025 09:40:54 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 02:10:56 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan 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: > > - Refactor code > > Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this > optimization, making the code more modular. > - Merge branch 'master' into JDK-8354242 > - Update the jtreg test > - Merge branch 'master' into JDK-8354242 > - Addressed some review comments > > 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. > 2. Improve code comments. > - Merge branch 'master' into JDK-8354242 > - Merge branch 'master' into JDK-8354242 > - 8354242: VectorAPI: combine vector not operation with compare > > This patch optimizes the following patterns: > For integer types: > ``` > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > ``` > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the > negative comparison of cond. > > For float and double types: > ``` > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > ``` > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: > With option `-XX:UseSVE=2`: > ``` > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4... I'll update the code next week, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2865870304 From duke at openjdk.org Fri May 9 09:40:55 2025 From: duke at openjdk.org (erifan) Date: Fri, 9 May 2025 09:40:55 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 01:49:45 GMT, Xiaohong Gong wrote: >> Yes, that's the right approach. For this PR, I think you can mix some test points covering compare, xor(maskAll(true)). > > Yes, converting `VectorMask.fromLong(SPECIES, -1L)` to `MaskAll()` would be better, and that will benefit AArch64 as well, since `MaskAll()` is much more cheaper than `fromLong()` on AArch64. We can add such a transformation with another PR. Ok, I'll extend the test to xor(maskAll(true) in the next commit, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2081313613 From duke at openjdk.org Fri May 9 09:49:56 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Fri, 9 May 2025 09:49:56 GMT Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v11] In-Reply-To: References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Fri, 9 May 2025 09:21:14 GMT, Viktor Klang 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 24 additional commits since the last revision: >> >> - Revert unintended change >> - Revert unintended change >> - Remove unused factories and add comment >> - Merge branch 'master' into stable-updaters >> - Add composition of functions and MHs >> - Revert changes in stable classes >> - Add lazy CallSite methods >> - Reformat >> - Add convenience methods and documentations >> - Add low level variants >> - ... and 14 more: https://git.openjdk.org/jdk/compare/b9531363...9a58db6a > > src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 697: > >> 695: return f; >> 696: } >> 697: } > > Is there a specific reason not to use `Class::getDeclaredField(name)`? Class::getDeclaredField(name) throws NoSuchFieldException if not found. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081336037 From ihse at openjdk.org Fri May 9 10:04:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 10:04:09 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v3] In-Reply-To: References: Message-ID: > As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them. > > 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? > > I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code. > > There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start. Magnus Ihse Bursie 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 unicode-sequence-in-comments - Merge branch 'master' into unicode-sequence-in-comments - 8354968: Replace unicode sequences in comment text with UTF-8 characters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24727/files - new: https://git.openjdk.org/jdk/pull/24727/files/694b33dc..dd9a77c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=01-02 Stats: 14771 lines in 491 files changed: 7892 ins; 4380 del; 2499 mod Patch: https://git.openjdk.org/jdk/pull/24727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727 PR: https://git.openjdk.org/jdk/pull/24727 From ihse at openjdk.org Fri May 9 10:12:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 10:12:09 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v4] In-Reply-To: References: Message-ID: > As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them. > > 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? > > I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code. > > There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Clarify non-ASCII characters with unicode code point ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24727/files - new: https://git.openjdk.org/jdk/pull/24727/files/dd9a77c5..53aa4066 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727 PR: https://git.openjdk.org/jdk/pull/24727 From ihse at openjdk.org Fri May 9 10:12:12 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 10:12:12 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v2] In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com> References: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com> Message-ID: On Tue, 6 May 2025 17:16:57 GMT, Naoto Sato wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into unicode-sequence-in-comments >> - 8354968: Replace unicode sequences in comment text with UTF-8 characters > > src/java.base/share/classes/java/text/RuleBasedCollator.java line 594: > >> 592: // a three-digit number, one digit for primary, one for secondary, etc. >> 593: // >> 594: // String: A a B ? > > Maybe "? (\u00e9, e-acute)"? I used the `U+` code point notation here as well. I think that is better to make sure there are no misunderstandings, and no risk of the escaped character inadvertently being converted into an actual unicode character down the line by processors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2081372676 From nbenalla at openjdk.org Fri May 9 10:34:52 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 9 May 2025 10:34:52 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal In-Reply-To: References: Message-ID: On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. I just noticed there are a couple more javadoc tags that need to be fixed in this class, I still see two more warnings. I should have included these in the JBS issue when filling it. src/java.base/share/classes/java/math/BigDecimal.java:363: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types) * The scale of this BigDecimal, as returned by {@link #scale}. ^ src/java.base/share/classes/java/math/BigDecimal.java:366: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types) * @see #scale ^ ``` ------------- Changes requested by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2827841653 From ihse at openjdk.org Fri May 9 10:47:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 10:47:53 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v4] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie wrote: >> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them. >> >> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? >> >> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code. >> >> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Clarify non-ASCII characters with unicode code point Now that [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971) is committed, this PR is ready to be integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24727#issuecomment-2866080024 From asemenyuk at openjdk.org Fri May 9 11:44:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 May 2025 11:44:55 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage Message-ID: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> Refactor jpackage to separate the configuration and execution phases. At the configuration phase, jpackage parses command-line arguments and validates them. At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. **Functional changes** jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. - Minimize copying of the source app image when doing native packaging. Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
    Script New Old
    preinstall
    #!/usr/bin/env sh
    if [ ! -d "/Applications/SimplePackageTest.app" ] then mkdir -p "/Applications/SimplePackageTest.app" fi
    exit 0
    #!/usr/bin/env sh
    if [ ! -d "/Applications" ] then mkdir -p "/Applications" fi
    exit 0
    postinstall
    #!/usr/bin/env sh
    chown root:wheel "/Applications/SimplePackageTest.app" chmod a+rX "/Applications/SimplePackageTest.app" chmod +r "/Applications/SimplePackageTest.app/Contents/app/"*.jar
    exit 0
    #!/usr/bin/env sh
    chown root:wheel "/Applications" chmod a+rX "/Applications" chmod +r "/Applications/SimplePackageTest.app/Contents/app/"*.jar
    exit 0
    This change relates to the [JDK-8356047](https://bugs.openjdk.org/browse/JDK-8356047) issue. Although the scripts are different, they are functionally identical (they don't change anything in the system). - PKG bundler: no "postinstall" and "preinstall" scripts in runtime bundles. jpackage will not create post- and pre- install scripts in runtime PKGs. This doesn't make a difference as runtime bundling on macOS is currently broken, see [JDK-8351073](https://bugs.openjdk.org/browse/JDK-8351073) issue. - macOS signing. Use `java.security.cert.X509Certificate` class to parse the signing certificates data instead of "/usr/bin/openssl" invocations. To identify the certificate unambiguously, the certificate's SHA1 hash is passed as a value of the "-s" parameter for codesign instead of the certificate name. **Testing** With these significant code changes, ensuring that jpackage still produces packages with the same properties for the given input was essential. jpackage uses external tools for building packages, supplying them with the configuration files. Assuming that a packaging tool would produce the same package for the given configuration files, these configuration files created by the "old" jpackage and the "new" jpackage in every jpackage test were examined and verified for no substantial differences. ConfigFilesStasher.java and clean_stashed_files.sh tools served this purpose. Thanks to this way to test jpackage, [JDK-8356219](https://bugs.openjdk.org/browse/JDK-8356219) was uncovered. ------------- Commit messages: - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh - Merge branch 'master' into JDK-8333664 - 8333568: Test that jpackage doesn't modify R/O files/directories - 8356562: SigningAppImageTwoStepsTest test fails - Remove clean_stashed_files.sh - OSVersionCondition: bugfix; CfgFile: minor; signing: fix entitlements - Merge branch 'master' into JDK-8333664 - Merge branch 'master' into JDK-8333664 - Fix FA tests - Add missing default jlink options - ... and 497 more: https://git.openjdk.org/jdk/compare/cc3a366e...9776f496 Changes: https://git.openjdk.org/jdk/pull/19668/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333664 Stats: 23913 lines in 194 files changed: 17144 ins; 5680 del; 1089 mod Patch: https://git.openjdk.org/jdk/pull/19668.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668 PR: https://git.openjdk.org/jdk/pull/19668 From asemenyuk at openjdk.org Fri May 9 11:44:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 May 2025 11:44:55 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> Message-ID: On Wed, 12 Jun 2024 01:37:19 GMT, Alexey Semenyuk wrote: > Refactor jpackage to separate the configuration and execution phases. > At the configuration phase, jpackage parses command-line arguments and validates them. > At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. > > There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. > > This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. > > The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". > > Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. > > **Functional changes** > jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. > > - Minimize copying of the source app image when doing native packaging. > > Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. > > - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. > > post- and pre- install PKG scripts for SimplePackageTest package before and after the change: > > > > > > > > > > > >
    ScriptNewOld
    preinstall >
    > #!/usr/bin/env sh
    > if [ ! -d "/Applications/SimplePackageTest.app" ] > the... keep the PR open keep it open @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2307257730 PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2563789218 PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2866228697 From pminborg at openjdk.org Fri May 9 12:10:38 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 May 2025 12:10:38 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v2] In-Reply-To: References: Message-ID: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com> > This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. > > Unfortunately, this PR shows the total commit history for stable values. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits: - Fix an issue with toString on nested constructs - Merge branch 'master' into jep502-followup - Merge branch 'master' into jep502-followup - Update src/java.base/share/classes/java/lang/StableValue.java Co-authored-by: Chen Liang - Simplify furhter - Address comments in PR - Merge master - Remove unused method and add comment - Address comments - Merge branch 'master' into jep502-followup - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504 ------------- Changes: https://git.openjdk.org/jdk/pull/25004/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=01 Stats: 361 lines in 13 files changed: 243 ins; 49 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/25004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004 PR: https://git.openjdk.org/jdk/pull/25004 From liach at openjdk.org Fri May 9 12:17:02 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 12:17:02 GMT Subject: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` [v2] In-Reply-To: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com> References: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com> Message-ID: On Fri, 9 May 2025 07:50:29 GMT, Per Minborg wrote: >> This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Remove spurious class > - Address comments lgtm ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25120#pullrequestreview-2828087371 From dholmes at openjdk.org Fri May 9 12:21:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 12:21:54 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com> On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479 From lkorinth at openjdk.org Fri May 9 12:51:52 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 12:51:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers. I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937. Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573 From lkorinth at openjdk.org Fri May 9 13:06:01 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 13:06:01 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Changing the timeout factor might be preferable to do after the fork. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008 From duke at openjdk.org Fri May 9 13:12:30 2025 From: duke at openjdk.org (Abhishek N) Date: Fri, 9 May 2025 13:12:30 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() Message-ID: Create a Test case to have special cases coverage for currency.getInstance(). The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API. test results: jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java Directory "JTwork" not found: creating Directory "JTreport" not found: creating Test results: passed: 1 Report written to JTreport\html\report.html Results written to JTwork ------------- Commit messages: - remove trailing space - remove carriage return from txt and properties file - Update ValidateCurrencyCoverage.java test code and add more date cut off to properties and txt file - Update ValidateCurrncyCoverage.java to cover all currencies and print result in end - Replaced carriage return with newline and removed duplicate currencyParam.properties file - 8355393: Create a Test case to have special cases coverage for currency.getInstance() Changes: https://git.openjdk.org/jdk/pull/25057/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25057&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355393 Stats: 262 lines in 3 files changed: 262 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25057/head:pull/25057 PR: https://git.openjdk.org/jdk/pull/25057 From mullan at openjdk.org Fri May 9 13:26:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 9 May 2025 13:26:53 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fine tuning debug log and exception message We should also update the comments and info string of `com/sun/crypto/provider/SunJCE.java` with the HKDF algorithms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24520#issuecomment-2866532132 From rgiulietti at openjdk.org Fri May 9 13:31:55 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 9 May 2025 13:31:55 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 00:20:19 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add an assert to inflateToUTF16 method > Add doc of preconditions to appendChars... methods > Correct misc javadoc src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 238: > 236: * {@return true if the byte array should be replaced due to increased capacity or coder change} > 237: *
      > 238: *
    • The new coder is the different than the old coder Suggestion: *
    • The new coder is different than the old coder src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1901: > 1899: } > 1900: return value; > 1901: } I think the logic can be simplified, without a need for the loop. private static byte[] putCharsAt(byte[] value, byte coder, int count, int index, char[] s, int off, int end) { if (isLatin1(coder)) { int latin1Len = StringUTF16.compress(s, off, value, index, end - off); if (latin1Len < end - off) { value = inflateToUTF16(value, count); StringUTF16.putCharsSB(value, index + latin1Len, s, off + latin1Len, end); } } else { StringUTF16.putCharsSB(value, index, s, off, end); } return value; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081686513 PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081689712 From aph at openjdk.org Fri May 9 14:16:06 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 9 May 2025 14:16:06 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory Message-ID: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). Benchmark (aligned) (size) Mode Cnt Score Error Units MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op ------------- Commit messages: - 8354674: AArch64: Intrinsify Unsafe::setMemory - New test - Cleanup - Fixes - next cut - First cut Changes: https://git.openjdk.org/jdk/pull/25147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354674 Stats: 99 lines in 2 files changed: 96 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From ihse at openjdk.org Fri May 9 14:20:31 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 14:20:31 GMT Subject: RFR: 8356644: Update encoding declaration to UTF-8 Message-ID: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper. I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8. ------------- Commit messages: - 8356644: Update encoding declaration to UTF-8 Changes: https://git.openjdk.org/jdk/pull/25148/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356644 Stats: 794 lines in 53 files changed: 2 ins; 9 del; 783 mod Patch: https://git.openjdk.org/jdk/pull/25148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25148/head:pull/25148 PR: https://git.openjdk.org/jdk/pull/25148 From aph at openjdk.org Fri May 9 14:25:50 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 9 May 2025 14:25:50 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Apple M1, small memory blocks: Benchmark (aligned) (size) Mode Cnt Score Error Units MemorySegmentFillUnsafe.panama true 1 avgt 10 1.731 ? 0.001 ns/op MemorySegmentFillUnsafe.panama true 2 avgt 10 1.570 ? 0.001 ns/op MemorySegmentFillUnsafe.panama true 3 avgt 10 1.583 ? 0.014 ns/op MemorySegmentFillUnsafe.panama true 4 avgt 10 1.734 ? 0.014 ns/op MemorySegmentFillUnsafe.panama true 5 avgt 10 1.736 ? 0.001 ns/op MemorySegmentFillUnsafe.panama true 6 avgt 10 1.731 ? 0.001 ns/op MemorySegmentFillUnsafe.panama true 7 avgt 10 1.744 ? 0.002 ns/op MemorySegmentFillUnsafe.panama true 8 avgt 10 2.365 ? 0.005 ns/op MemorySegmentFillUnsafe.panama true 15 avgt 10 2.681 ? 0.001 ns/op MemorySegmentFillUnsafe.panama true 16 avgt 10 2.503 ? 0.003 ns/op MemorySegmentFillUnsafe.panama true 63 avgt 10 3.615 ? 0.003 ns/op MemorySegmentFillUnsafe.panama true 64 avgt 10 4.701 ? 0.056 ns/op MemorySegmentFillUnsafe.panama true 255 avgt 10 4.848 ? 0.004 ns/op MemorySegmentFillUnsafe.panama true 256 avgt 10 5.003 ? 0.003 ns/op MemorySegmentFillUnsafe.panama false 1 avgt 10 1.729 ? 0.001 ns/op MemorySegmentFillUnsafe.panama false 2 avgt 10 1.571 ? 0.003 ns/op MemorySegmentFillUnsafe.panama false 3 avgt 10 1.579 ? 0.010 ns/op MemorySegmentFillUnsafe.panama false 4 avgt 10 1.728 ? 0.002 ns/op MemorySegmentFillUnsafe.panama false 5 avgt 10 1.739 ? 0.019 ns/op MemorySegmentFillUnsafe.panama false 6 avgt 10 1.731 ? 0.002 ns/op MemorySegmentFillUnsafe.panama false 7 avgt 10 1.744 ? 0.012 ns/op MemorySegmentFillUnsafe.panama false 8 avgt 10 2.367 ? 0.002 ns/op MemorySegmentFillUnsafe.panama false 15 avgt 10 2.694 ? 0.030 ns/op MemorySegmentFillUnsafe.panama false 16 avgt 10 2.517 ? 0.057 ns/op MemorySegmentFillUnsafe.panama false 63 avgt 10 3.619 ? 0.009 ns/op MemorySegmentFillUnsafe.panama false 64 avgt 10 4.708 ? 0.057 ns/op MemorySegmentFillUnsafe.panama false 255 avgt 10 5.018 ? 0.057 ns/op MemorySegmentFillUnsafe.panama false 256 avgt 10 5.038 ? 0.068 ns/op MemorySegmentFillUnsafe.unsafe true 1 avgt 10 2.815 ? 0.002 ns/op MemorySegmentFillUnsafe.unsafe true 2 avgt 10 2.821 ? 0.022 ns/op MemorySegmentFillUnsafe.unsafe true 3 avgt 10 2.502 ? 0.002 ns/op MemorySegmentFillUnsafe.unsafe true 4 avgt 10 2.815 ? 0.004 ns/op MemorySegmentFillUnsafe.unsafe true 5 avgt 10 2.502 ? 0.003 ns/op MemorySegmentFillUnsafe.unsafe true 6 avgt 10 2.505 ? 0.022 ns/op MemorySegmentFillUnsafe.unsafe true 7 avgt 10 2.193 ? 0.019 ns/op MemorySegmentFillUnsafe.unsafe true 8 avgt 10 2.190 ? 0.002 ns/op MemorySegmentFillUnsafe.unsafe true 15 avgt 10 2.043 ? 0.027 ns/op MemorySegmentFillUnsafe.unsafe true 16 avgt 10 2.191 ? 0.003 ns/op MemorySegmentFillUnsafe.unsafe true 63 avgt 10 2.061 ? 0.040 ns/op MemorySegmentFillUnsafe.unsafe true 64 avgt 10 2.196 ? 0.027 ns/op MemorySegmentFillUnsafe.unsafe true 255 avgt 10 3.756 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 256 avgt 10 3.752 ? 0.002 ns/op MemorySegmentFillUnsafe.unsafe false 1 avgt 10 2.813 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 2 avgt 10 2.817 ? 0.003 ns/op MemorySegmentFillUnsafe.unsafe false 3 avgt 10 2.502 ? 0.003 ns/op MemorySegmentFillUnsafe.unsafe false 4 avgt 10 2.816 ? 0.002 ns/op MemorySegmentFillUnsafe.unsafe false 5 avgt 10 2.507 ? 0.027 ns/op MemorySegmentFillUnsafe.unsafe false 6 avgt 10 2.507 ? 0.025 ns/op MemorySegmentFillUnsafe.unsafe false 7 avgt 10 2.195 ? 0.025 ns/op MemorySegmentFillUnsafe.unsafe false 8 avgt 10 2.192 ? 0.005 ns/op MemorySegmentFillUnsafe.unsafe false 15 avgt 10 2.050 ? 0.025 ns/op MemorySegmentFillUnsafe.unsafe false 16 avgt 10 2.188 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 63 avgt 10 2.051 ? 0.027 ns/op MemorySegmentFillUnsafe.unsafe false 64 avgt 10 2.196 ? 0.015 ns/op MemorySegmentFillUnsafe.unsafe false 255 avgt 10 4.619 ? 0.029 ns/op MemorySegmentFillUnsafe.unsafe false 256 avgt 10 4.618 ? 0.047 ns/op Graviton 4, small memory blocks: Benchmark (aligned) (size) Mode Cnt Score Error Units MemorySegmentFillUnsafe.panama true 1 avgt 10 1.970 ? 0.002 ns/op MemorySegmentFillUnsafe.panama true 2 avgt 10 1.966 ? 0.020 ns/op MemorySegmentFillUnsafe.panama true 3 avgt 10 1.963 ? 0.014 ns/op MemorySegmentFillUnsafe.panama true 4 avgt 10 1.989 ? 0.004 ns/op MemorySegmentFillUnsafe.panama true 5 avgt 10 2.030 ? 0.010 ns/op MemorySegmentFillUnsafe.panama true 6 avgt 10 2.027 ? 0.010 ns/op MemorySegmentFillUnsafe.panama true 7 avgt 10 2.077 ? 0.006 ns/op MemorySegmentFillUnsafe.panama true 8 avgt 10 2.557 ? 0.004 ns/op MemorySegmentFillUnsafe.panama true 15 avgt 10 3.176 ? 0.002 ns/op MemorySegmentFillUnsafe.panama true 16 avgt 10 2.779 ? 0.001 ns/op MemorySegmentFillUnsafe.panama true 63 avgt 10 4.302 ? 0.002 ns/op MemorySegmentFillUnsafe.panama true 64 avgt 10 4.292 ? 0.007 ns/op MemorySegmentFillUnsafe.panama true 255 avgt 10 6.311 ? 0.013 ns/op MemorySegmentFillUnsafe.panama true 256 avgt 10 5.394 ? 0.003 ns/op MemorySegmentFillUnsafe.panama false 1 avgt 10 1.970 ? 0.001 ns/op MemorySegmentFillUnsafe.panama false 2 avgt 10 1.937 ? 0.017 ns/op MemorySegmentFillUnsafe.panama false 3 avgt 10 1.954 ? 0.014 ns/op MemorySegmentFillUnsafe.panama false 4 avgt 10 1.985 ? 0.005 ns/op MemorySegmentFillUnsafe.panama false 5 avgt 10 2.006 ? 0.008 ns/op MemorySegmentFillUnsafe.panama false 6 avgt 10 2.015 ? 0.008 ns/op MemorySegmentFillUnsafe.panama false 7 avgt 10 2.138 ? 0.035 ns/op MemorySegmentFillUnsafe.panama false 8 avgt 10 2.553 ? 0.005 ns/op MemorySegmentFillUnsafe.panama false 15 avgt 10 3.178 ? 0.002 ns/op MemorySegmentFillUnsafe.panama false 16 avgt 10 2.775 ? 0.005 ns/op MemorySegmentFillUnsafe.panama false 63 avgt 10 4.296 ? 0.007 ns/op MemorySegmentFillUnsafe.panama false 64 avgt 10 4.290 ? 0.001 ns/op MemorySegmentFillUnsafe.panama false 255 avgt 10 6.334 ? 0.013 ns/op MemorySegmentFillUnsafe.panama false 256 avgt 10 5.472 ? 0.009 ns/op MemorySegmentFillUnsafe.unsafe true 1 avgt 10 3.218 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 2 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 3 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 4 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 5 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 6 avgt 10 2.503 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 7 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 8 avgt 10 2.145 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 15 avgt 10 2.886 ? 0.100 ns/op MemorySegmentFillUnsafe.unsafe true 16 avgt 10 2.145 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe true 63 avgt 10 3.781 ? 0.013 ns/op MemorySegmentFillUnsafe.unsafe true 64 avgt 10 2.735 ? 0.016 ns/op MemorySegmentFillUnsafe.unsafe true 255 avgt 10 5.079 ? 0.014 ns/op MemorySegmentFillUnsafe.unsafe true 256 avgt 10 4.007 ? 0.112 ns/op MemorySegmentFillUnsafe.unsafe false 1 avgt 10 3.218 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 2 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 3 avgt 10 2.861 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 4 avgt 10 2.864 ? 0.016 ns/op MemorySegmentFillUnsafe.unsafe false 5 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 6 avgt 10 2.503 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 7 avgt 10 2.860 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 8 avgt 10 2.145 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 15 avgt 10 2.571 ? 0.040 ns/op MemorySegmentFillUnsafe.unsafe false 16 avgt 10 2.146 ? 0.001 ns/op MemorySegmentFillUnsafe.unsafe false 63 avgt 10 4.531 ? 0.021 ns/op MemorySegmentFillUnsafe.unsafe false 64 avgt 10 5.134 ? 0.099 ns/op MemorySegmentFillUnsafe.unsafe false 255 avgt 10 6.603 ? 0.031 ns/op MemorySegmentFillUnsafe.unsafe false 256 avgt 10 7.148 ? 0.025 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2866747058 PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2866751204 From vromero at openjdk.org Fri May 9 14:35:38 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 May 2025 14:35:38 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v7] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: documentation and adding alias to lint categories ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/5d834ce0..d52ec33b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=05-06 Stats: 101 lines in 9 files changed: 36 ins; 28 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From dfuchs at openjdk.org Fri May 9 14:39:53 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 9 May 2025 14:39:53 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits: - merge latest changes from master branch - Undo whitespace change - Remove unnecessary import - Merge remote-tracking branch 'origin/master' into http3 - Fix test license - Remove leftover file (test was moved to parent directory) - Remove unnecessary import - Update throws clauses - Merge remote-tracking branch 'origin/master' into http3 - 8354275: Add HTTP/3 tests to `EmptyAuthenticate` - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=04 Stats: 103018 lines in 469 files changed: 100164 ins; 1347 del; 1507 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From liach at openjdk.org Fri May 9 14:42:52 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 14:42:52 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > documentation and adding alias to lint categories src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 434: > 432: // we need to do this as forward references are not allowed > 433: if (alias != null) { > 434: alias.alias = this; I think we wish to make this a union-find-like structure (if you are familiar with leetcode problems) - we need to have some category as roots that point to themselves. Other category like synchronization can point to identity. When we use a `LintCategory` we do a "find root" to find the actual category to use. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2081830955 From mcimadamore at openjdk.org Fri May 9 14:46:58 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 May 2025 14:46:58 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v2] In-Reply-To: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com> References: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com> Message-ID: On Fri, 9 May 2025 12:10:38 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits: > > - Fix an issue with toString on nested constructs > - Merge branch 'master' into jep502-followup > - Merge branch 'master' into jep502-followup > - Update src/java.base/share/classes/java/lang/StableValue.java > > Co-authored-by: Chen Liang > - Simplify furhter > - Address comments in PR > - Merge master > - Remove unused method and add comment > - Address comments > - Merge branch 'master' into jep502-followup > - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504 StableAPI javadoc changes look good! ------------- PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2828627039 From vklang at openjdk.org Fri May 9 14:47:56 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 9 May 2025 14:47:56 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:28:18 GMT, kabutz wrote: >> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 865: >> >>> 863: long n = 0; >>> 864: for (E e : c) { >>> 865: Objects.requireNonNull(e); >> >> This makes me wonder: Does it make sense to create new nodes if we don't track if they will still fit into the capacity? > > We could if you like, but that would subtly change the current behaviour. I tried to make as few changes as possible. On the other hand, there could be intermediate operations modifying the underlying collection before the lock is obtained, so checking wouldn't help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2081840954 From mcimadamore at openjdk.org Fri May 9 14:49:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 May 2025 14:49:54 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v10] In-Reply-To: References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com> Message-ID: <3JVT36sXI35rxZUAP0TTK270tQV0eZBeN5hXL3Xr0ro=.62770fd7-0812-4616-9574-953f48be3186@github.com> On Thu, 8 May 2025 10:50:55 GMT, Per Minborg wrote: >> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Revert more incidental changes > - Revert incidental change Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25043#pullrequestreview-2828633505 From vklang at openjdk.org Fri May 9 14:53:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 9 May 2025 14:53:52 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com> Message-ID: On Thu, 8 May 2025 13:47:41 GMT, kabutz wrote: >> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 341: >> >>> 339: if (count >= capacity) >>> 340: return false; >>> 341: linkFirst(node); >> >> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean? > >> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean? > > I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion. I understand, alas LBQ enqueue() and dequeue() don't increment a counter. It seems a bit brittle that the invariant needs to be maintained *externally* to the state modification. For the sake of maintainability I think the checks and the increment/decrement belongs in the same unit of work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2081852042 From acobbs at openjdk.org Fri May 9 15:00:56 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 9 May 2025 15:00:56 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > documentation and adding alias to lint categories I don't understand the point of having two separate `LintCategory`'s `SYNCHRONIZATION` and `IDENTITY`. That's like having two different humans just so you can call them `Robert` or `Bobby`. Put another way, are we proposing here to temporarily support compiler configurations like `Xlint:-identity,synchronization` and `Xlint:-synchronization,identity`? * If not, then there should be a single `LintCategory.IDENTITY` that is addressable through all the usual naming mechanisms (i.e., `@SuppressWarnings`, `-Xlint:foo`) as either `"synchronization"` or `"identity"`. That is `"synchronization"` is just a true alias. * If so, then we are creating a future backward-incompatibility when we merge `SYNCHRONIZATION` into `IDENTITY`. After that merge, what is `Xlint:-synchronization,identity` or `Xlint:-identity,-synchronization` supposed to mean? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2866880798 From pchilanomate at openjdk.org Fri May 9 15:07:58 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 9 May 2025 15:07:58 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com> References: <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com> Message-ID: <0YcCb_ThphXvVjENLXPNn-Z5EKdj_VIUKKAWPYdOc04=.f5571a2c-9afb-4a34-b13c-abb530e64960@github.com> On Fri, 9 May 2025 06:32:07 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename awaitBlocked to awaitTrueAndBlocked > > Marked as reviewed by alanb (Reviewer). Thanks for the reviews @AlanBateman, @kevinjwalls and @dholmes-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2866899837 From pchilanomate at openjdk.org Fri May 9 15:07:57 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 9 May 2025 15:07:57 GMT Subject: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 21:59:18 GMT, David Holmes wrote: > > we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). > > No, because that is an internal implementation detail. It is a grey area. There is no such thing as an uninterruptible-wait in the Java language, so if we marked the thread as waiting and yet it failed to stop waiting if interrupted, then that would appear to be a bug. > I see, thanks for the clarification David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2866895215 From pchilanomate at openjdk.org Fri May 9 15:07:59 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 9 May 2025 15:07:59 GMT Subject: Integrated: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments). > > I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). > > I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 9ebb5d42 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/9ebb5d42d43a743cf3a5197c7dabe46ac8120474 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock Reviewed-by: kevinw, dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25119 From liach at openjdk.org Fri May 9 15:16:58 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 15:16:58 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > documentation and adding alias to lint categories Good point; maybe instead of creating new `LintCategory`, we use this union-find approach to deduplicate when we parse LintCategory from strings. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2866948054 From aph at openjdk.org Fri May 9 15:20:53 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 9 May 2025 15:20:53 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Apple M1: Benchmark (ELEM_SIZE) Mode Cnt Score Error Units SegmentBulkFill.heapSegmentFillJava 2 avgt 10 1.727 ? 0.017 ns/op SegmentBulkFill.heapSegmentFillJava 3 avgt 10 1.721 ? 0.002 ns/op SegmentBulkFill.heapSegmentFillJava 4 avgt 10 1.876 ? 0.002 ns/op SegmentBulkFill.heapSegmentFillJava 5 avgt 10 1.876 ? 0.001 ns/op SegmentBulkFill.heapSegmentFillJava 6 avgt 10 1.876 ? 0.002 ns/op SegmentBulkFill.heapSegmentFillJava 7 avgt 10 1.876 ? 0.002 ns/op SegmentBulkFill.heapSegmentFillJava 8 avgt 10 2.502 ? 0.003 ns/op SegmentBulkFill.heapSegmentFillJava 64 avgt 10 4.064 ? 0.002 ns/op SegmentBulkFill.heapSegmentFillJava 512 avgt 10 6.601 ? 0.051 ns/op SegmentBulkFill.heapSegmentFillJava 4096 avgt 10 44.050 ? 0.076 ns/op SegmentBulkFill.heapSegmentFillJava 32768 avgt 10 330.328 ? 0.450 ns/op SegmentBulkFill.heapSegmentFillJava 262144 avgt 10 4138.154 ? 6.509 ns/op SegmentBulkFill.heapSegmentFillJava 2097152 avgt 10 33089.966 ? 48.068 ns/op SegmentBulkFill.heapSegmentFillJava 16777216 avgt 10 352669.548 ? 571.433 ns/op SegmentBulkFill.heapSegmentFillJava 134217728 avgt 10 4482510.192 ? 7177.637 ns/op SegmentBulkFill.heapSegmentFillLoop 2 avgt 10 1.977 ? 0.003 ns/op SegmentBulkFill.heapSegmentFillLoop 3 avgt 10 3.447 ? 0.002 ns/op SegmentBulkFill.heapSegmentFillLoop 4 avgt 10 4.073 ? 0.042 ns/op SegmentBulkFill.heapSegmentFillLoop 5 avgt 10 4.377 ? 0.004 ns/op SegmentBulkFill.heapSegmentFillLoop 6 avgt 10 5.337 ? 0.071 ns/op SegmentBulkFill.heapSegmentFillLoop 7 avgt 10 5.629 ? 0.004 ns/op SegmentBulkFill.heapSegmentFillLoop 8 avgt 10 5.947 ? 0.010 ns/op SegmentBulkFill.heapSegmentFillLoop 64 avgt 10 8.127 ? 0.003 ns/op SegmentBulkFill.heapSegmentFillLoop 512 avgt 10 16.045 ? 0.027 ns/op SegmentBulkFill.heapSegmentFillLoop 4096 avgt 10 46.627 ? 0.164 ns/op SegmentBulkFill.heapSegmentFillLoop 32768 avgt 10 333.233 ? 1.040 ns/op SegmentBulkFill.heapSegmentFillLoop 262144 avgt 10 4134.009 ? 11.125 ns/op SegmentBulkFill.heapSegmentFillLoop 2097152 avgt 10 33148.671 ? 322.905 ns/op SegmentBulkFill.heapSegmentFillLoop 16777216 avgt 10 343832.913 ? 233.881 ns/op SegmentBulkFill.heapSegmentFillLoop 134217728 avgt 10 4475821.911 ? 6101.380 ns/op SegmentBulkFill.heapSegmentFillUnsafe 2 avgt 10 3.133 ? 0.034 ns/op SegmentBulkFill.heapSegmentFillUnsafe 3 avgt 10 3.130 ? 0.005 ns/op SegmentBulkFill.heapSegmentFillUnsafe 4 avgt 10 3.128 ? 0.004 ns/op SegmentBulkFill.heapSegmentFillUnsafe 5 avgt 10 3.139 ? 0.030 ns/op SegmentBulkFill.heapSegmentFillUnsafe 6 avgt 10 3.135 ? 0.035 ns/op SegmentBulkFill.heapSegmentFillUnsafe 7 avgt 10 3.135 ? 0.030 ns/op SegmentBulkFill.heapSegmentFillUnsafe 8 avgt 10 2.665 ? 0.006 ns/op SegmentBulkFill.heapSegmentFillUnsafe 64 avgt 10 2.841 ? 0.032 ns/op SegmentBulkFill.heapSegmentFillUnsafe 512 avgt 10 6.246 ? 0.100 ns/op SegmentBulkFill.heapSegmentFillUnsafe 4096 avgt 10 41.241 ? 0.107 ns/op SegmentBulkFill.heapSegmentFillUnsafe 32768 avgt 10 331.001 ? 4.521 ns/op SegmentBulkFill.heapSegmentFillUnsafe 262144 avgt 10 3038.808 ? 29.750 ns/op SegmentBulkFill.heapSegmentFillUnsafe 2097152 avgt 10 21996.375 ? 2617.947 ns/op SegmentBulkFill.heapSegmentFillUnsafe 16777216 avgt 10 241814.864 ? 24300.854 ns/op SegmentBulkFill.heapSegmentFillUnsafe 134217728 avgt 10 2811655.392 ? 24737.911 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2866961810 From liach at openjdk.org Fri May 9 15:21:03 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 15:21:03 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v2] In-Reply-To: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com> References: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com> Message-ID: <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com> On Fri, 9 May 2025 12:10:38 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits: > > - Fix an issue with toString on nested constructs > - Merge branch 'master' into jep502-followup > - Merge branch 'master' into jep502-followup > - Update src/java.base/share/classes/java/lang/StableValue.java > > Co-authored-by: Chen Liang > - Simplify furhter > - Address comments in PR > - Merge master > - Remove unused method and add comment > - Address comments > - Merge branch 'master' into jep502-followup > - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504 Looks good, some bikeshedding src/java.base/share/classes/java/util/ImmutableCollections.java line 140: > 138: } > 139: public List stableList(int size, IntFunction mapper) { > 140: // A stable list is not Serializable so, we cannot return `List.of()` if `size == 0` Suggestion: // A stable list is not Serializable, so we cannot return `List.of()` if `size == 0` src/java.base/share/classes/java/util/ImmutableCollections.java line 144: > 142: } > 143: public Map stableMap(Set keys, Function mapper) { > 144: // A stable map is not Serializable so, we cannot return `Map.of()` if `keys.isEmpty()` Suggestion: // A stable map is not Serializable, so we cannot return `Map.of()` if `keys.isEmpty()` bikeshedding. src/java.base/share/classes/java/util/ImmutableCollections.java line 879: > 877: public List subList(int fromIndex, int toIndex) { > 878: final int size = size(); > 879: subListRangeCheck(fromIndex, toIndex, size); Suggestion: subListRangeCheck(fromIndex, toIndex, size()); Redundant variable. src/java.base/share/classes/java/util/ImmutableCollections.java line 1715: > 1713: > 1714: // For @ValueBased > 1715: static private LazyMapIterator of(StableMapEntrySet outer) { Suggestion: private static LazyMapIterator of(StableMapEntrySet outer) { src/java.base/share/classes/java/util/ReverseOrderListView.java line 46: > 44: final List base; > 45: @Stable > 46: final boolean modifiable; Unfortunately, stable on boolean only works for true - wish we can get trusted or strict final soon :) ------------- PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2828636051 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081846330 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081847091 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081851704 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081858151 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081860387 From rriggs at openjdk.org Fri May 9 15:23:36 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 May 2025 15:23:36 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v8] In-Reply-To: References: Message-ID: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - Refactor ensureCapacityNewCoder to compute newCapacity first and add an assert to check the count of characters fit within the new capacity. The same and different coder paths had slightly different computations for newCapacity. - Add a test exercising the buffer capacity changes during SB.replace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/1404fa9e..8f731431 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=06-07 Stats: 72 lines in 2 files changed: 56 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From rriggs at openjdk.org Fri May 9 15:23:36 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 May 2025 15:23:36 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v6] In-Reply-To: References: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com> Message-ID: On Tue, 6 May 2025 16:18:11 GMT, Chen Liang wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply reviewer suggestions for typos, javadoc, and copyright dates. > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 270: > >> 268: private static byte[] ensureCapacityNewCoder(byte[] value, byte coder, int count, >> 269: int minimumCapacity, byte newCoder) { >> 270: assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1"; > > I recommend an additional assertion `count <= minimumCapacity`; even though all callers ensure this currently, in case this is accidentally violated, we are sending dangerous arguments to `StringLatin1.inflate`. > > Also, the message string of assertion can include the `coder` and `newCoder` values. Same for the other assertions we add. Added the assertion(s) without the extra message formatting overhead/codesize. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081918105 From aph at openjdk.org Fri May 9 15:30:53 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 9 May 2025 15:30:53 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: <2yBNv1pe_7PYsML-ySuw5EMb2cqamuF1wDiDgRtNP3Y=.0fa1c070-d627-472f-9255-376d3a4bd7b6@github.com> On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Graviton 4: Benchmark (ELEM_SIZE) Mode Cnt Score Error Units SegmentBulkFill.heapSegmentFillJava 2 avgt 10 2.324 ? 0.066 ns/op SegmentBulkFill.heapSegmentFillJava 3 avgt 10 2.427 ? 0.031 ns/op SegmentBulkFill.heapSegmentFillJava 4 avgt 10 2.231 ? 0.009 ns/op SegmentBulkFill.heapSegmentFillJava 5 avgt 10 2.523 ? 0.040 ns/op SegmentBulkFill.heapSegmentFillJava 6 avgt 10 2.632 ? 0.017 ns/op SegmentBulkFill.heapSegmentFillJava 7 avgt 10 2.394 ? 0.007 ns/op SegmentBulkFill.heapSegmentFillJava 8 avgt 10 3.004 ? 0.032 ns/op SegmentBulkFill.heapSegmentFillJava 64 avgt 10 4.813 ? 0.417 ns/op SegmentBulkFill.heapSegmentFillJava 512 avgt 10 9.151 ? 0.040 ns/op SegmentBulkFill.heapSegmentFillJava 4096 avgt 10 60.127 ? 0.078 ns/op SegmentBulkFill.heapSegmentFillJava 32768 avgt 10 461.292 ? 2.127 ns/op SegmentBulkFill.heapSegmentFillJava 262144 avgt 10 3666.851 ? 0.280 ns/op SegmentBulkFill.heapSegmentFillJava 2097152 avgt 10 35169.510 ? 22.507 ns/op SegmentBulkFill.heapSegmentFillJava 16777216 avgt 10 227182.710 ? 903.546 ns/op SegmentBulkFill.heapSegmentFillJava 134217728 avgt 10 1946761.410 ? 3033.447 ns/op SegmentBulkFill.heapSegmentFillLoop 2 avgt 10 2.902 ? 0.038 ns/op SegmentBulkFill.heapSegmentFillLoop 3 avgt 10 3.870 ? 0.004 ns/op SegmentBulkFill.heapSegmentFillLoop 4 avgt 10 5.438 ? 0.013 ns/op SegmentBulkFill.heapSegmentFillLoop 5 avgt 10 5.714 ? 0.033 ns/op SegmentBulkFill.heapSegmentFillLoop 6 avgt 10 5.748 ? 0.019 ns/op SegmentBulkFill.heapSegmentFillLoop 7 avgt 10 5.909 ? 0.004 ns/op SegmentBulkFill.heapSegmentFillLoop 8 avgt 10 6.330 ? 0.295 ns/op SegmentBulkFill.heapSegmentFillLoop 64 avgt 10 8.769 ? 0.003 ns/op SegmentBulkFill.heapSegmentFillLoop 512 avgt 10 16.935 ? 0.007 ns/op SegmentBulkFill.heapSegmentFillLoop 4096 avgt 10 57.822 ? 0.510 ns/op SegmentBulkFill.heapSegmentFillLoop 32768 avgt 10 376.849 ? 0.311 ns/op SegmentBulkFill.heapSegmentFillLoop 262144 avgt 10 3059.064 ? 0.419 ns/op SegmentBulkFill.heapSegmentFillLoop 2097152 avgt 10 24398.571 ? 8.618 ns/op SegmentBulkFill.heapSegmentFillLoop 16777216 avgt 10 225721.136 ? 608.041 ns/op SegmentBulkFill.heapSegmentFillLoop 134217728 avgt 10 1940987.569 ? 2156.239 ns/op SegmentBulkFill.heapSegmentFillUnsafe 2 avgt 10 3.628 ? 0.022 ns/op SegmentBulkFill.heapSegmentFillUnsafe 3 avgt 10 3.670 ? 0.011 ns/op SegmentBulkFill.heapSegmentFillUnsafe 4 avgt 10 3.583 ? 0.002 ns/op SegmentBulkFill.heapSegmentFillUnsafe 5 avgt 10 3.651 ? 0.016 ns/op SegmentBulkFill.heapSegmentFillUnsafe 6 avgt 10 3.659 ? 0.015 ns/op SegmentBulkFill.heapSegmentFillUnsafe 7 avgt 10 3.687 ? 0.016 ns/op SegmentBulkFill.heapSegmentFillUnsafe 8 avgt 10 3.193 ? 0.022 ns/op SegmentBulkFill.heapSegmentFillUnsafe 64 avgt 10 3.365 ? 0.034 ns/op SegmentBulkFill.heapSegmentFillUnsafe 512 avgt 10 6.443 ? 0.006 ns/op SegmentBulkFill.heapSegmentFillUnsafe 4096 avgt 10 48.261 ? 0.081 ns/op SegmentBulkFill.heapSegmentFillUnsafe 32768 avgt 10 389.793 ? 0.777 ns/op SegmentBulkFill.heapSegmentFillUnsafe 262144 avgt 10 3123.758 ? 1.048 ns/op SegmentBulkFill.heapSegmentFillUnsafe 2097152 avgt 10 25039.904 ? 55.467 ns/op SegmentBulkFill.heapSegmentFillUnsafe 16777216 avgt 10 223579.037 ? 306.005 ns/op SegmentBulkFill.heapSegmentFillUnsafe 134217728 avgt 10 1931370.983 ? 1110.364 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2867002071 From aph at openjdk.org Fri May 9 15:39:35 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 9 May 2025 15:39:35 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2] In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: generate_unsafecopy_common_error_exit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25147/files - new: https://git.openjdk.org/jdk/pull/25147/files/c3d4c414..1078ba8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=00-01 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From rgiulietti at openjdk.org Fri May 9 15:57:57 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 9 May 2025 15:57:57 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 13:28:44 GMT, Raffaello Giulietti wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Add an assert to inflateToUTF16 method >> Add doc of preconditions to appendChars... methods >> Correct misc javadoc > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1901: > >> 1899: } >> 1900: return value; >> 1901: } > > I think the logic can be simplified, without a need for the loop. > > private static byte[] putCharsAt(byte[] value, byte coder, int count, int index, char[] s, int off, int end) { > if (isLatin1(coder)) { > int latin1Len = StringUTF16.compress(s, off, value, index, end - off); > if (latin1Len < end - off) { > value = inflateToUTF16(value, count); > StringUTF16.putCharsSB(value, index + latin1Len, s, off + latin1Len, end); > } > } else { > StringUTF16.putCharsSB(value, index, s, off, end); > } > return value; > } Unfortunately, my simplification isn't sound when `s` is concurrently modified. Please disregard. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081978097 From kbarrett at openjdk.org Fri May 9 15:59:38 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 9 May 2025 15:59:38 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v6] In-Reply-To: References: Message-ID: <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com> > Please review this change which adds a native method providing the > implementation of Reference::get. Referece::get is an intrinsic candidate, so > this native method implementation is only used when the intrinsic is not. > > Currently there is intrinsic support by the interpreter, C1, C2, and graal, > which are always used. With this change we can later remove all the > per-platform interpreter intrinsic implementations, and might also remove the > C1 intrinsic implementation. > > Testing: > (1) mach5 tier1-6 normal (so using all the existing intrinsics). > (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. Kim Barrett 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 native-reference-get - use new waitForRefProc, some tidying - Merge branch 'master' into native-reference-get - remove timeout by using waitForReferenceProcessing - make ill-timed gc in non-concurrent case less likely - fix test package use - add package decl to test - parameterized return type of native get0 - test native method - native Reference.get helper ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24315/files - new: https://git.openjdk.org/jdk/pull/24315/files/48b7960c..6b4e4c76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=04-05 Stats: 6281 lines in 341 files changed: 3313 ins; 1807 del; 1161 mod Patch: https://git.openjdk.org/jdk/pull/24315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315 PR: https://git.openjdk.org/jdk/pull/24315 From dfuchs at openjdk.org Fri May 9 16:01:51 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 9 May 2025 16:01:51 GMT Subject: RFR: 8356644: Update encoding declaration to UTF-8 In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> Message-ID: On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper. > > I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8. Changes to net-properties.html LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2828873053 From naoto at openjdk.org Fri May 9 16:08:50 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 16:08:50 GMT Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8 characters [v4] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie wrote: >> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them. >> >> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? >> >> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code. >> >> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Clarify non-ASCII characters with unicode code point LGTM. Thanks for the changes ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24727#pullrequestreview-2828887346 From darcy at openjdk.org Fri May 9 16:15:11 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 9 May 2025 16:15:11 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2] In-Reply-To: References: Message-ID: > Fix javadoc tags. 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/25131/files - new: https://git.openjdk.org/jdk/pull/25131/files/d1c2345a..212261bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25131.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25131/head:pull/25131 PR: https://git.openjdk.org/jdk/pull/25131 From darcy at openjdk.org Fri May 9 16:10:57 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 9 May 2025 16:10:57 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal In-Reply-To: References: Message-ID: On Fri, 9 May 2025 10:32:27 GMT, Nizar Benalla wrote: > I just noticed there are a couple more javadoc tags that need to be fixed in this class, I still see two more warnings. I should have included these in the JBS issue when filling it. > > ``` > src/java.base/share/classes/java/math/BigDecimal.java:363: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types) > * The scale of this BigDecimal, as returned by {@link #scale}. > ^ > src/java.base/share/classes/java/math/BigDecimal.java:366: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types) > * @see #scale > ^ > ``` > ``` Okay; I'll add a fix for that, although the javadoc text is one a private field so is not generated by default. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25131#issuecomment-2867109531 From naoto at openjdk.org Fri May 9 16:20:00 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 16:20:00 GMT Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550 In-Reply-To: References: Message-ID: On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case. > Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25130#issuecomment-2867133483 From naoto at openjdk.org Fri May 9 16:20:01 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 16:20:01 GMT Subject: Integrated: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550 In-Reply-To: References: Message-ID: On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case. > Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater. This pull request has now been integrated. Changeset: 5f00c877 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/5f00c877e26f1716da231771b611234db5607fa7 Stats: 10 lines in 1 file changed: 7 ins; 1 del; 2 mod 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550 Reviewed-by: bpb, jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/25130 From nbenalla at openjdk.org Fri May 9 16:22:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 9 May 2025 16:22:51 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 16:15:11 GMT, Joe Darcy wrote: >> Fix javadoc tags. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Looks good! ------------- Marked as reviewed by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2828933840 From liach at openjdk.org Fri May 9 16:26:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 16:26:55 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2] In-Reply-To: References: Message-ID: <7YmRRAotqqh-90KZ3CaMwWPiFyevfBiupHI24ORvB3Q=.a418860a-94c1-4539-871c-cc6a66d08725@github.com> On Fri, 9 May 2025 16:15:11 GMT, Joe Darcy wrote: >> Fix javadoc tags. > > 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/25131#pullrequestreview-2828942139 From bpb at openjdk.org Fri May 9 16:30:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 May 2025 16:30:54 GMT Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2] In-Reply-To: References: Message-ID: <4HYcWFe2bgyoumYenJrfBMcj3xiLYLW1E5JmtHo5Y-0=.054f959f-d30e-4bbc-af3c-5d80c7095631@github.com> On Fri, 9 May 2025 16:15:11 GMT, Joe Darcy wrote: >> Fix javadoc tags. > > 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/25131#pullrequestreview-2828951810 From darcy at openjdk.org Fri May 9 16:38:59 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 9 May 2025 16:38:59 GMT Subject: Integrated: 8356555: Incorrect use of {@link} in BigDecimal In-Reply-To: References: Message-ID: <4Uk4QI1N7TIJegN8bHqwHBo2p4CkqLbbqliLu04ocmg=.d22f26f2-e683-460c-8f10-e34888f4a4e2@github.com> On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. This pull request has now been integrated. Changeset: bed29a03 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/bed29a03d198a9717f7d258ee21330462775136e Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8356555: Incorrect use of {@link} in BigDecimal Reviewed-by: bpb, nbenalla, liach, iris ------------- PR: https://git.openjdk.org/jdk/pull/25131 From rriggs at openjdk.org Fri May 9 16:41:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 May 2025 16:41:39 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v9] In-Reply-To: References: Message-ID: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Removed extraneous "the" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24967/files - new: https://git.openjdk.org/jdk/pull/24967/files/8f731431..e7aa6303 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967 PR: https://git.openjdk.org/jdk/pull/24967 From almatvee at openjdk.org Fri May 9 16:49:56 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 May 2025 16:49:56 GMT Subject: Integrated: 8352480: Don't follow symlinks in additional content for app images In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 20:17:57 GMT, Alexander Matveev wrote: > - Symbolic links will not be followed for `--app-content` on all platforms. > - Added test to cover this case. > - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links. This pull request has now been integrated. Changeset: 601f05e0 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/601f05e06d3c364ab5b151785d4ac49183cf61b5 Stats: 96 lines in 3 files changed: 57 ins; 24 del; 15 mod 8352480: Don't follow symlinks in additional content for app images Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/24974 From jlu at openjdk.org Fri May 9 16:54:56 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 9 May 2025 16:54:56 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() In-Reply-To: References: Message-ID: On Tue, 6 May 2025 07:25:36 GMT, Abhishek N wrote: > Create a Test case to have special cases coverage for currency.getInstance(). > > The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API. > > test results: > > jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Test results: passed: 1 > Report written to JTreport\html\report.html > Results written to JTwork Hi @abhn-git, thanks for contributing the test but it's not clear to me what the purpose of this PR is. It seems to be testing the Currency overriding mechanism via the system property but that behavior is already tested. If you are attempting to test the future cut-over behavior for a standard ISO 4217 currency in `currencyData.properties`, the override mechanism does not simulate this 1-1. For a standard ISO 4217 currency in `currencyData.properties`, a currency transition for a locale can occur at any time, (i.e. subsequent `getInstance(Locale)` calls can return different currencies). For the override mechanism, the transition is checked in the static block, and the resulting currency selected is fixed for the duration of the application's lifecycle. ------------- Changes requested by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/25057#pullrequestreview-2829069916 From rgiulietti at openjdk.org Fri May 9 16:55:01 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 9 May 2025 16:55:01 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55] In-Reply-To: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com> References: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com> Message-ID: <_ib9SlZnCi08sAjh2SZ5LrPC3Q4_LK7du9wKhQpsuWE=.f0e5d603-0342-4e9f-a567-54c7b10130d9@github.com> On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Code simplification Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24690#pullrequestreview-2829069025 From kbarrett at openjdk.org Fri May 9 16:56:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 9 May 2025 16:56:55 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v4] In-Reply-To: References: Message-ID: <93k3k6NWe-yOZtaoWAO6UEDM-tcbCnD-2B1sIAin42g=.5a393055-540d-4df5-8fea-9b2bb0a97e1e@github.com> On Fri, 11 Apr 2025 08:14:29 GMT, Kim Barrett wrote: >> test/hotspot/jtreg/gc/TestNativeReferenceGet.java line 137: >> >>> 135: } >>> 136: checkQueue(); // One last check after refproc complete. >>> 137: } catch (InterruptedException e) { >> >> Rather than using Reference.remove with a timeout, I've changed this to use waitForReferenceProcessing. >> That removes false passes (from reference processing being slow to deliver) and also removes the delay >> until timeout for the passing case. > > https://github.com/openjdk/jdk/pull/24527 is proposing a different way to access > `waitForReferenceProcessing`. I'll wait for that. Test has now been changed to use the new `WhiteBox::waitForReferenceProcessing()`. So how about some reviews... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2082106208 From rgiulietti at openjdk.org Fri May 9 16:56:57 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 9 May 2025 16:56:57 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v9] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed extraneous "the" Thanks @RogerRiggs ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2829074577 From duke at openjdk.org Fri May 9 17:04:00 2025 From: duke at openjdk.org (duke) Date: Fri, 9 May 2025 17:04:00 GMT Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55] In-Reply-To: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com> References: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com> Message-ID: <9JhxqnfUH0boq5pOvDrJWVDheuysPs6OrtmVamMNES4=.fc18b49f-9c24-40d9-b3c1-988c033650fd@github.com> On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Code simplification @fabioromano1 Your change (at version 261dd315537f6135a4f065b3dcbcfe045d4a27db) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2867305168 From duke at openjdk.org Fri May 9 17:09:05 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 9 May 2025 17:09:05 GMT Subject: Integrated: 8355719: Reduce memory consumption of BigInteger.pow() In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 13:45:55 GMT, fabioromano1 wrote: > This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory. This pull request has now been integrated. Changeset: 1c5eb370 Author: Fabio Romano Committer: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/1c5eb370b7dbe7558b535bf27c9df292c2007b9b Stats: 329 lines in 2 files changed: 231 ins; 49 del; 49 mod 8355719: Reduce memory consumption of BigInteger.pow() Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/24690 From liach at openjdk.org Fri May 9 17:14:53 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 17:14:53 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v9] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed extraneous "the" The new safeguards look good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2829109097 From joehw at openjdk.org Fri May 9 17:15:59 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 9 May 2025 17:15:59 GMT Subject: Integrated: 8353232: Standardizing and Unifying XML Component Configurations In-Reply-To: References: Message-ID: <-jL2Xj52A9qNbSU-iKomS2rRkQT2MeSJ1q_Ydknej3I=.0a67e659-98b3-4eea-869b-8c02998c2ce3@github.com> On Wed, 7 May 2025 16:17:07 GMT, Joe Wang wrote: > This is a refactor patch, no change in functionality. > > This patch refactor the configuration code. Rather than for each factory to go through the whole configuration process, a base configuration as represented in JdkXmlConfig is created once, which includes loading of the JAXP Configuration file, factories then get their own copies of the property managers, created on top of the base ones rather than directly constructed. > > The JDKCatalog and its Resolver are lazily initialized when external references are encountered. This code replaces the original code block within the security manager. This change also addresses JDK-8350189. > > The rest of changes basically replace all direct constructions of XMLSecurityManager/XMLSecurityPropertyManager with calls to JdkXmlConfig's corresponding get methods, which return clones of the base instances. in the factory classes, these clones are updated with property settings on the factories. In non-public or legacy code paths (inherited from upstream components), such updates may not be necessary. > > Tests: existing tests T1-3 passed; XML JCK tests passed. This pull request has now been integrated. Changeset: 66f04427 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/66f044271324643ee17df13ad3ef254bc4dbd798 Stats: 582 lines in 31 files changed: 318 ins; 119 del; 145 mod 8353232: Standardizing and Unifying XML Component Configurations Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/25102 From asemenyuk at openjdk.org Fri May 9 17:28:19 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 May 2025 17:28:19 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v2] In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> Message-ID: > Refactor jpackage to separate the configuration and execution phases. > At the configuration phase, jpackage parses command-line arguments and validates them. > At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. > > There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. > > This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. > > The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". > > Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. > > jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html > > **Functional changes** > jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. > > - Minimize copying of the source app image when doing native packaging. > > Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. > > - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. > > post- and pre- install PKG scripts for SimplePackageTest package before and after the change: > > > > > > > > > References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> Message-ID: > Refactor jpackage to separate the configuration and execution phases. > At the configuration phase, jpackage parses command-line arguments and validates them. > At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. > > There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. > > This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. > > The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". > > Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. > > jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html > > **Functional changes** > jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. > > - Minimize copying of the source app image when doing native packaging. > > Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. > > - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. > > post- and pre- install PKG scripts for SimplePackageTest package before and after the change: >
      ScriptNewOld
      > > > > > > > > References: Message-ID: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com> > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson 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: - switch platform helper to be mapToNativeLibraryName - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix - fix spelling - new approach: append . to file name on Windows - 8348828: Windows dll loading now resolves symlinks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24694/files - new: https://git.openjdk.org/jdk/pull/24694/files/70e943c8..58d644a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=02-03 Stats: 90263 lines in 2420 files changed: 66254 ins; 14855 del; 9154 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From duke at openjdk.org Fri May 9 17:42:14 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Fri, 9 May 2025 17:42:14 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3] In-Reply-To: References: Message-ID: <3B3YzTERC8bABG-b9P6fiKfLZnq0HYjH3awaW3jaivY=.30a8f806-20c2-4a2e-b91d-491e0bd1870e@github.com> On Fri, 9 May 2025 09:10:21 GMT, Alan Bateman wrote: > Is this documented in the Microsoft document for LoadLibrary? We don't want to rely on undocumented behavior as it could break at any time. [LoadLibraryEx` documentation](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa) states: To prevent the function from appending ".DLL" to the module name, include a trailing point character (.) in the module name string. which isn't incompatible with not adding `.dll` when the extension is already present. Practically speaking, I imagine the behavior of a common operating system API available since at least Windows XP is completly ossified. > > For the prototype, I think you can replace nativeLoaderFileNameSuffix() with mapToNativeLibraryName(String) so that other platforms can "return this". This would give the flexibility to prefix or do other mangling. I've changed the implementation to do this. > > That said, I'm not so sure that we should changing the JDK to work in this unusual environment. Are you able to name the product that is move-renaming the DLLs and replacing them with sym links? Just trying to get some sense as to whether this is something that many people might run into it. I understand the narrow reproducer in the bug is weird, but it was isolated from a generically useful system. As I explained in https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766, this arises in a generic system my company offers for executing tasks in distributed fashion across many machines. We don't have any particular interest in DLLs or even JDK installations; we simply create a symlinks for all data required by tasks that our system is asked to execute. This system worked fine with JDKS through Java 23 and all previous versions we've tried. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2082174367 From vromero at openjdk.org Fri May 9 17:56:38 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 May 2025 17:56:38 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v8] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: additional documentation changes and bug fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/d52ec33b..1ff2f2c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=06-07 Stats: 79 lines in 7 files changed: 41 ins; 7 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From wxiao at openjdk.org Fri May 9 18:21:51 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Fri, 9 May 2025 18:21:51 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() In-Reply-To: References: Message-ID: On Tue, 6 May 2025 07:25:36 GMT, Abhishek N wrote: > Create a Test case to have special cases coverage for currency.getInstance(). > > The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API. > > test results: > > jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Test results: passed: 1 > Report written to JTreport\html\report.html > Results written to JTwork The root cause of the failure in https://bugs.openjdk.org/browse/JDK-8353433 was written by @coffeys in the bug. Right now It needs a test case to verify when future cut-over time is passing and the currency is going to work properly. Here is the example defined in CurrencyData.properties, "CW=ANG;2026-04-01-04-00-00;XCG". Technically it needs to overwrite the return value of System.currentTimeMillis() and make it return with future time to trigger the test for future currency. see this line https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Currency.java#L423. BTW, @justin-curtis-lu made the change in the mainline of JDK at https://bugs.openjdk.org/browse/JDK-8354344. Since it is using ClassFiie API, it can not be backported to jdk with version 23 or lower. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2867537361 From smarks at openjdk.org Fri May 9 18:53:53 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 9 May 2025 18:53:53 GMT Subject: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` [v2] In-Reply-To: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com> References: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com> Message-ID: On Fri, 9 May 2025 07:50:29 GMT, Per Minborg wrote: >> This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Remove spurious class > - Address comments Looks good. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25120#pullrequestreview-2829404293 From smarks at openjdk.org Fri May 9 18:53:54 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 9 May 2025 18:53:54 GMT Subject: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:03:30 GMT, Per Minborg wrote: >> There are some new collections (such as StableList) that are not covered in Basic. But maybe they should have their separate tests? > > `UnmodifiableSequencedCollection` double-reversed is not an identity function. But at least, it does not nest, as it returns a new USC with the underlying collection reversed. Re the testing strategy: perhaps ideally, everything would be covered by MOAT, but its architecture is kind of cobbled together and doesn't support new features very well. The SequencedCollection/Basic tests are decent for SC but there's some uncomfortable overlap with MOAT. So there's some tension here. For a new "kind" of collection like StableX it's unclear whether they should have their own tests or be added to a centralized place. It would be nice if StableX could rely on the tests for "typical" collection semantics. However, I'm not sure of their semantics of Stable collections when certain operations are performed. It looks like certain operations like contains(), indexOf(), and toArray() all eagerly evaluate the mapper function. So if the values have all been established, all the usual assertions for ordinary unmodifiable collections should apply. However, there are probably other operations that don't want to evaluate the element, so you'll want to have separate tests for those. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2082338587 From bchristi at openjdk.org Fri May 9 19:20:55 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 9 May 2025 19:20:55 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v9] In-Reply-To: References: Message-ID: <48Z0yWp-3t3IYySh3EQflD9TfUnGSTKgHoiM408ZMvE=.f0682895-7a6b-4067-9dda-c6f23996a840@github.com> On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed extraneous "the" Marked as reviewed by bchristi (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2829460339 From prr at openjdk.org Fri May 9 19:24:53 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 9 May 2025 19:24:53 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> References: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> Message-ID: On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth wrote: > > test/jdk/java/awt/font/NumericShaper/MTTest.java > > ``` > > * * @run main/timeout=300/othervm MTTest > > > > > > * * @run main/timeout=1200/othervm MTTest > > ``` > > > > > > > > > > > > > > > > > > > > > > > > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. > > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java > > So 300 was fine, and 1200 isn't needed. > > I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough? I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176 From naoto at openjdk.org Fri May 9 19:58:01 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 19:58:01 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in Message-ID: With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/25155/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356420 Stats: 29 lines in 3 files changed: 21 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155 PR: https://git.openjdk.org/jdk/pull/25155 From weijun at openjdk.org Fri May 9 20:05:10 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 9 May 2025 20:05:10 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7] In-Reply-To: References: Message-ID: > Finalize the KDF API. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: new algorithms in SunJCE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24520/files - new: https://git.openjdk.org/jdk/pull/24520/files/f44dc9bd..aeb82ccf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=05-06 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From acobbs at openjdk.org Fri May 9 20:16:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 9 May 2025 20:16:54 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:55:34 GMT, Vicente Romero wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: >> >> - Merge branch 'master' into JDK-8354556 >> - addressing review comment >> - changes to test >> - Merge branch 'master' into JDK-8354556 >> - updating test >> - final adjustments >> - additional refactorings >> - removing unneeded changes >> - more refactorings >> - more refactorings and tests >> - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0 > > note to reviewers: I had an offline discussion with Dan, I will introduce some changes to the implementation @vicente-romero-oracle, please see my [`identity-alias-synchronization`](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:identity-alias-synchronization?files) branch for an example of only having a single `LintCategory` with an alias. This branch passes `make test TEST="langtools_javac"`. This patch is based on an another PR that I already had lying around which had some related changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867784880 From bpb at openjdk.org Fri May 9 20:18:56 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 May 2025 20:18:56 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in In-Reply-To: References: Message-ID: <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com> On Fri, 9 May 2025 19:53:24 GMT, Naoto Sato wrote: > With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. Looks good. src/java.base/share/classes/java/lang/System.java line 136: > 134: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); > 135: * } > 136: * Or with a {@link java.util.Scanner Scanner}: "Or with" -> "Using a" or "Or using a" for consistency? Up to you. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2829563522 PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082436990 From vromero at openjdk.org Fri May 9 20:28:12 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 May 2025 20:28:12 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: fixing bugs, removing dead code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/1ff2f2c6..ea631161 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=07-08 Stats: 57 lines in 3 files changed: 12 ins; 34 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Fri May 9 20:28:14 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 May 2025 20:28:14 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:55:34 GMT, Vicente Romero wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: >> >> - Merge branch 'master' into JDK-8354556 >> - addressing review comment >> - changes to test >> - Merge branch 'master' into JDK-8354556 >> - updating test >> - final adjustments >> - additional refactorings >> - removing unneeded changes >> - more refactorings >> - more refactorings and tests >> - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0 > > note to reviewers: I had an offline discussion with Dan, I will introduce some changes to the implementation > @vicente-romero-oracle, please see my [`identity-alias-synchronization`](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:identity-alias-synchronization?files) branch for an example of only having a single `LintCategory` with an alias. This branch passes `make test TEST="langtools_javac"`. This patch is based on an another PR that I already had lying around which had some related changes. I was working on something in this line too, just pushed the patch ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867804036 From naoto at openjdk.org Fri May 9 20:39:27 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 20:39:27 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: Message-ID: > With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects a review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25155/files - new: https://git.openjdk.org/jdk/pull/25155/files/844aa0a7..496dd39d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155 PR: https://git.openjdk.org/jdk/pull/25155 From bpb at openjdk.org Fri May 9 20:39:27 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 May 2025 20:39:27 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:36:07 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects a review comment Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2829592684 From naoto at openjdk.org Fri May 9 20:39:27 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 20:39:27 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com> References: <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com> Message-ID: On Fri, 9 May 2025 20:15:48 GMT, Brian Burkhalter wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects a review comment > > src/java.base/share/classes/java/lang/System.java line 136: > >> 134: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); >> 135: * } >> 136: * Or with a {@link java.util.Scanner Scanner}: > > "Or with" -> "Using a" or "Or using a" for consistency? Up to you. Thanks. That flows better. Corrected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082453780 From bpb at openjdk.org Fri May 9 20:39:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 May 2025 20:39:28 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com> Message-ID: On Fri, 9 May 2025 20:31:51 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/lang/System.java line 136: >> >>> 134: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); >>> 135: * } >>> 136: * Or with a {@link java.util.Scanner Scanner}: >> >> "Or with" -> "Using a" or "Or using a" for consistency? Up to you. > > Thanks. That flows better. Corrected. You're welcome. Re-approved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082457972 From aturbanov at openjdk.org Fri May 9 20:41:11 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 9 May 2025 20:41:11 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`. >> >> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`. >> >> To ensure quality... >> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`. >> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR. > > Markus KARG 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 latest from master branch > - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? > - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs > - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. > - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' > - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() > - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() > - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' > - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? > - Applied changes requested by Alan: Copies chars from this sequence into the given destination array > - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a src/java.base/share/classes/java/lang/CharSequence.java line 313: > 311: * at index {@code dstBegin} and ending at index: > 312: *
      {@code
      > 313:      * dstbegin + (srcEnd-srcBegin) - 1
      
      Shouldn't it be dstBegin?
      
      * dstBegin + (srcEnd-srcBegin) - 1
      
      src/java.base/share/classes/java/lang/CharSequence.java line 329:
      
      > 327:      *             {@code this.length()}.
      > 328:      *             
    • {@code dstBegin+srcEnd-srcBegin} is greater than > 329: * {@code dst.length} I think we should have `.` at the end of each case. Now it's inconsistent ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2082456985 PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2082459665 From liach at openjdk.org Fri May 9 20:46:57 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 20:46:57 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com> On Fri, 9 May 2025 20:28:12 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing bugs, removing dead code make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2216: > 2214: } > 2215: case ModuleMainClassAttribute a -> ((ModuleHeaderDescription) feature).moduleMainClass = a.mainClass().asInternalName(); > 2216: case RuntimeVisibleTypeAnnotationsAttribute a -> {/* do nothing for now */} I think this will make createsymbol created older reference/weakhashmap APIs' type parameter for older releases always have this annotation; but this should be fine. We can fix this for 26. The question is that now their type parameter and the actual parameter uses will see some inconsistent values for releases < 25 in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082465503 From prr at openjdk.org Fri May 9 20:53:52 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 9 May 2025 20:53:52 GMT Subject: RFR: 8356644: Update encoding declaration to UTF-8 In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> Message-ID: On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper. > > I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829627877 From iris at openjdk.org Fri May 9 20:56:52 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 9 May 2025 20:56:52 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:39:27 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects a review comment Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2829630775 From vromero at openjdk.org Fri May 9 20:56:54 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 May 2025 20:56:54 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com> References: <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com> Message-ID: <6zIXpQATpCOWVMh3AdcX0h7_M8H2nqHgK2Ok9ym7sys=.035df212-854c-4b1a-968c-0f3853d13c5a@github.com> On Fri, 9 May 2025 20:43:46 GMT, Chen Liang wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing bugs, removing dead code > > make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2216: > >> 2214: } >> 2215: case ModuleMainClassAttribute a -> ((ModuleHeaderDescription) feature).moduleMainClass = a.mainClass().asInternalName(); >> 2216: case RuntimeVisibleTypeAnnotationsAttribute a -> {/* do nothing for now */} > > I think this will make createsymbol created older reference/weakhashmap APIs' type parameter for older releases always have this annotation; but this should be fine. We can fix this for 26. The question is that now their type parameter and the actual parameter uses will see some inconsistent values for releases < 25 in the future. Jan is taking a look at the changes for CreateSymbols. The change included in this PR is the minimum for the build to pass, I will double check with him if what he is doing will be pushed in a separate PR or as part of this PR, not sure yet. Time is tight and we want this in 25 this is why I decided to move on with this PR even though the CreateSymbols code complete. I forgot to mention this before, sorry ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082482663 From liach at openjdk.org Fri May 9 20:56:53 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 20:56:53 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:39:27 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects a review comment src/java.base/share/classes/java/util/Scanner.java line 81: > 79: * } > 80: * > 81: *

      To read lines from {@link System#in} with {@link System##stdin.encoding Other 2 example paragraphs start with "this code allows..." and I think we should start this paragraph with: (you might need to wrap lines) Suggestion: *

      This code reads lines from {@link System#in} with {@link System##stdin.encoding ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082482111 From rriggs at openjdk.org Fri May 9 21:02:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 May 2025 21:02:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v16] In-Reply-To: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com> Message-ID: On Tue, 6 May 2025 15:43:07 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test This is right pair of methods on Reader to cover the use cases. The names are clear and concise. Some editorial suggestions are included to the text, use as you see fit. I think its clear and complete enough to get the CSR drafted and into the proposed queue for review for JDK 25. src/java.base/share/classes/java/io/Reader.java line 438: > 436: * > 437: * @throws IOException If an I/O error occurs > 438: * Editorial suggestion: Literally/liberally use the description of lines and terminators from String.lines(). Move the implementation limit to the @apiNote and reduce to the maximum size of UTF16 strings. Added the @throw for OOME, to make it clear there is a limit that also applies to readAllLines(). Suggestion: /** * Reads all remaining characters as lines of text. *

      * A line is either a sequence of zero or more characters * followed by a line terminator, or it is a sequence of one or * more characters followed by the end of the stream. * A line does not include the line terminator. *

      * A line terminator is one of the following: * a line feed character {@code "\n"} (U+000A), * a carriage return character {@code "\r"} (U+000D), * or a carriage return followed immediately by a line feed * {@code "\r\n"} (U+000D U+000A). * *

      The method does not close this reader nor its underlying stream. * If an I/O error occurs, the states of the reader and its underlying * stream are unspecified. * * @apiNote * This method is intended for simple cases where it is convenient * to read all remaining characters in a single operation. It is not * intended for reading a large number of characters, for example, greater than 1G. * * @return the remaining characters as lines of text stored in an * unmodifiable {@code List} of strings in the order they are read * * @throws IOException If an I/O error occurs * @throws OutOfMemoryError If the number of remaining characters exceeds the * implementation limit for String. * src/java.base/share/classes/java/io/Reader.java line 470: > 468: * @throws OutOfMemoryError If the remaining content is extremely > 469: * large, for example larger than {@code 2GB} > 470: * Editorial suggestions: Change 'content' to 'characters' to match rest of descriptions. Move mention of implementation limit, 1G to the @apiNote Changed the @throw OOME to just say it exceeds the implementation limit of string. Suggestion: /** * Reads all remaining characters into a string. * *

      This method reads all remaining characters including all line separators * to the end of the stream. The resulting string will contain line * separators as they appear in the stream. * *

      The method does not close this reader nor its underlying stream. * If an I/O error occurs, the states of the reader and its underlying * stream are unspecified. * * @apiNote * This method is intended for simple cases where it is appropriate and * convenient to read all remaining characters into a String. It is not * intended for reading a large number of characters, for example, greater than 1G. * * @return a String containing all remaining characters * * @throws IOException If an I/O error occurs * @throws OutOfMemoryError If the number of remaining characters exceeds the * implementation limit for String. * ------------- PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2829623531 PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2082474638 PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2082474398 From acobbs at openjdk.org Fri May 9 21:09:53 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 9 May 2025 21:09:53 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:25:40 GMT, Vicente Romero wrote: > I was working on something in this line too, just pushed the patch Looks reasonable, a couple of comments... Can't `LintCategory.alias` be `final`? If so I think this obviates the patch to `DetectMutableStaticFields.java`. This is not a general solution to aliasing of lint categories. For example, if someone were to add an alias `filenames` for `path`, then [this code](https://github.com/openjdk/jdk/blob/68a118509a562334eb8c099129d79520041b10cf/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L506-L507) and a few other examples like it would break. Do we care about that? If so then we might want to implement a proper fix for lint aliases as a separate pre-requisite to this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867878715 From liach at openjdk.org Fri May 9 21:09:54 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 21:09:54 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: <-kiskE2-Ejcqxz1znbiJRJ-ZtGdkyZmY7awv7fasv4E=.a52127c6-0339-473b-8018-a97aa93f9efb@github.com> On Fri, 9 May 2025 20:28:12 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing bugs, removing dead code Note: The tests and the core library changes look good to me. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 428: > 426: this.alias = alias; > 427: map.put(option, this); > 428: // we need to do this as forward references are not allowed Suggestion: Redundant comment from last revision. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 454: > 452: public final boolean annotationSuppression; > 453: > 454: public String alias; Suggestion: public final String alias; We are no longer storing LintCategory objects. test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java line 96: > 94: ignore("com/sun/tools/javac/file/JRTIndex", "sharedInstance"); > 95: ignore("com/sun/tools/javac/main/JavaCompiler", "versionRB"); > 96: ignore("com/sun/tools/javac/code/Lint$LintCategory", "alias"); Can remove this once alias is final ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867879980 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082492124 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082496953 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082497326 From rriggs at openjdk.org Fri May 9 21:12:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 May 2025 21:12:53 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:39:27 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects a review comment src/java.base/share/classes/java/lang/System.java line 135: > 133: * {@snippet lang=java : > 134: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); > 135: * } So, ok as far as it goes. Does this example imply that one should always use the 2 arg constructor. When should the 1-arg constructor that uses the defaultEncoding vs the 2-arg constructor with stdin.encoding be used? Is that understood to be described elsewhere? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082502132 From liach at openjdk.org Fri May 9 21:12:53 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 21:12:53 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 21:06:09 GMT, Archie Cobbs wrote: > Do we care about that? If so then we might want to implement a proper fix for lint aliases as a separate pre-requisite to this issue. I think if we do that, we should encapsulate `option` and move all access, such as `option.isSet`, to dedicated methods on `LintCategory`. We are a bit short on time for this, so IMO our best approach is to open a followup issue that we can work on for 26 given the short time to RDP1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867884046 From acobbs at openjdk.org Fri May 9 21:27:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 9 May 2025 21:27:54 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 21:09:46 GMT, Chen Liang wrote: > I think if we do that, we should encapsulate `option` and move all access, such as `option.isSet`, to dedicated methods on `LintCategory`. We are a bit short on time for this, so IMO our best approach is to open a followup issue that we can work on for 26 given the short time to RDP1. That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867906064 From naoto at openjdk.org Fri May 9 21:29:09 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 21:29:09 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v3] In-Reply-To: References: Message-ID: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> > With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects another review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25155/files - new: https://git.openjdk.org/jdk/pull/25155/files/496dd39d..6f8101cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155 PR: https://git.openjdk.org/jdk/pull/25155 From naoto at openjdk.org Fri May 9 21:29:09 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 21:29:09 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: Message-ID: <8dzBg7q2XBJFz4Yajv7C-odescuIL8Qe2xterGxOZ98=.7fc22c24-d9d6-4d56-ade0-fcd9de470a5e@github.com> On Fri, 9 May 2025 21:10:02 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects a review comment > > src/java.base/share/classes/java/lang/System.java line 135: > >> 133: * {@snippet lang=java : >> 134: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); >> 135: * } > > So, ok as far as it goes. Does this example imply that one should always use the 2 arg constructor. > When should the 1-arg constructor that uses the defaultEncoding vs the 2-arg constructor with stdin.encoding be used? > Is that understood to be described elsewhere? For reading from `System.in`, yes. For other cases, depends on the user's situation. This is the first to modify our documents to guide users as `stdin.encoding` is a new property. There are some descriptions for `System.out` and `System.err` in the JEP 400 though. Probably we will need to update the JEP too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082519023 From naoto at openjdk.org Fri May 9 21:29:09 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 21:29:09 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:53:42 GMT, Chen Liang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects a review comment > > src/java.base/share/classes/java/util/Scanner.java line 81: > >> 79: * } >> 80: * >> 81: *

      To read lines from {@link System#in} with {@link System##stdin.encoding > > Other 2 example paragraphs start with "this code allows..." and I think we should start this paragraph with: (you might need to wrap lines) > Suggestion: > > *

      This code reads lines from {@link System#in} with {@link System##stdin.encoding Thanks. Modified ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082520238 From rriggs at openjdk.org Fri May 9 21:50:58 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 May 2025 21:50:58 GMT Subject: Integrated: 8351443: Improve robustness of StringBuilder In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs wrote: > Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. > Support methods are static, designed to pass all values as arguments and return a value. > > The value byte array is reallocated under 3 conditions: > - Increasing the capacity with the same encoder > - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 > - Inflation with the same capacity > > Added StressSBTest to exercise public instance methods of StringBuilder. This pull request has now been integrated. Changeset: 8fadf295 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/8fadf295b0ba720a5bc728c6b4d159e60447de97 Stats: 1010 lines in 8 files changed: 733 ins; 68 del; 209 mod 8351443: Improve robustness of StringBuilder Reviewed-by: liach, rgiulietti, bchristi, jpai ------------- PR: https://git.openjdk.org/jdk/pull/24967 From rgiulietti at openjdk.org Fri May 9 22:34:48 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 9 May 2025 22:34:48 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v8] In-Reply-To: References: Message-ID: > See the JBS bug for some details. Raffaello Giulietti 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: - Added javadoc to refer to the grammar in j.l.Double. - Merge branch 'master' into 8343829 - Make some static arrays @Stable. - Remove unused BIG_DECIMAL_EXPONENT - Merge branch 'master' into 8343829 - Merge branch 'master' into 8343829 - Redacted comments. - Merge branch 'master' into 8343829 - Minors in comments. - Removed repeated comment. - ... and 2 more: https://git.openjdk.org/jdk/compare/ad02a4cb...9d14562a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22737/files - new: https://git.openjdk.org/jdk/pull/22737/files/41d070ec..9d14562a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=06-07 Stats: 20641 lines in 746 files changed: 12447 ins; 4900 del; 3294 mod Patch: https://git.openjdk.org/jdk/pull/22737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737 PR: https://git.openjdk.org/jdk/pull/22737 From liach at openjdk.org Fri May 9 22:41:58 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 22:41:58 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 21:24:58 GMT, Archie Cobbs wrote: > That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer. Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867998674 From rgiulietti at openjdk.org Fri May 9 22:48:34 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 9 May 2025 22:48:34 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v9] In-Reply-To: References: Message-ID: > See the JBS bug for some details. Raffaello Giulietti 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: - Removed useless comment. - Merge branch 'master' into 8343829 - Added javadoc to refer to the grammar in j.l.Double. - Merge branch 'master' into 8343829 - Make some static arrays @Stable. - Remove unused BIG_DECIMAL_EXPONENT - Merge branch 'master' into 8343829 - Merge branch 'master' into 8343829 - Redacted comments. - Merge branch 'master' into 8343829 - ... and 4 more: https://git.openjdk.org/jdk/compare/e19291a2...88fe2c08 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22737/files - new: https://git.openjdk.org/jdk/pull/22737/files/9d14562a..88fe2c08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=07-08 Stats: 1064 lines in 14 files changed: 761 ins; 81 del; 222 mod Patch: https://git.openjdk.org/jdk/pull/22737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737 PR: https://git.openjdk.org/jdk/pull/22737 From liach at openjdk.org Fri May 9 23:02:00 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 23:02:00 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v9] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:48:34 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti 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: > > - Removed useless comment. > - Merge branch 'master' into 8343829 > - Added javadoc to refer to the grammar in j.l.Double. > - Merge branch 'master' into 8343829 > - Make some static arrays @Stable. > - Remove unused BIG_DECIMAL_EXPONENT > - Merge branch 'master' into 8343829 > - Merge branch 'master' into 8343829 > - Redacted comments. > - Merge branch 'master' into 8343829 > - ... and 4 more: https://git.openjdk.org/jdk/compare/e0e999c4...88fe2c08 Took a look over the string parsing part. Not professional enough about floating numbers. src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1964: > 1962: > 1963: /* Skip opt [FfDd]? suffix. */ > 1964: if (i < len && (((ch = in.charAt(i) | 0b10_0000)) == 'f' || ch == 'd')) { Is it really right to ignore these suffix for all ix values? src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2006: > 2004: * > 2005: * |lz |pt |tnz |stop > 2006: * 0000000012345600000023.4567000000000 Suggestion: * |lz |pt |tnz |stop * 0000000012345600000023.4567000000000 src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2265: > 2263: > 2264: /* Arithmetically "appends the digit" ch to v >= 0, clamping at 10^10. */ > 2265: private static long appendDigit(long v, int ch) { Since this appends only decimal digit, should we name it `appendDecDegit`? In the use site we already note all exponents are decimals. ------------- PR Review: https://git.openjdk.org/jdk/pull/22737#pullrequestreview-2829815281 PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2082593368 PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2082588752 PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2082592192 From naoto at openjdk.org Fri May 9 23:18:50 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 May 2025 23:18:50 GMT Subject: RFR: 8356644: Update encoding declaration to UTF-8 In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> Message-ID: On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper. > > I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829881137 From bchristi at openjdk.org Fri May 9 23:28:25 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 9 May 2025 23:28:25 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Message-ID: For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. Automated test results are omitted as expected. ------------- Commit messages: - add @requires Changes: https://git.openjdk.org/jdk/pull/25163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356107 Stats: 20 lines in 4 files changed: 4 ins; 10 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25163/head:pull/25163 PR: https://git.openjdk.org/jdk/pull/25163 From almatvee at openjdk.org Fri May 9 23:42:26 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 May 2025 23:42:26 GMT Subject: RFR: 8356664: [macos] AppContentTest fails after JDK-8352480 Message-ID: - Regression from JDK-8352480. - On macOS we should create `Links` folder under `Resources`. Which means `--app-content` should point to `app-content/Resources` and not to `app-content/Resources/Links`. ------------- Commit messages: - 8356664: [macos] AppContentTest fails after JDK-8352480 Changes: https://git.openjdk.org/jdk/pull/25164/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25164&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356664 Stats: 7 lines in 1 file changed: 4 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25164/head:pull/25164 PR: https://git.openjdk.org/jdk/pull/25164 From bpb at openjdk.org Fri May 9 23:45:51 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 May 2025 23:45:51 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property In-Reply-To: References: Message-ID: On Fri, 9 May 2025 23:23:27 GMT, Brent Christian wrote: > For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. > > Automated test results are omitted as expected. test/jdk/java/lang/RuntimeTests/exec/Space.java line 42: > 40: throw new RuntimeException("Extra space in command."); > 41: } catch (IOException e) { > 42: // not Win NT - cmd doesnt exist As long as you're there: `doesnt` -> `doesn't`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25163#discussion_r2082640179 From naoto at openjdk.org Sat May 10 00:27:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 10 May 2025 00:27:51 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property In-Reply-To: References: Message-ID: On Fri, 9 May 2025 23:23:27 GMT, Brent Christian wrote: > For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. > > Automated test results are omitted as expected. I think `test/jdk/java/lang/System/NonAnsiFileEncodingTest.java` can be removed, as it does not provide any value today :- - It intends to run on Windows 2000/XP, which are both no longer supported. - The test requires manual set up to one of those locales on Windows. - `file.encoding` is always UTF-8 since JDK 18. (and it is actually comparing it with "utf-8" in case-insensitive way) ------------- PR Review: https://git.openjdk.org/jdk/pull/25163#pullrequestreview-2829970870 From asemenyuk at openjdk.org Sat May 10 00:58:02 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 10 May 2025 00:58:02 GMT Subject: RFR: 8356664: [macos] AppContentTest fails after JDK-8352480 In-Reply-To: References: Message-ID: On Fri, 9 May 2025 23:36:44 GMT, Alexander Matveev wrote: > - Regression from JDK-8352480. > - On macOS we should create `Links` folder under `Resources`. Which means `--app-content` should point to `app-content/Resources` and not to `app-content/Resources/Links`. Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25164#pullrequestreview-2830001571 From almatvee at openjdk.org Sat May 10 03:11:02 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 10 May 2025 03:11:02 GMT Subject: Integrated: 8356664: [macos] AppContentTest fails after JDK-8352480 In-Reply-To: References: Message-ID: On Fri, 9 May 2025 23:36:44 GMT, Alexander Matveev wrote: > - Regression from JDK-8352480. > - On macOS we should create `Links` folder under `Resources`. Which means `--app-content` should point to `app-content/Resources` and not to `app-content/Resources/Links`. This pull request has now been integrated. Changeset: fa7c5a65 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/fa7c5a65ba62da9b6598d484db923119ace0cf90 Stats: 7 lines in 1 file changed: 4 ins; 1 del; 2 mod 8356664: [macos] AppContentTest fails after JDK-8352480 Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/25164 From rgiulietti at openjdk.org Sat May 10 10:02:59 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 10 May 2025 10:02:59 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v9] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:58:19 GMT, Chen Liang wrote: >> Raffaello Giulietti 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: >> >> - Removed useless comment. >> - Merge branch 'master' into 8343829 >> - Added javadoc to refer to the grammar in j.l.Double. >> - Merge branch 'master' into 8343829 >> - Make some static arrays @Stable. >> - Remove unused BIG_DECIMAL_EXPONENT >> - Merge branch 'master' into 8343829 >> - Merge branch 'master' into 8343829 >> - Redacted comments. >> - Merge branch 'master' into 8343829 >> - ... and 4 more: https://git.openjdk.org/jdk/compare/8862cc91...88fe2c08 > > src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1964: > >> 1962: >> 1963: /* Skip opt [FfDd]? suffix. */ >> 1964: if (i < len && (((ch = in.charAt(i) | 0b10_0000)) == 'f' || ch == 'd')) { > > Is it really right to ignore these suffix for all ix values? Although this might seem surprising, yes, it is right. This is what the `[Double|Float].valueOf(String)` specs say (these are the "main clients" of this class): > Note that trailing format specifiers, [...] do not influence the results of this method. > src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2006: > >> 2004: * >> 2005: * |lz |pt |tnz |stop >> 2006: * 0000000012345600000023.4567000000000 > > Suggestion: > > * |lz |pt |tnz |stop > * 0000000012345600000023.4567000000000 Addressed. > src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2265: > >> 2263: >> 2264: /* Arithmetically "appends the digit" ch to v >= 0, clamping at 10^10. */ >> 2265: private static long appendDigit(long v, int ch) { > > Since this appends only decimal digit, should we name it `appendDecDegit`? In the use site we already note all exponents are decimals. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2083096389 PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2083096060 PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2083096070 From rgiulietti at openjdk.org Sat May 10 10:08:39 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 10 May 2025 10:08:39 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v10] In-Reply-To: References: Message-ID: <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com> > See the JBS bug for some details. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Addressed reviewer comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22737/files - new: https://git.openjdk.org/jdk/pull/22737/files/88fe2c08..dbb5a272 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=08-09 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737 PR: https://git.openjdk.org/jdk/pull/22737 From swen at openjdk.org Sat May 10 11:20:35 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 10 May 2025 11:20:35 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via UTF16::compress & Unsafe::copyMemory [v5] In-Reply-To: References: Message-ID: > In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string. > > For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - copyright - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 # Conflicts: # src/java.base/share/classes/java/lang/AbstractStringBuilder.java - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 # Conflicts: # src/java.base/share/classes/java/lang/AbstractStringBuilder.java - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504 # Conflicts: # src/java.base/share/classes/java/lang/StringUTF16.java - putCharsUnchecked - copyright - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[]) - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[]) - add append(char[]) benchmark ------------- Changes: https://git.openjdk.org/jdk/pull/24773/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=04 Stats: 42 lines in 2 files changed: 36 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24773.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24773/head:pull/24773 PR: https://git.openjdk.org/jdk/pull/24773 From duke at openjdk.org Sat May 10 11:53:38 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 10 May 2025 11:53:38 GMT Subject: RFR: 8077587: BigInteger Roots [v5] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'openjdk:master' into nth-root-branch - Update to resolve conflicts - An optimization - Correct unsigned division - Correct typo in comment - No need to avoid overflow - Merge branch 'openjdk:master' into BigInteger-nth-root - Optimized nth root iteration loop - Systematization of special cases in BigInteger.pow(int) - Some optimizations - ... and 34 more: https://git.openjdk.org/jdk/compare/fa7c5a65...4729a468 ------------- Changes: https://git.openjdk.org/jdk/pull/24898/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=04 Stats: 136 lines in 1 file changed: 136 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From duke at openjdk.org Sat May 10 11:57:32 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 10 May 2025 11:57:32 GMT Subject: RFR: 8077587: BigInteger Roots [v6] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch - Restore nthRoot() public methods in BigInteger.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/4729a468..823d2f63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=04-05 Stats: 74 lines in 1 file changed: 74 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From liach at openjdk.org Sat May 10 14:34:57 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 10 May 2025 14:34:57 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:19:11 GMT, Joe Darcy wrote: >> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. > >> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. > > Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch. See #25124. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2083210454 From acobbs at openjdk.org Sat May 10 15:27:52 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 10 May 2025 15:27:52 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:39:19 GMT, Chen Liang wrote: > Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach. OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases). @vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868963258 From vromero at openjdk.org Sat May 10 15:31:45 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 15:31:45 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v10] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: integrating code from Archie ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/ea631161..a9a53783 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=08-09 Stats: 151 lines in 7 files changed: 98 ins; 25 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From liach at openjdk.org Sat May 10 15:33:52 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 10 May 2025 15:33:52 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:28:12 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing bugs, removing dead code Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868971783 From vromero at openjdk.org Sat May 10 15:37:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 15:37:51 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 15:24:52 GMT, Archie Cobbs wrote: >>> That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer. >> >> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach. > >> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach. > > OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases). > > @vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks! I have integrated @archiecobbs's code. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868972990 From vromero at openjdk.org Sat May 10 15:37:52 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 15:37:52 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 15:31:17 GMT, Chen Liang wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing bugs, removing dead code > > Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration. > > Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach. > > OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases). > > @vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks! heh, I was doing the same, thanks anyway :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868973659 From acobbs at openjdk.org Sat May 10 15:43:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 10 May 2025 15:43:54 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 15:35:16 GMT, Vicente Romero wrote: > heh, I was doing the same, thanks anyway :) Awesome, thanks! Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868976097 From nbenalla at openjdk.org Sat May 10 15:44:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sat, 10 May 2025 15:44:51 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 14:32:10 GMT, Chen Liang wrote: >>> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. >> >> Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch. > > See #25124. Thanks Chen! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2083223695 From acobbs at openjdk.org Sat May 10 16:00:58 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 10 May 2025 16:00:58 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 15:31:17 GMT, Chen Liang wrote: > Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration. Good point... I prototyped that in commit be160a3261b. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868989327 From vromero at openjdk.org Sat May 10 16:05:59 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 16:05:59 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v10] In-Reply-To: References: Message-ID: <_tMq_VvOY6ER-1qTRe7TDbBBCPWFW7080gRydehdBME=.7131f939-c8dc-4443-8c44-ce31fbc227a3@github.com> On Sat, 10 May 2025 15:31:45 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > integrating code from Archie > > Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration. > > Good point... I prototyped that in commit [be160a3](https://github.com/openjdk/jdk/commit/be160a3261bebcbd09c350a3feda6e696f26a3e3). thanks! I will integrate it ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868993387 From vromero at openjdk.org Sat May 10 16:05:59 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 16:05:59 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 15:41:18 GMT, Archie Cobbs wrote: > > heh, I was doing the same, thanks anyway :) > > Awesome, thanks! > > Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes. thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868993581 From vromero at openjdk.org Sat May 10 16:39:38 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 16:39:38 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v11] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - additional changes from Archie - removing dead code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/a9a53783..973307eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=09-10 Stats: 66 lines in 7 files changed: 16 ins; 35 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Sat May 10 16:39:38 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 16:39:38 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v10] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 15:31:45 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > integrating code from Archie I integrated the rest of Archie's changes, thanks guys for the contributions and the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869007212 From vromero at openjdk.org Sat May 10 16:50:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 16:50:51 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 16:03:37 GMT, Vicente Romero wrote: > > heh, I was doing the same, thanks anyway :) > > Awesome, thanks! > > Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes. thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869011552 From asemenyuk at openjdk.org Sat May 10 19:02:45 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 10 May 2025 19:02:45 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4] In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> Message-ID: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> > Refactor jpackage to separate the configuration and execution phases. > At the configuration phase, jpackage parses command-line arguments and validates them. > At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. > > There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. > > This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. > > The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". > > Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. > > jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html > > **Functional changes** > jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. > > - Minimize copying of the source app image when doing native packaging. > > Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. > > - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. > > post- and pre- install PKG scripts for SimplePackageTest package before and after the change: >

    • ScriptNewOld
      > > > > > > > > References: Message-ID: On Sat, 10 May 2025 16:39:38 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - additional changes from Archie > - removing dead code As much as I dislike streams, I think we will probably keep them for their conciseness except this one, which made things less concise. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 422: > 420: ArrayList optionList = new ArrayList<>(1 + aliases.length); > 421: optionList.add(option); > 422: Stream.of(aliases).forEach(optionList::add); Suggestion: Collections.addAll(optionList, aliases); ------------- PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2831052002 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2083275193 From acobbs at openjdk.org Sat May 10 20:04:52 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 10 May 2025 20:04:52 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v11] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 19:32:16 GMT, Chen Liang wrote: >> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: >> >> - additional changes from Archie >> - removing dead code > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 422: > >> 420: ArrayList optionList = new ArrayList<>(1 + aliases.length); >> 421: optionList.add(option); >> 422: Stream.of(aliases).forEach(optionList::add); > > Suggestion: > > Collections.addAll(optionList, aliases); Wow, somehow I never knew `Collections.addAll()` existed. Thanks for the tip - that's simpler. (I'll let @vicente-romero-oracle fix it.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2083280028 From vromero at openjdk.org Sat May 10 20:28:39 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 20:28:39 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v12] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/973307eb..63fd151f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Sat May 10 20:28:39 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 20:28:39 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v11] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 19:36:52 GMT, Chen Liang wrote: > As much as I dislike streams, I think we will probably keep them for their conciseness except this one, which made things less concise. thanks! committed ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869141760 From acobbs at openjdk.org Sat May 10 20:40:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 10 May 2025 20:40:54 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v12] In-Reply-To: References: Message-ID: <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com> On Sat, 10 May 2025 20:28:39 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang FYI, this issue now effectively fixes [JDK-7004476 Lint.LintCategory should support aliases](https://bugs.openjdk.org/browse/JDK-7004476), which happened to be closed as "Rejected" on Monday. Not sure if anything needs to be done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869145567 From liach at openjdk.org Sat May 10 20:43:20 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 10 May 2025 20:43:20 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13] In-Reply-To: References: Message-ID: > The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. > > The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. > > The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. > > Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: - Jaikiran comments, improve thread reference tracking, more documents - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove - Update src/java.base/share/classes/java/lang/ClassValue.java Co-authored-by: Shaojin Wen - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove - Reviews from viktor - Rewrite impl to follow the new simplified spec - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove - Try to simplify the model - use the finish of computeValue - Test updates - remove repetition, test case for no stale installation - Fix incorrect promise removal when unnecessary and add regression test - ... and 12 more: https://git.openjdk.org/jdk/compare/c7a6f415...e24a1fd7 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24043/files - new: https://git.openjdk.org/jdk/pull/24043/files/3d68f09a..e24a1fd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=11-12 Stats: 27783 lines in 969 files changed: 17000 ins; 6516 del; 4267 mod Patch: https://git.openjdk.org/jdk/pull/24043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043 PR: https://git.openjdk.org/jdk/pull/24043 From vromero at openjdk.org Sat May 10 22:48:52 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 10 May 2025 22:48:52 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v12] In-Reply-To: <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com> References: <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com> Message-ID: <7sbyHtJrLFM2tyXex553OXX12Mch_Q2mXwJg3qKSEqk=.e568d019-99d3-4c04-8ad6-0c6d071aef62@github.com> On Sat, 10 May 2025 20:38:36 GMT, Archie Cobbs wrote: > FYI, this issue now effectively fixes [JDK-7004476 Lint.LintCategory should support aliases](https://bugs.openjdk.org/browse/JDK-7004476), which happened to be closed as "Rejected" on Monday. Not sure if anything needs to be done. I guess we can add a note to that bug once this one goes through ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869184983 From godmlzkf1 at naver.com Sun May 11 08:21:21 2025 From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=) Date: Sun, 11 May 2025 17:21:21 +0900 Subject: =?utf-8?B?QXJyYXlMaXN0IHByaW50IGNhcGFjaXR5?= Message-ID: <5b359bff7665f93daacbe7a210bedd3a@cweb004.nm> Hi It seems that there is no code to print Capacity in ArrayList. Vector, a friend of ArrayList, can be printed through capacity(). I want to add code to print Capacity of ArrayList as elementData.length. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun May 11 08:42:41 2025 From: duke at openjdk.org (Abhishek N) Date: Sun, 11 May 2025 08:42:41 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() [v2] In-Reply-To: References: Message-ID: > Create a Test case to have special cases coverage for currency.getInstance(). > > The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API. > > test results: > > jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Test results: passed: 1 > Report written to JTreport\html\report.html > Results written to JTwork Abhishek N has updated the pull request incrementally with one additional commit since the last revision: correcting jtreg header order, add meaningful comments for each test methods and properties file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25057/files - new: https://git.openjdk.org/jdk/pull/25057/files/77ae234a..7207e7c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25057&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25057&range=00-01 Stats: 24 lines in 3 files changed: 17 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25057/head:pull/25057 PR: https://git.openjdk.org/jdk/pull/25057 From forax at univ-mlv.fr Sun May 11 10:03:28 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 11 May 2025 12:03:28 +0200 (CEST) Subject: ArrayList print capacity In-Reply-To: <5b359bff7665f93daacbe7a210bedd3a@cweb004.nm> References: <5b359bff7665f93daacbe7a210bedd3a@cweb004.nm> Message-ID: <1145605941.260696498.1746957808830.JavaMail.zimbra@univ-eiffel.fr> Hello, this is not an overlook, the less you expose (make public), the easier it is to change the implementation in the future. Also, the collection API was design to avoid (if possible) to have more public methods in the implementation (ArrayList) than you have in the interface (List). So as a user, you can always use a List as parameter of a public method instead of an ArrayList. regards, R?mi > From: "???" > To: "core-libs-dev" > Sent: Sunday, May 11, 2025 10:21:21 AM > Subject: ArrayList print capacity > Hi > It seems that there is no code to print Capacity in ArrayList. > Vector, a friend of ArrayList, can be printed through capacity(). > I want to add code to print Capacity of ArrayList as elementData.length. > Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun May 11 10:16:17 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 11 May 2025 12:16:17 +0200 (CEST) Subject: Unnecessary logic is added to removeFirst and removeLast of ArrayList. In-Reply-To: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm> References: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm> Message-ID: <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr> > From: "???" > To: "core-libs-dev" > Sent: Friday, May 9, 2025 10:33:30 AM > Subject: Unnecessary logic is added to removeFirst and removeLast of ArrayList. > Hi. > In removeFirst, if size is not 0, the logic is the same as the remove logic. > removeLast also has the same logic as remove when size is not exceeded. > I want to fix this. > thank you. Duplicating the logic is bad in some cases and not that bad in other cases. Here ArrayList is one of the most used class in Java (with String and HashMap), it is heavily optimized (to the point where the generated assembly code by the JITs is checked by humans), so duplicating the logic is not a bad idea, >From a documentation POV, you do not have to jump through many methods if you want to see the implementation and in terms of performance, you want the inlining to be done by hand because the methods of ArrayList are usually deep in the call graph, so you may reach the inlining threshold right inside removeFirst(). In general, you do not optimize applications and libraries the same way. Usually, you do not optimize application code that often but for a library, if a lot of people are using it, it may worth to spend time to optimize for the benefit of everybody. regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From syan at openjdk.org Sun May 11 14:36:50 2025 From: syan at openjdk.org (SendaoYan) Date: Sun, 11 May 2025 14:36:50 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > generate_unsafecopy_common_error_exit Changes requested by syan (Committer). test/micro/org/openjdk/bench/java/lang/foreign/MemorySegmentFillUnsafe.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. 2025 maybe more suitable ------------- PR Review: https://git.openjdk.org/jdk/pull/25147#pullrequestreview-2831415179 PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2083540891 From liach at openjdk.org Sun May 11 15:17:55 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 11 May 2025 15:17:55 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v3] In-Reply-To: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> References: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> Message-ID: On Fri, 9 May 2025 21:29:09 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects another review comment I looked for the other mentions of System.in without references to stdin.encoding, notably: 1. FileDescriptor.in: Unfortunately FileInputStream(FileDescriptor) has no overload that supports custom charsets. We should probably document both on this FD and that constructor. 2. JShell.in and JavaShellToolBuilder.in 3. A few usages in security, like password reading in sun.security.tools.keytool.Main, or javax.security.auth.callback.CallbackHandler ------------- PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2869933924 From chen.l.liang at oracle.com Sun May 11 15:41:25 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sun, 11 May 2025 15:41:25 +0000 Subject: Unnecessary logic is added to removeFirst and removeLast of ArrayList. In-Reply-To: <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr> References: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm> <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr> Message-ID: > where the generated assembly code by the JITs is checked by humans Is it? I have heard anecdotes that it is still slower than direct array usage, presumably due to the modCount tracking mechanism. Don't know if escape analysis and the resulting stack allocation in the compiled code eliminates that field. ________________________________ From: core-libs-dev on behalf of Remi Forax Sent: Sunday, May 11, 2025 5:16 AM To: ??? Cc: core-libs-dev Subject: Re: Unnecessary logic is added to removeFirst and removeLast of ArrayList. Duplicating the logic is bad in some cases and not that bad in other cases. Here ArrayList is one of the most used class in Java (with String and HashMap), it is heavily optimized (to the point where the generated assembly code by the JITs is checked by humans), so duplicating the logic is not a bad idea, From a documentation POV, you do not have to jump through many methods if you want to see the implementation and in terms of performance, you want the inlining to be done by hand because the methods of ArrayList are usually deep in the call graph, so you may reach the inlining threshold right inside removeFirst(). In general, you do not optimize applications and libraries the same way. Usually, you do not optimize application code that often but for a library, if a lot of people are using it, it may worth to spend time to optimize for the benefit of everybody. regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Sun May 11 16:48:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 11 May 2025 16:48:52 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v3] In-Reply-To: References: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> Message-ID: On Sun, 11 May 2025 15:15:17 GMT, Chen Liang wrote: > 1. FileDescriptor.in: Unfortunately FileInputStream(FileDescriptor) has no overload that supports custom charsets. We should probably document both on this FD and that constructor. FYI, FileInputStream is an InputStream so reading bytes, not chars, and should not say anything about Chrasets. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2869974486 From alanb at openjdk.org Sun May 11 17:09:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 11 May 2025 17:09:52 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7] In-Reply-To: References: Message-ID: <0dcTQBkhjRuEbzel6ux6ZX6pGg9BgVWSbSXYI5QI3L4=.0f7b1564-ede4-4c43-b3a2-29fb0b54d8cf@github.com> On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix merge Marked as reviewed by alanb (Reviewer). I ran tier1-6 so I think we are good and there isn't anything left to bring over from the loom repo. There are a few files that will need their copyright header updated before integration. The CSR also needs to be finalized. ------------- PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2831452149 PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2870007648 From liach at openjdk.org Sun May 11 17:37:50 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 11 May 2025 17:37:50 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v3] In-Reply-To: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> References: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> Message-ID: On Fri, 9 May 2025 21:29:09 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects another review comment Oops, I meant the wrong constructor - the `FileReader(FileDescriptor fd)` one that does not have a charset overload. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2870021180 From forax at univ-mlv.fr Sun May 11 17:43:53 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 11 May 2025 19:43:53 +0200 (CEST) Subject: Unnecessary logic is added to removeFirst and removeLast of ArrayList. In-Reply-To: References: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm> <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <833229561.260895323.1746985433257.JavaMail.zimbra@univ-eiffel.fr> > From: "Chen Liang" > To: "Remi Forax" > Cc: "core-libs-dev" > Sent: Sunday, May 11, 2025 5:41:25 PM > Subject: Re: Unnecessary logic is added to removeFirst and removeLast of > ArrayList. > > where the generated assembly code by the JITs is checked by humans > Is it? At least, it was true during the Java 8 timeframe :) At that time, i was involved in the effort of updating the collection API to use lambdas. I suppose that the introduction of value types will trigger a similar effort (even if it seems less easier to use value types to optimize the collection API because the spec allows a lot of modifications). > I have heard anecdotes that it is still slower than direct array usage, > presumably due to the modCount tracking mechanism. Don't know if escape > analysis and the resulting stack allocation in the compiled code eliminates > that field. I've recently bench array vs arraylist (while testing the performance of StableValue.list()), for 1024 string ("0", "1", "2" etc), on my Mac M2 air, i get // Benchmark Mode Cnt Score Error Units // StableListBench.array avgt 5 427,889 ? 1,553 ns/op // StableListBench.arraylist avgt 5 605,542 ? 1,372 ns/op // StableListBench.asList avgt 5 572,532 ? 2,574 ns/op // StableListBench.list_of avgt 5 615,069 ? 0,341 ns/op // StableListBench.stable_list avgt 5 1897,948 ? 2,119 ns/op with @Benchmark public int list_of () { var sum = 0 ; for ( var item : listof ) { sum += item .length(); } return sum ; } So at least, I can say that on my mac, direct array usage is more efficient. (BTW, using an arraylist is more effcient than using List.of()/List.copyOf() because ListN inherits from the iterator of AbstractList instead of having its own). regards, R?mi > From: core-libs-dev on behalf of Remi Forax > > Sent: Sunday, May 11, 2025 5:16 AM > To: ??? > Cc: core-libs-dev > Subject: Re: Unnecessary logic is added to removeFirst and removeLast of > ArrayList. > Duplicating the logic is bad in some cases and not that bad in other cases. > Here ArrayList is one of the most used class in Java (with String and HashMap), > it is heavily optimized (to the point where the generated assembly code by the > JITs is checked by humans), so duplicating the logic is not a bad idea, > From a documentation POV, you do not have to jump through many methods if you > want to see the implementation and in terms of performance, you want the > inlining to be done by hand because the methods of ArrayList are usually deep > in the call graph, so you may reach the inlining threshold right inside > removeFirst(). > In general, you do not optimize applications and libraries the same way. > Usually, you do not optimize application code that often but for a library, if a > lot of people are using it, it may worth to spend time to optimize for the > benefit of everybody. > regards, > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From j3graham at gmail.com Sun May 11 18:37:15 2025 From: j3graham at gmail.com (Johannes Graham) Date: Sun, 11 May 2025 14:37:15 -0400 Subject: Optimization of BigDecimal.valueOf(double) Message-ID: This is somewhat of followup to a conversation a few months ago [1] regarding the non-existence of a BigDecimal.valueOf(float) method. While it wasn't the primary issue, the matter of performance did come up. Based on that, I have been experimenting with making some improvements there. I have a draft PR [2] open that leads to an improvement of around 6x for me. If there is interest in this change, I would need someone to open a JIRA for this. Thanks, Johannes [1] https://mail.openjdk.org/pipermail/core-libs-dev/2025-January/139074.html [2] https://github.com/openjdk/jdk/pull/25173 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Sun May 11 19:13:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 11 May 2025 19:13:52 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v12] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 20:28:39 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang I'm coming here from "far away" and am not familiar with all the work leading up to this proposal, so maybe there's some rationale that I don't know about. (I did look, but didn't find anything other than this draft JEP: https://openjdk.org/jeps/8340476. And that doesn't really deal with the issue I discuss below.) Keeping that in mind, I'm surprised by some parts of this change. Specifically 2) Apply the annotation to the following: - The referent parameter of all constructors in classes PhantomReference, SoftReference, and WeakReference ... - The type parameter T of Reference, PhantomReference, SoftReference, WeakReference, and ReferenceQueue I wonder why it is not sufficient to apply the annotation to the type parameter T of Reference, and leave it at that? The type parameter of the subclasses is passed as the type parameter to Reference in the `extends` clause. I would expect if the type parameter for a subclass didn't satisfy the annotation that would be noticed there. Indeed, if that isn't the case then many uses of Reference types won't benefit from this annotation, since they are using classes derived from one of those subclasses and won't have this internal annotation. That would significantly limit the utility of this annotation in this area. Similarly, I wonder why the constructors need the annotation. And why don't the return type of `get` or the argument for `Reference::refersTo` need it? (Maybe because those values can be null? But there's nothing that prevents passing null to one of the constructors. It's not very useful to do so, but not forbidden. I've even seen a use-case for doing so.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2870055928 From duke at openjdk.org Sun May 11 21:54:56 2025 From: duke at openjdk.org (Luca Kellermann) Date: Sun, 11 May 2025 21:54:56 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis wrote: > While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. > > For example this is not valid Java (and protected) by javac: > > > byte b = 1; > switch (b) { > case String s -> System.out.println("How did we get here? byte is " + s.getClass()); > } > > > but this is a valid call (and not protected): > > > CallSite shortSwitch = SwitchBootstraps.typeSwitch( > MethodHandles.lookup(), > "", > MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int > String.class); > > > The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. > > This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 782: > 780: else if (selectorType.equals(targetType) || > 781: (targetType.isPrimitive() && selectorType.isPrimitive() && > 782: ((selectorType.equals(byte.class) && !targetType.equals(char.class)) || Will `unconditionalExactnessMatch(byte.class, boolean.class` return `true`? I think it shouldn't, even if `isNotValidPair` is called before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2083628555 From jpai at openjdk.org Mon May 12 01:11:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 May 2025 01:11:00 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with empty file data [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:07:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799? >> >> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix. >> >> tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's suggestion - use assertThrows() Hello Alan, > > > I'll run some experiments and see what it shows up. > > > > > > Thanks as that will help inform as to whether this will need a compatibility knob. > > The crc is calculated as part of the write of the entry and I have not seen any cases, where the CRC is not 0 for a directory/ 0-length file In addition to Lance's investigation, I also ran some experiments against a large number of jars. The results show that none of them are impacted by this change. More specifically, like Lance notes, the CRC values for the case of empty file data (or directory), the CRC is always 0. So the proposed change in this PR isn't expected to run into a JAR/ZIP which will trigger an exception when this CRC is now checked for such entries. So I think we won't need a configuration property for this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2870444933 From jpai at openjdk.org Mon May 12 01:20:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 May 2025 01:20:07 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:35:04 GMT, Andrey Turbanov wrote: >> Markus KARG 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 latest from master branch >> - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted? >> - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs >> - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since. >> - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.' >> - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars() >> - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars() >> - Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)' >> - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted? >> - Applied changes requested by Alan: Copies chars from this sequence into the given destination array >> - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a > > src/java.base/share/classes/java/lang/CharSequence.java line 313: > >> 311: * at index {@code dstBegin} and ending at index: >> 312: *
      {@code
      >> 313:      * dstbegin + (srcEnd-srcBegin) - 1
      > 
      > Shouldn't it be dstBegin?
      > 
      > * dstBegin + (srcEnd-srcBegin) - 1
      
      Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2083686557
      
      From liach at openjdk.org  Mon May 12 02:22:27 2025
      From: liach at openjdk.org (Chen Liang)
      Date: Mon, 12 May 2025 02:22:27 GMT
      Subject: RFR: 8356694: Removed unused subclass audits in
       ObjectInput/OutputStream
      Message-ID: 
      
      These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
      
      Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress
      
      -------------
      
      Commit messages:
       - 8356694: Removed unused subclass audits in ObjectInput/OutputStream
      
      Changes: https://git.openjdk.org/jdk/pull/25174/files
        Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25174&range=00
        Issue: https://bugs.openjdk.org/browse/JDK-8356694
        Stats: 71 lines in 2 files changed: 0 ins; 69 del; 2 mod
        Patch: https://git.openjdk.org/jdk/pull/25174.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25174/head:pull/25174
      
      PR: https://git.openjdk.org/jdk/pull/25174
      
      From alanb at openjdk.org  Mon May 12 06:26:56 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 06:26:56 GMT
      Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
       all lines [v16]
      In-Reply-To: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
      References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
       <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
      Message-ID: <82sPe3Kc8mt9lhFzvvgWkQNWjVwSnRnfZcluBehOfZI=.a124a4bc-82ee-4105-a4de-94bb7eca7cb2@github.com>
      
      On Tue, 6 May 2025 15:43:07 GMT, Brian Burkhalter  wrote:
      
      >> Implement the requested methods and add a test thereof.
      >
      > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test
      
      For the APIs then both methods will need to specify what they return when already at end of stream, does readAllAsString return an empty or null, does readAllLines return an empty list?  
      
      Also, you look at the paragraph that we put in InputStream.readAllBytes to cover the case where the reader is asynchronously closed or the thread interrupted while blocked reading the remaining characters?  There is also wording about the I/O error case that I think can come over too as it is more complete than what is in the current PR.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2871020072
      
      From alanb at openjdk.org  Mon May 12 06:31:52 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 06:31:52 GMT
      Subject: RFR: 8356694: Removed unused subclass audits in
       ObjectInput/OutputStream
      In-Reply-To: 
      References: 
      Message-ID: <6aSSeleHyKu2MpKIcaJsO-hMCcsmSueFM2w_5E0QYTs=.9d928a88-e996-45df-b56b-43497da18972@github.com>
      
      On Mon, 12 May 2025 02:18:05 GMT, Chen Liang  wrote:
      
      > These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
      > 
      > Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress
      
      Looks okay, looks like it was missed in the post JEP 486 cleanup.
      
      -------------
      
      Marked as reviewed by alanb (Reviewer).
      
      PR Review: https://git.openjdk.org/jdk/pull/25174#pullrequestreview-2831959455
      
      From pminborg at openjdk.org  Mon May 12 06:54:51 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 06:54:51 GMT
      Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
      In-Reply-To: 
      References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
       
      Message-ID: 
      
      On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley  wrote:
      
      >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
      >> 
      >> 
      >> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
      >> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
      >> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
      >> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
      >> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
      >
      > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   generate_unsafecopy_common_error_exit
      
      Looking at the improvements made, I suggest we also change (in `SegmentBulkOperations`):
      
      
      private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 18 : 5); 
      
      
      to 
      
      
       private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill",  5);
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2871092439
      
      From pminborg at openjdk.org  Mon May 12 07:03:03 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 07:03:03 GMT
      Subject: Integrated: 8347408: Create an internal method handle adapter for
       system calls with errno
      In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
      References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
      Message-ID: 
      
      On Mon, 5 May 2025 16:53:58 GMT, Per Minborg  wrote:
      
      > As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
      > 
      > Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
      > 
      > It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
      
      This pull request has now been integrated.
      
      Changeset: 45cf32bd
      Author:    Per Minborg 
      URL:       https://git.openjdk.org/jdk/commit/45cf32bd2c9e44e2fcbb4b8d0714b87e078cdb7c
      Stats:     650 lines in 4 files changed: 649 ins; 0 del; 1 mod
      
      8347408: Create an internal method handle adapter for system calls with errno
      
      Reviewed-by: mcimadamore
      
      -------------
      
      PR: https://git.openjdk.org/jdk/pull/25043
      
      From alanb at openjdk.org  Mon May 12 07:03:56 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 07:03:56 GMT
      Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
       empty file data [v2]
      In-Reply-To: 
      References: 
       
       
      Message-ID: 
      
      On Mon, 12 May 2025 01:08:34 GMT, Jaikiran Pai  wrote:
      
      > In addition to Lance's investigation, I also ran some experiments against a large number of jars. The results show that none of them are impacted by this change. More specifically, like Lance notes, the CRC values for the case of empty file data (or directory), the CRC is always 0. So the proposed change in this PR isn't expected to run into a JAR/ZIP which will trigger an exception when this CRC is now checked for such entries.
      
      Thanks for the investigations, this helps with the confidence that this isn't going to be disruptive.  The main concern with any tightening of validation is that a popular tool or plugin is generated ZIP or JAR files that fail this validation. So I think the change is okay and if something comes up then we still have the option of introducing a compatibility knob in the future.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2871116967
      
      From pminborg at openjdk.org  Mon May 12 07:14:59 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 07:14:59 GMT
      Subject: Integrated: 8356486: ReverseOrderListView should override reversed()
       to return `base`
      In-Reply-To: 
      References: 
      Message-ID: 
      
      On Thu, 8 May 2025 14:30:28 GMT, Per Minborg  wrote:
      
      > This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path.
      
      This pull request has now been integrated.
      
      Changeset: 43008b42
      Author:    Per Minborg 
      URL:       https://git.openjdk.org/jdk/commit/43008b42cf98466b4c4528d357bfcc2ae309770a
      Stats:     7 lines in 1 file changed: 4 ins; 2 del; 1 mod
      
      8356486: ReverseOrderListView should override reversed() to return `base`
      
      Reviewed-by: liach, smarks
      
      -------------
      
      PR: https://git.openjdk.org/jdk/pull/25120
      
      From pminborg at openjdk.org  Mon May 12 07:16:59 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 07:16:59 GMT
      Subject: RFR: 8356080: Address post-integration comments for Stable Values
       [v2]
      In-Reply-To: <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com>
      References: 
       <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>
       <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com>
      Message-ID: 
      
      On Fri, 9 May 2025 14:55:06 GMT, Chen Liang  wrote:
      
      >> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits:
      >> 
      >>  - Fix an issue with toString on nested constructs
      >>  - Merge branch 'master' into jep502-followup
      >>  - Merge branch 'master' into jep502-followup
      >>  - Update src/java.base/share/classes/java/lang/StableValue.java
      >>    
      >>    Co-authored-by: Chen Liang 
      >>  - Simplify furhter
      >>  - Address comments in PR
      >>  - Merge master
      >>  - Remove unused method and add comment
      >>  - Address comments
      >>  - Merge branch 'master' into jep502-followup
      >>  - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504
      >
      > src/java.base/share/classes/java/util/ReverseOrderListView.java line 46:
      > 
      >> 44:     final List base;
      >> 45:     @Stable
      >> 46:     final boolean modifiable;
      > 
      > Unfortunately, stable on boolean only works for true - wish we can get trusted or strict final soon :)
      
      We could change it to `Boolean`
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2083985618
      
      From alanb at openjdk.org  Mon May 12 07:24:56 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 07:24:56 GMT
      Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
      In-Reply-To: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
      References: 
       <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
      Message-ID: 
      
      On Fri, 9 May 2025 21:29:09 GMT, Naoto Sato  wrote:
      
      >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
      >
      > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Reflects another review comment
      
      src/java.base/share/classes/java/io/InputStreamReader.java line 54:
      
      > 52:  * }
      > 53:  * This example also demonstrates how to wrap {@link System#in} with {@link
      > 54:  * System##stdin.encoding stdin.encoding}.
      
      This example communicate two concerns, one is buffering, the other is the charset to use when running from System.in. I think we should separate these two, make with two examples.
      
      src/java.base/share/classes/java/util/Scanner.java line 82:
      
      > 80:  *
      > 81:  * 

      This code reads lines from {@link System#in} with {@link > 82: * System##stdin.encoding stdin.encoding}: "from System.in with stdin.encoding" isn't very clear. I think you we can expand the sentence, or make it two sentences, so to that is uses a Scanner to read lines from System.in, and uses the value of stdin.encoding as the charset. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2083997044 PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2083991533 From pminborg at openjdk.org Mon May 12 07:42:16 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 12 May 2025 07:42:16 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v3] In-Reply-To: References: Message-ID: > This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. > > Unfortunately, this PR shows the total commit history for stable values. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits: - Address comments - Merge branch 'master' into jep502-followup - Fix an issue with toString on nested constructs - Merge branch 'master' into jep502-followup - Merge branch 'master' into jep502-followup - Update src/java.base/share/classes/java/lang/StableValue.java Co-authored-by: Chen Liang - Simplify furhter - Address comments in PR - Merge master - Remove unused method and add comment - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336 ------------- Changes: https://git.openjdk.org/jdk/pull/25004/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=02 Stats: 358 lines in 13 files changed: 237 ins; 49 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/25004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004 PR: https://git.openjdk.org/jdk/pull/25004 From vklang at openjdk.org Mon May 12 08:14:03 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 12 May 2025 08:14:03 GMT Subject: RFR: 8350765: Need to pin when accessing thread container from virtual thread In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman wrote: > Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code. Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues. > > Testing tier1-5, quick statup/footprint, noreg-hard Nice work, Alan src/java.base/share/classes/jdk/internal/vm/ContinuationSupport.java line 57: > 55: */ > 56: public static void pinIfSupported() { > 57: if (ContinuationSupport.isSupported()) { Suggestion: if (isSupported()) { src/java.base/share/classes/jdk/internal/vm/ContinuationSupport.java line 66: > 64: */ > 65: public static void unpinIfSupported() { > 66: if (ContinuationSupport.isSupported()) { Suggestion: if (isSupported()) { ------------- Changes requested by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23810#pullrequestreview-2829366716 PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2082318599 PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2082318783 From alanb at openjdk.org Mon May 12 08:14:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 May 2025 08:14:03 GMT Subject: RFR: 8350765: Need to pin when accessing thread container from virtual thread Message-ID: Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code. Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues. Testing tier1-5, quick statup/footprint, noreg-hard ------------- Commit messages: - No need to used qualified name - Merge branch 'master' into JDK-8350765 - Update - Merge branch 'master' into JDK-8350765 - Add method to ContinuationSupport - Missing / - Initial commit Changes: https://git.openjdk.org/jdk/pull/23810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23810&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350765 Stats: 92 lines in 6 files changed: 48 ins; 25 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/23810.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23810/head:pull/23810 PR: https://git.openjdk.org/jdk/pull/23810 From pminborg at openjdk.org Mon May 12 08:27:00 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 12 May 2025 08:27:00 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v4] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright years Latest changes look good. ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2832285086 From jpai at openjdk.org Mon May 12 08:51:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 May 2025 08:51:53 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v4] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright years src/java.base/share/classes/jdk/internal/util/HexDigits.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Hello Volkan, this should be `2024, 2025, ` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084166104 From jpai at openjdk.org Mon May 12 08:54:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 May 2025 08:54:54 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v4] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright years src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 461: > 459: * make a copy. > 460: */ > 461: Object stringConcat1(String[] constants); Is this missing the `unchecked` prefix to the method name? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084172186 From pminborg at openjdk.org Mon May 12 09:03:32 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 12 May 2025 09:03:32 GMT Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out Message-ID: This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. ------------- Commit messages: - Add safety net around stalled thread Changes: https://git.openjdk.org/jdk/pull/25177/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356658 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177 PR: https://git.openjdk.org/jdk/pull/25177 From jpai at openjdk.org Mon May 12 09:03:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 May 2025 09:03:53 GMT Subject: RFR: 8350765: Need to pin when accessing thread container from virtual thread In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman wrote: > Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code. Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues. > > Testing tier1-5, quick statup/footprint, noreg-hard src/java.base/share/classes/jdk/internal/vm/ThreadContainer.java line 97: > 95: public final void add(Thread thread) { > 96: // Prevent a virtual thread from being preempted as this could potentially > 97: // deadlock with a carrier is removing a virtual thread from the container Is there a typo in this sentence? Should "with a carrier" have been "when a carrier ..." ? Similar comment in the remove(...) method too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2084191952 From mcimadamore at openjdk.org Mon May 12 09:19:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 12 May 2025 09:19:51 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis wrote: > While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. > > For example this is not valid Java (and protected) by javac: > > > byte b = 1; > switch (b) { > case String s -> System.out.println("How did we get here? byte is " + s.getClass()); > } > > > but this is a valid call (and not protected): > > > CallSite shortSwitch = SwitchBootstraps.typeSwitch( > MethodHandles.lookup(), > "", > MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int > String.class); > > > The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. > > This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 725: > 723: > 724: private static boolean isNotValidPair(Class selectorType, Object caseLabel) { > 725: return (selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class) || What happens if `caseLabel` is a reference class? E.g. a `boolean` selector is incompatible with `String`. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 786: > 784: (selectorType.equals(char.class) && (selectorWrapper.isStrictSubRangeOf(targetWrapper))) || > 785: (selectorType.equals(int.class) && (targetType.equals(double.class) || targetType.equals(long.class))) || > 786: (selectorType.equals(float.class) && (selectorWrapper.isStrictSubRangeOf(targetWrapper)))))) return true; Is `double` the only allowed target for `float` ? If so, perhaps we could simplify like for other selector types. Or, alternatively, I wonder if it wouldn't be simpler to _always_ check for strict subrange on the wrappers, but then ban the conversions that are not exact (e.g. int -> float), as those are few? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2084222014 PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2084221014 From adinn at openjdk.org Mon May 12 09:20:52 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 12 May 2025 09:20:52 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > generate_unsafecopy_common_error_exit src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2611: > 2609: > 2610: __ subs(count, count, 64); > 2611: __ add(dest, dest, 64); This add could be elided by employing a post-increment on dest in each of the two writes above, saving on code size. Is there a reason to prefer the add? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084225622 From pminborg at openjdk.org Mon May 12 09:35:08 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 12 May 2025 09:35:08 GMT Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v2] In-Reply-To: References: Message-ID: > This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. > > Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add shutdown ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25177/files - new: https://git.openjdk.org/jdk/pull/25177/files/3547359f..c4f50471 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177 PR: https://git.openjdk.org/jdk/pull/25177 From jpai at openjdk.org Mon May 12 09:35:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 May 2025 09:35:08 GMT Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v2] In-Reply-To: References: Message-ID: <2obeae4mCNTHQck4IShjXJr07D5vtl-Z-_P7dYYNIO4=.e6b60cc7-8d71-4c46-ad51-0961bc43182d@github.com> On Mon, 12 May 2025 09:32:11 GMT, Per Minborg wrote: >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. >> >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add shutdown test/jdk/java/foreign/TestBufferStackStress2.java line 139: > 137: // This is a corner case for rare configurations > 138: System.out.println(duration(begin) + "ABORTED"); > 139: System.exit(0); Hello Per, a `System.exit(...)` call isn't recommended in a jtreg test (https://openjdk.org/jtreg/faq.html#should-a-test-call-the-system.exit-method) On a general note though, I think this test might need a different solution to address the issue. For one, I think it might be better to use `@run junit/othervm` instead of the current `@run junit` to prevent any agent VM specific state to interfere with this test. Secondly, I think in its current form the test may still have a race. The main thread which does the `quiescent.notify();` may execute before the other thread reaches the `quiescent.wait();`. That can cause the other thread to wait forever. I think to avoid this, a `CountDownLatch` might be more appropriate. Something like (the untested change below): diff --git a/test/jdk/java/foreign/TestBufferStackStress2.java b/test/jdk/java/foreign/TestBufferStackStress2.java index 8ec5d512ff6..0ba28ad6f9e 100644 --- a/test/jdk/java/foreign/TestBufferStackStress2.java +++ b/test/jdk/java/foreign/TestBufferStackStress2.java @@ -38,6 +38,7 @@ import java.lang.foreign.ValueLayout; import java.time.Duration; import java.time.temporal.ChronoUnit; +import java.util.concurrent.CountDownLatch; import java.util.concurrent.Executors; import java.util.concurrent.ForkJoinWorkerThread; import java.util.concurrent.atomic.AtomicBoolean; @@ -78,7 +79,7 @@ void movingVirtualThreadWithGc() throws InterruptedException { var done = new AtomicBoolean(); var completed = new AtomicBoolean(); - var quiescent = new Object(); + var quiescentLatch = new CountDownLatch(1); var executor = Executors.newVirtualThreadPerTaskExecutor(); executor.submit(() -> { @@ -93,12 +94,11 @@ void movingVirtualThreadWithGc() throws InterruptedException { try (Arena arena = pool.pushFrame(SMALL_ALLOC_SIZE, 1)) { MemorySegment segment = arena.allocate(SMALL_ALLOC_SIZE); done.set(true); - synchronized (quiescent) { - try { - quiescent.wait(); - } catch (Throwable ex) { - throw new AssertionError(ex); - } + // wait for ForkJoinPool to contract + try { + quiescentLatch.await(); + } catch (Throwable ex) { + throw new AssertionError(ex); } System.out.println(duration(begin) + "ACCESSING SEGMENT"); @@ -123,10 +123,7 @@ void movingVirtualThreadWithGc() throws InterruptedException { } while (count > 0); System.out.println(duration(begin) + "FJP HAS CONTRACTED"); - - synchronized (quiescent) { - quiescent.notify(); - } + quiescentLatch.countDown(); // notify the thread that accesses the MemorySegment System.out.println(duration(begin) + "CLOSING EXECUTOR"); executor.close(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084250912 From aph at openjdk.org Mon May 12 09:37:24 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 12 May 2025 09:37:24 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v3] In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Stub stack frame ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25147/files - new: https://git.openjdk.org/jdk/pull/25147/files/1078ba8c..47179d57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From aph at openjdk.org Mon May 12 09:37:24 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 12 May 2025 09:37:24 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: <8nuQIwaoVWwaSrsAE8oni5LET--OIIsSloJYgenOUY8=.68950b83-957d-48f6-87e1-a63f88197df5@github.com> On Mon, 12 May 2025 09:18:13 GMT, Andrew Dinn wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> generate_unsafecopy_common_error_exit > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2611: > >> 2609: >> 2610: __ subs(count, count, 64); >> 2611: __ add(dest, dest, 64); > > This add could be elided by employing a post-increment on dest in each of the two writes above, saving on code size. Is there a reason to prefer the add? Yes, there is. A post-increment is often an extra cycle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084252981 From alanb at openjdk.org Mon May 12 09:37:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 May 2025 09:37:52 GMT Subject: RFR: 8350765: Need to pin when accessing thread container from virtual thread In-Reply-To: References: Message-ID: On Mon, 12 May 2025 09:01:34 GMT, Jaikiran Pai wrote: >> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code. Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues. >> >> Testing tier1-5, quick statup/footprint, noreg-hard > > src/java.base/share/classes/jdk/internal/vm/ThreadContainer.java line 97: > >> 95: public final void add(Thread thread) { >> 96: // Prevent a virtual thread from being preempted as this could potentially >> 97: // deadlock with a carrier is removing a virtual thread from the container > > Is there a typo in this sentence? Should "with a carrier" have been "when a carrier ..." ? Similar comment in the remove(...) method too. You are right, there is a pre-existing typo in that comment (the sentence was copied to here from RQ). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2084260621 From aph at openjdk.org Mon May 12 09:42:51 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 12 May 2025 09:42:51 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: <6iRBKELx-Xnkgfm4MbONISmz9D3SjO_38PlaQXijv7w=.d6cb630c-7e83-4695-9ccc-6cfa30da5e17@github.com> On Mon, 12 May 2025 06:52:12 GMT, Per Minborg wrote: > Looking at the improvements made, I suggest we also change (in `SegmentBulkOperations`): > > ``` > private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 18 : 5); > ``` > > to > > ``` > private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", 5); > ``` Possibly so, yes, but I'm still looking at the reasons for the differences. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2871790462 From duke at openjdk.org Mon May 12 09:45:02 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 May 2025 09:45:02 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems Message-ID: Adding read-only support to ZipFileSystem. The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). ------------- Commit messages: - Read only Zip file system support. Changes: https://git.openjdk.org/jdk/pull/25178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350880 Stats: 373 lines in 5 files changed: 310 ins; 20 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From adinn at openjdk.org Mon May 12 09:50:52 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 12 May 2025 09:50:52 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v3] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Mon, 12 May 2025 09:37:24 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Stub stack frame src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2619: > 2617: > 2618: __ bind(tail); > 2619: // __ add(count, count, 64); I can see why you commented this out (and prefer that to deleting it). However, a comment explaining why it is not needed might avoid maintainers being side-tracked. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084293642 From alanb at openjdk.org Mon May 12 10:04:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 May 2025 10:04:53 GMT Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v2] In-Reply-To: References: Message-ID: <8R2mz4GuYNoqtgW8VOc_DGcNAxa0-1s5x_DL-w8R8TE=.e498ab31-d1bd-4736-83e3-04cf0390f518@github.com> On Mon, 12 May 2025 09:35:08 GMT, Per Minborg wrote: >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. >> >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add shutdown Jai is correct that we can't use System.exit in tests. I added a comment to the JBS issue as it looks like the bug report is with a Zero build. Zero doesn't have VM continuations support so there will be no scheduler and no ForkJoinWorkerThreads. This creates the race where the main thread does the quiescent.notify before the virtual thread waits. Adding `@requires vm.continuations` to the test will skip it for this configuraiton. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2871874731 From duke at openjdk.org Mon May 12 10:05:59 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 May 2025 10:05:59 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems In-Reply-To: References: Message-ID: On Mon, 12 May 2025 09:40:56 GMT, David Beaumont wrote: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). Preloading some explanatory comment. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 83: > 81: private static final boolean isWindows = System.getProperty("os.name") > 82: .startsWith("Windows"); > 83: private static final byte[] ROOTPATH = new byte[]{'/'}; Whitespace format changes from my editor - will revert (sorry hadn't spotted). src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 89: > 87: > 88: // Posix file permissions allow per-file access control in a posix-like fashion. > 89: // Note that using a "readOnly" access mode will force all files, and the Not correct now - will fix. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 198: > 196: this.defaultOwner = supportPosix ? initOwner(zfpath, env) : null; > 197: this.defaultGroup = supportPosix ? initGroup(zfpath, env) : null; > 198: this.defaultPermissions = supportPosix ? Collections.unmodifiableSet(initPermissions(env)) : null; Ensuring this is unmodifiable to avoid risk of returning a modifiable enum set. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221: > 219: } > 220: // sm and existence check > 221: zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ); Type name clash with existing AccessMode class. Since new enum is private, happy to rename. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241: > 239: // is why they are the only non-final fields), and it requires that the > 240: // inode map has been initialized. > 241: Optional multiReleaseVersion = determineReleaseVersion(env); Now release version and entry lookup determination always happen on a read-only file system. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259: > 257: > 258: // Pass "this" as a parameter after everything else is set up. > 259: this.rootdir = new ZipPath(this, new byte[]{'/'}); This could probably be set above release version etc. but it's a choice of either: 1. waiting until everything is set up before passing "this" 2. letting an incomplete "this" instance get passed to another class (possible escape risk?) src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 264: > 262: /** > 263: * Return the compression method to use (STORED or DEFLATED). If the > 264: * property {@code compressionMethod} is set use its value to determine Typo fix (too many m's). src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 377: > 375: Object o = env.get(PROPERTY_DEFAULT_PERMISSIONS); > 376: if (o == null) { > 377: return PosixFilePermissions.fromString("rwxrwxrwx"); Since DEFAULT_PERMISSIONS was mutable and only used exactly once, it seems better to just inline it where it's clear what it actually is based off. Better readability. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1458: > 1456: * use its value to determine the requested version. If not use the value of the "multi-release" property. > 1457: */ > 1458: private Optional determineReleaseVersion(Map env) throws IOException { Refactored to return the value rather than side-effect instance fields. test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 180: > 178: */ > 179: @Test > 180: public void testNoSuchFileFailure() { In theory some of these could be split more, but they are uncomplicated sanity checks. test/jdk/jdk/nio/zipfs/Utils.java line 52: > 50: */ > 51: static Path createJarFile(String name, String... entries) throws IOException { > 52: Path jarFile = Paths.get(name); Previous tests always had the test file called the same thing. Note that in jtreg tests, the file of the same name often already exists in the test directory. I tried adding a "ensure file doesn't already exist" check and it fails lots of tests. ------------- PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2832583353 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084284309 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084288335 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084292488 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084296094 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084297859 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084301697 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084302415 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084306071 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084307536 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084311454 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084317768 From aph at openjdk.org Mon May 12 10:06:51 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 12 May 2025 10:06:51 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v3] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: <-74qcaU_hYstfJykNB6hvffkOH9WQVtZOVNza8TGdMs=.10f80939-81e6-403e-930c-8e12ee6cb35d@github.com> On Mon, 12 May 2025 09:48:03 GMT, Andrew Dinn wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Stub stack frame > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2619: > >> 2617: >> 2618: __ bind(tail); >> 2619: // __ add(count, count, 64); > > I can see why you commented this out (and prefer that to deleting it). However, a comment explaining why it is not needed might avoid maintainers being side-tracked. Eh, people enjoy a little puzzle. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084323192 From duke at openjdk.org Mon May 12 10:11:11 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 May 2025 10:11:11 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v2] In-Reply-To: References: Message-ID: <1WMrvLWTwMWR2ECtF4E8hcQXIL1sxeQA4Cf1mamF6Ho=.80041034-907d-48aa-957c-108d59c3b3e8@github.com> > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Remove unwanted reformatting. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/da3dfc6f..376e3acf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From duke at openjdk.org Mon May 12 10:16:33 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 May 2025 10:16:33 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: Message-ID: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Fix comment based on current behaviour. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/376e3acf..9b356a24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From vyazici at openjdk.org Mon May 12 10:17:46 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 12 May 2025 10:17:46 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v5] In-Reply-To: References: Message-ID: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` - Fix `HexDigits` copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24982/files - new: https://git.openjdk.org/jdk/pull/24982/files/121005ee..5da9465c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=03-04 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From vyazici at openjdk.org Mon May 12 10:17:48 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 12 May 2025 10:17:48 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 08:52:00 GMT, Jaikiran Pai wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright years > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 461: > >> 459: * make a copy. >> 460: */ >> 461: Object stringConcat1(String[] constants); > > Is this missing the `unchecked` prefix to the method name? Fixed in 5da9465ce7f. > src/java.base/share/classes/jdk/internal/util/HexDigits.java line 2: > >> 1: /* >> 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > Hello Volkan, this should be `2024, 2025, ` Fixed in f94af95d8d0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084345953 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084345343 From duke at openjdk.org Mon May 12 10:21:50 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 May 2025 10:21:50 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. Obvious mistakes now fixed (it's amazing what you only spot when looking at code in a review UI). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2871935949 From pminborg at openjdk.org Mon May 12 10:30:31 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 12 May 2025 10:30:31 GMT Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v3] In-Reply-To: References: Message-ID: > This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. > > Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rework solution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25177/files - new: https://git.openjdk.org/jdk/pull/25177/files/c4f50471..bb612982 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=01-02 Stats: 28 lines in 1 file changed: 7 ins; 14 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177 PR: https://git.openjdk.org/jdk/pull/25177 From duke at openjdk.org Mon May 12 10:37:04 2025 From: duke at openjdk.org (Markus KARG) Date: Mon, 12 May 2025 10:37:04 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 01:17:15 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/lang/CharSequence.java line 313: >> >>> 311: * at index {@code dstBegin} and ending at index: >>> 312: *

      {@code
      >>> 313:      * dstbegin + (srcEnd-srcBegin) - 1
      >> 
      >> Shouldn't it be dstBegin?
      >> 
      >> * dstBegin + (srcEnd-srcBegin) - 1
      >
      > Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?
      
      We could also simply include it in the PR for https://bugs.openjdk.org/browse/JDK-8356679 to reduce organizational overhead.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2084384684
      
      From alanb at openjdk.org  Mon May 12 10:47:52 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 10:47:52 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v3]
      In-Reply-To: 
      References: 
       
      Message-ID: <6iLIocajLhCunmHWfesaMMAP324cbfKxN22JHT7RbLs=.f4632de1-0ece-4be0-a7a8-55361d3aaf03@github.com>
      
      On Mon, 12 May 2025 10:30:31 GMT, Per Minborg  wrote:
      
      >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      >> 
      >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      >
      > Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Rework solution
      
      test/jdk/java/foreign/TestBufferStackStress2.java line 28:
      
      > 26:  *
      > 27:  * If the VM does not have continuations, then no VTs can ever be scheduled
      > 28:  * @requires vm.continuations
      
      The comment isn't quite right. Virtual threads will still be scheduled, it's just that the OS scheduler will be used as each virtual thread is backed by an OS thread.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084399659
      
      From jpai at openjdk.org  Mon May 12 10:47:51 2025
      From: jpai at openjdk.org (Jaikiran Pai)
      Date: Mon, 12 May 2025 10:47:51 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v3]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Mon, 12 May 2025 10:30:31 GMT, Per Minborg  wrote:
      
      >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      >> 
      >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      >
      > Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Rework solution
      
      test/jdk/java/foreign/TestBufferStackStress2.java line 27:
      
      > 25:  * @test
      > 26:  *
      > 27:  * If the VM does not have continuations, then no VTs can ever be scheduled
      
      Nit - jtreg allows for a `@comment` tag in the test definition https://openjdk.org/jtreg/tag-spec.html. It would be good to prefix this line with `@comment`.
      
      test/jdk/java/foreign/TestBufferStackStress2.java line 48:
      
      > 46: import java.util.concurrent.Executors;
      > 47: import java.util.concurrent.ForkJoinWorkerThread;
      > 48: import java.util.concurrent.TimeUnit;
      
      Likely no longer needed?
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084398966
      PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084401253
      
      From pminborg at openjdk.org  Mon May 12 10:54:05 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 10:54:05 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v4]
      In-Reply-To: 
      References: 
      Message-ID: 
      
      > This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      > 
      > Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      
      Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      
        Address comments
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/25177/files
        - new: https://git.openjdk.org/jdk/pull/25177/files/bb612982..6e3f7eeb
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=03
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=02-03
      
        Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
        Patch: https://git.openjdk.org/jdk/pull/25177.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177
      
      PR: https://git.openjdk.org/jdk/pull/25177
      
      From jpai at openjdk.org  Mon May 12 11:06:56 2025
      From: jpai at openjdk.org (Jaikiran Pai)
      Date: Mon, 12 May 2025 11:06:56 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v4]
      In-Reply-To: 
      References: 
       
      Message-ID: <9cfLMQKs9naPI2ISlRk8CY1OMJf0_lQMJyWph4oZv_k=.4a3eb13a-e7a0-4e52-a062-74e32593096c@github.com>
      
      On Mon, 12 May 2025 10:54:05 GMT, Per Minborg  wrote:
      
      >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      >> 
      >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      >
      > Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Address comments
      
      Sorry Per, I didn't notice this in the previous round - I think we should add `@bug 8356658` to the test definition, given the nature of the change to this test. Other than that, the rest of the changes in `6e3f7ee` look good to me.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872077214
      
      From dl at openjdk.org  Mon May 12 11:11:51 2025
      From: dl at openjdk.org (Doug Lea)
      Date: Mon, 12 May 2025 11:11:51 GMT
      Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
      In-Reply-To: 
      References: 
       <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
       
       
      Message-ID: 
      
      On Fri, 9 May 2025 14:50:49 GMT, Viktor Klang  wrote:
      
      >>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?
      >> 
      >> I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion.
      >
      > I understand, alas LBQ enqueue() and dequeue() don't increment a counter. It seems a bit brittle that the invariant needs to be maintained *externally* to the state modification. For the sake of maintainability I think the checks and the increment/decrement belongs in the same unit of work.
      
      This is what I meant about reducing sequential consistency. But it does work out in terms of maintaining specs.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2084442740
      
      From jd at civilian-framework.org  Mon May 12 11:16:37 2025
      From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
      Date: Mon, 12 May 2025 13:16:37 +0200
      Subject: potential performance improvement in sun.nio.cs.UTF_8
      Message-ID: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>
      
      I have a suggestion for a performance improvement in sun.nio.cs.UTF_8, 
      the workhorse for stream based UTF-8 encoding and decoding, but don't 
      know if this has been discussed before.
      I explain my idea for the decoding case:
      Claes Redestad describes in his blog 
      https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html? how he 
      used SIMD intrinsics (now JavaLangAccess.decodeASCII) to speed UTF_8 
      decoding when buffers are backed by arrays:
      
      https://github.com/openjdk/jdk/blob/0258d9998ebc523a6463818be00353c6ac8b7c9c/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L231
      
        * first a call to JLA.decodeASCII harvests all ASCII-characters
          (=1-byte UTF-8 sequence) at the beginning of the input
        * then enters the slow loop of looking at UTF-8 byte sequences in the
          input buffer and writing to the output buffer (this is basically the
          old implementation)
      
      If the input is all ASCII all decoding work is done in JLA.decodeASCII 
      resulting in an extreme performance boost. But if the input contains a 
      non-ASCII it will fall back to the slow array loop.
      
      Now here is my idea: Why not call JLA.decodeASCI whenever an ASCII input 
      is seen:
      
      while (sp < sl) {
       ??? int b1 = sa[sp];
       ??? if (b1 >= 0) {
       ??????? // 1 byte, 7 bits: 0xxxxxxx
       ??????? if (dp >= dl)
       ??????????? return xflow(src, sp, sl, dst, dp, 1);
       ??????? // my change
      *??????? int n = JLA.decodeASCII(sa, sp, da, dp, Math.min(sl - sp, dl - 
      dp));
       ??????? sp += n;
       ??????? dp += n;
      *??? } else if ((b1 >> 5) == -2 && (b1 & 0x1e) != 0) {
      
      I setup a small improvised benchmark to get an idea of the impact:
      
      Benchmark???????????????????? (data) Mode? Cnt??????? Score?? Error? Units
      DecoderBenchmark.jdkDecoder? TD_8000? thrpt??? 2 2045960,037????????? ops/s
      DecoderBenchmark.jdkDecoder? TD_3999? thrpt??? 2 263744,675????????? ops/s
      DecoderBenchmark.jdkDecoder?? TD_999? thrpt??? 2 154232,940????????? ops/s
      DecoderBenchmark.jdkDecoder?? TD_499? thrpt??? 2 142239,763????????? ops/s
      DecoderBenchmark.jdkDecoder??? TD_99? thrpt??? 2 128678,229????????? ops/s
      DecoderBenchmark.jdkDecoder???? TD_9? thrpt??? 2 127388,649????????? ops/s
      DecoderBenchmark.jdkDecoder???? TD_4? thrpt??? 2 119834,183????????? ops/s
      DecoderBenchmark.jdkDecoder???? TD_2? thrpt??? 2 111733,115????????? ops/s
      DecoderBenchmark.jdkDecoder???? TD_1? thrpt??? 2 102397,455????????? ops/s
      DecoderBenchmark.newDecoder? TD_8000? thrpt??? 2 2022997,518????????? ops/s
      DecoderBenchmark.newDecoder? TD_3999? thrpt??? 2 2909450,005????????? ops/s
      DecoderBenchmark.newDecoder?? TD_999? thrpt??? 2 2140307,712????????? ops/s
      DecoderBenchmark.newDecoder?? TD_499? thrpt??? 2 1171970,809????????? ops/s
      DecoderBenchmark.newDecoder??? TD_99? thrpt??? 2 686771,614????????? ops/s
      DecoderBenchmark.newDecoder???? TD_9? thrpt??? 2 95181,541????????? ops/s
      DecoderBenchmark.newDecoder???? TD_4? thrpt??? 2 65656,184????????? ops/s
      DecoderBenchmark.newDecoder???? TD_2? thrpt??? 2 45439,240????????? ops/s
      DecoderBenchmark.newDecoder???? TD_1? thrpt??? 2 36994,738????????? ops/s
      
      (The benchmark uses only memory buffers, each test input is a UTF-8 
      encoded byte buffer which produces 8000 chars and consists of various 
      length of pure ascii bytes, followed by a 2-byte UTF-8 sequence 
      producing a non-ASCII char:
      TD_8000: 8000 ascii bytes -> 1 call to JLA.decodeASCII
      TD_3999: 3999 ascii bytes + 2 non-ascii bytes, repeated 2 times -> 2 
      calls to JLA.decodeASCII
      ...
      TD_1: 1 ascii byte + 2 non-ascii bytes, repeated 4000 times -> 4000 
      calls to JLA.decodeASCII
      
      Interpretation:
      
        * Input all ASCII: same performance as before
        * Input contains pure ASCII sequence of considerable length
          interrupted by non ASCII bytes: now seeing huge performance
          improvements similar to the pure ASCII case.
        * Input has lot of short sequences of ASCII-bytes interrupted by non
          ASCII bytes: at some point performance drops below current
          implementation.
      
      Thanks for reading and happy to hear your opinions,
      Johannes
      
      -------------- next part --------------
      An HTML attachment was scrubbed...
      URL: 
      
      From jpai at openjdk.org  Mon May 12 11:27:35 2025
      From: jpai at openjdk.org (Jaikiran Pai)
      Date: Mon, 12 May 2025 11:27:35 GMT
      Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
       empty file data [v3]
      In-Reply-To: 
      References: 
      Message-ID: 
      
      > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
      > 
      > `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
      > 
      > tier testing is currently in progress.
      
      Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
      
        Lance's suggestion - simplify argument creation, given just a handful number of argument values
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/25116/files
        - new: https://git.openjdk.org/jdk/pull/25116/files/0aea22fa..d1361736
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=02
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=01-02
      
        Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod
        Patch: https://git.openjdk.org/jdk/pull/25116.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25116/head:pull/25116
      
      PR: https://git.openjdk.org/jdk/pull/25116
      
      From pminborg at openjdk.org  Mon May 12 11:45:29 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 11:45:29 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v5]
      In-Reply-To: 
      References: 
      Message-ID: 
      
      > This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      > 
      > Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      
      Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      
        Add @bug definition
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/25177/files
        - new: https://git.openjdk.org/jdk/pull/25177/files/6e3f7eeb..82e68046
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=04
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=03-04
      
        Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
        Patch: https://git.openjdk.org/jdk/pull/25177.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177
      
      PR: https://git.openjdk.org/jdk/pull/25177
      
      From mullan at openjdk.org  Mon May 12 12:19:56 2025
      From: mullan at openjdk.org (Sean Mullan)
      Date: Mon, 12 May 2025 12:19:56 GMT
      Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Fri, 9 May 2025 20:05:10 GMT, Weijun Wang  wrote:
      
      >> Finalize the KDF API.
      >
      > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   new algorithms in SunJCE
      
      Marked as reviewed by mullan (Reviewer).
      
      -------------
      
      PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2833006989
      
      From alanb at openjdk.org  Mon May 12 12:36:54 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 12:36:54 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v5]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Mon, 12 May 2025 11:45:29 GMT, Per Minborg  wrote:
      
      >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      >> 
      >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      >
      > Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Add @bug definition
      
      I assume the changes to switch this from wait/notify to CountDownLatch aren't needed. A carrier can't terminate with a mounted virtual thread. It's okay to change the test but I think the original issue is about Zero or running with -XX:-VMContinautions.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872382778
      
      From pminborg at openjdk.org  Mon May 12 12:39:54 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 12:39:54 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v5]
      In-Reply-To: 
      References: 
       
       
      Message-ID: 
      
      On Mon, 12 May 2025 12:34:29 GMT, Alan Bateman  wrote:
      
      > I assume the changes to switch this from wait/notify to CountDownLatch aren't needed. A carrier can't terminate with a mounted virtual thread. It's okay to change the test but I think the original issue is about Zero or running with -XX:-VMContinautions.
      
      Yes. This just eliminates potential races, but is not strictly needed to avoid the problem at hand.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872391132
      
      From alanb at openjdk.org  Mon May 12 12:46:53 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 12:46:53 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v5]
      In-Reply-To: 
      References: 
       
       
       
      Message-ID: 
      
      On Mon, 12 May 2025 12:37:34 GMT, Per Minborg  wrote:
      
      > > I assume the changes to switch this from wait/notify to CountDownLatch aren't needed. A carrier can't terminate with a mounted virtual thread. It's okay to change the test but I think the original issue is about Zero or running with -XX:-VMContinautions.
      > 
      > Yes. This just eliminates potential races, but is not strictly needed to avoid the problem at hand.
      
      Okay, but I don't think there is a race as the only scheduler point right now is the wait. Maybe the future we might have additional scheduling points that would impact this. So I think what you have is okay.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872422477
      
      From jpai at openjdk.org  Mon May 12 13:44:51 2025
      From: jpai at openjdk.org (Jaikiran Pai)
      Date: Mon, 12 May 2025 13:44:51 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v5]
      In-Reply-To: 
      References: 
       
      Message-ID: <1GL6_g0L3wPIO5N7RIih6gb-2DQQ-p7NUFEECDRmRhU=.517abf75-526a-4937-ad7a-b50c31c10046@github.com>
      
      On Mon, 12 May 2025 11:45:29 GMT, Per Minborg  wrote:
      
      >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      >> 
      >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      >
      > Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Add @bug definition
      
      test/jdk/java/foreign/TestBufferStackStress2.java line 30:
      
      > 28:  * @requires vm.continuations
      > 29:  *
      > 30:  * @bug 8356114, 8356658
      
      jtreg doesn't like the presence of comma in those values and the GitHub job has caught that failure in this test.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084707435
      
      From duke at openjdk.org  Mon May 12 13:59:57 2025
      From: duke at openjdk.org (kabutz)
      Date: Mon, 12 May 2025 13:59:57 GMT
      Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
       pre-loading LockSupport.class
      In-Reply-To: 
      References: 
       
       
       
       
      Message-ID: 
      
      On Fri, 9 May 2025 06:37:40 GMT, Alan Bateman  wrote:
      
      > No, it will still uses synchronized if there is contention and this will not consume the park permit when it's a virtual thread. Im not sure if Heinz ran into an issue, or just remember the issue from 2015, Heinz?
      
      I saw this comment in the JavaDoc of LockSupport: https://github.com/openjdk/jdk/blob/7ae52ce572794f9d17446c66381f703ea1bb8b7c/src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java#L135 
      
      I then searched through the JDK classes and the only ones that used LockSupport and that did not have the static {var clazz = LockSupport.class;} were the newer classes that arrived with Java 19, plus also Exchanger (which may have been an oversight).
      
      If this is no longer an issue, and we are 100% sure of that, then we can perhaps change the example to not have that static loader?
      
      I have not tried to reproduce the bug, and from what Martin Buchholz described it is extremely elusive.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2872683811
      
      From alanb at openjdk.org  Mon May 12 14:01:16 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 14:01:16 GMT
      Subject: RFR: 8350765: Need to pin when accessing thread container from
       virtual thread [v2]
      In-Reply-To: 
      References: 
      Message-ID: 
      
      > Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
      > 
      > Testing tier1-5, quick statup/footprint, noreg-hard
      
      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 10 additional commits since the last revision:
      
       - Fix/improve comment
       - Merge branch 'master' into JDK-8350765
       - Merge branch 'master' into JDK-8350765
       - No need to used qualified name
       - Merge branch 'master' into JDK-8350765
       - Update
       - Merge branch 'master' into JDK-8350765
       - Add method to ContinuationSupport
       - Missing /
       - Initial commit
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/23810/files
        - new: https://git.openjdk.org/jdk/pull/23810/files/2959e070..5ff93aea
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=23810&range=01
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23810&range=00-01
      
        Stats: 2069 lines in 129 files changed: 1811 ins; 61 del; 197 mod
        Patch: https://git.openjdk.org/jdk/pull/23810.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/23810/head:pull/23810
      
      PR: https://git.openjdk.org/jdk/pull/23810
      
      From jengebr at amazon.com  Mon May 12 14:35:02 2025
      From: jengebr at amazon.com (Engebretson, John)
      Date: Mon, 12 May 2025 14:35:02 +0000
      Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
      In-Reply-To: 
      References: <8721e7784793451187c5b6099eb37756@amazon.com>
       <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
       <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
       
       
       <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
       
       <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
       
       
       
       <4741eceb3beb40c2bc82613c67836d66@amazon.com>
       
       
       
       <4c4aac5737d844a4959885c65f17efee@amazon.com>
       <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
       <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>
       
       
      Message-ID: 
      
        Friendly ping.  There seems to be support for this idea in some form (especially on the PR) but I haven?t received anything definitive from this email discussion.  The safest proposal on the table is from @liach: make this a JDK-internal class (for now) and modify JDK classes to rely on it.  Assuming good results, we consider making it public in future releases.
        Could I please get some form of signoff from the core team?  I?d really like to deliver something here soon, otherwise I have to move on.
        Thank you very much!  ?
          John
      
      From: core-libs-dev  On Behalf Of Engebretson, John
      Sent: Tuesday, April 22, 2025 7:52 AM
      
      
        Thank you Alan!  I?ll try to address each of your points, apologies if I miss anything:
      
              Maybe the two efforts should be separated.
      
        I?m good with that, and will operate that way unless someone argues otherwise.
      
             The factory methods can return a different implementation, in particular BAOS.unsynchronized (or whatever name it gets) does not need to collect the bytes in a contiguous array. So having a BAOS.unsynchronized may help with some of the scenarios that you are looking at.
      
        I think this is a clever way to go and I?m in favor? just not sold on the name.  I won?t abandon the effort if you feel otherwise.  ?  Let me know if we?re ready to proceed with this or another name.
      
            I think the PR proposing MemoryOutputStream is a bit premature
      
        This was intended solely to share code for discussion, and it?s been effective in that sense.  I agree that the PR is nowhere near merging.
      
            Maybe you have explored a segment like API or a cursor or consumer API to handle the bytes?
      
        The current version of the PR is along these lines, providing one public class whose contents are available via views (SeekableByteChannel, BAOS, ByteArrayInputStream) as well as the usual add/write/updates, long size(), and lambda-based applyToSegment(Function) and applyToIndex(Function).  The public wrapping needs to evolve but I think these provide the core of the API.
          John
      
      -------------- next part --------------
      An HTML attachment was scrubbed...
      URL: 
      
      From pminborg at openjdk.org  Mon May 12 14:41:27 2025
      From: pminborg at openjdk.org (Per Minborg)
      Date: Mon, 12 May 2025 14:41:27 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v6]
      In-Reply-To: 
      References: 
      Message-ID: 
      
      > This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      > 
      > Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      
      Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      
        Remove delimiter between JBS issues
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/25177/files
        - new: https://git.openjdk.org/jdk/pull/25177/files/82e68046..7bf3be63
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=05
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=04-05
      
        Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
        Patch: https://git.openjdk.org/jdk/pull/25177.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177
      
      PR: https://git.openjdk.org/jdk/pull/25177
      
      From duke at openjdk.org  Mon May 12 14:43:09 2025
      From: duke at openjdk.org (Johannes Graham)
      Date: Mon, 12 May 2025 14:43:09 GMT
      Subject: RFR: 8356709: Avoid redundant String formatting in
       BigDecimal.valueOf(double)
      Message-ID: 
      
      Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
      
      -------------
      
      Commit messages:
       - add bug number to test, fix typo
       - wait for real bug number to set it in header
       - Dates again
       - Fix licence format
       - Fix licence dates
       - Add licence, update test directives
       - Improve variable names
       - optimize BigDecimal.valueOf(double)
      
      Changes: https://git.openjdk.org/jdk/pull/25173/files
        Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=00
        Issue: https://bugs.openjdk.org/browse/JDK-8356709
        Stats: 188 lines in 4 files changed: 179 ins; 1 del; 8 mod
        Patch: https://git.openjdk.org/jdk/pull/25173.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173
      
      PR: https://git.openjdk.org/jdk/pull/25173
      
      From liach at openjdk.org  Mon May 12 14:43:10 2025
      From: liach at openjdk.org (Chen Liang)
      Date: Mon, 12 May 2025 14:43:10 GMT
      Subject: RFR: 8356709: Avoid redundant String formatting in
       BigDecimal.valueOf(double)
      In-Reply-To: 
      References: 
      Message-ID: 
      
      On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham  wrote:
      
      > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
      
      Thanks for this improvement! Looks great!
      
      Sorry, didn't see your core-libs-dev mail. Created an issue for you at https://bugs.openjdk.org/browse/JDK-8356709
      
      test/jdk/java/math/BigDecimal/ValueOfDouble.java line 14:
      
      > 12: 
      > 13: public class ValueOfDouble {
      > 14:     private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long
      
      Should we consider including 0 in this list?
      
      This file needs a license header, and the jtreg directive should be `/*` instead of `/**` and usually placed before imports, and usually we include a `@bug` tag (once there is an issue ID) and a `@summary` tag.
      
      -------------
      
      PR Review: https://git.openjdk.org/jdk/pull/25173#pullrequestreview-2831469156
      PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2870517444
      PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2083592761
      
      From duke at openjdk.org  Mon May 12 14:43:11 2025
      From: duke at openjdk.org (Johannes Graham)
      Date: Mon, 12 May 2025 14:43:11 GMT
      Subject: RFR: 8356709: Avoid redundant String formatting in
       BigDecimal.valueOf(double)
      In-Reply-To: 
      References: 
      Message-ID: <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>
      
      On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham  wrote:
      
      > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
      
      On Aarch64 M4:
      
      Benchmark                                Mode  Cnt   Score   Error  Units
      + BigDecimals.testValueOfWithDouble        avgt   15   9.913 ? 0.080  ns/op
      - BigDecimals.testValueOfWithDoubleString  avgt   15  65.846 ? 0.801  ns/op
      
      src/java.base/share/classes/java/math/BigDecimal.java line 1398:
      
      > 1396:     public static BigDecimal valueOf(double val) {
      > 1397:         if (!Double.isFinite(val)) {
      > 1398:             throw new NumberFormatException("Infinite or NaN");
      
      Note, this changes the exception message. The new message is consistent with `new BigDecimal(double)`
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2869969120
      PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2083568201
      
      From rgiulietti at openjdk.org  Mon May 12 14:43:11 2025
      From: rgiulietti at openjdk.org (Raffaello Giulietti)
      Date: Mon, 12 May 2025 14:43:11 GMT
      Subject: RFR: 8356709: Avoid redundant String formatting in
       BigDecimal.valueOf(double)
      In-Reply-To: <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>
      References: 
       <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>
      Message-ID: 
      
      On Sun, 11 May 2025 16:32:02 GMT, Johannes Graham  wrote:
      
      >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
      >
      > On Aarch64 M4:
      > 
      > Benchmark                                Mode  Cnt   Score   Error  Units
      > + BigDecimals.testValueOfWithDouble        avgt   15   9.913 ? 0.080  ns/op
      > - BigDecimals.testValueOfWithDoubleString  avgt   15  65.846 ? 0.801  ns/op
      
      @j3graham This seems like a nice improvement.
      I'll take a deeper look in some days from now.
      
      @j3graham Since @liach created the JBS issue, you should change the PR title to match the title of the issue.
      
      > src/java.base/share/classes/java/math/BigDecimal.java line 1398:
      > 
      >> 1396:     public static BigDecimal valueOf(double val) {
      >> 1397:         if (!Double.isFinite(val)) {
      >> 1398:             throw new NumberFormatException("Infinite or NaN");
      > 
      > Note, this changes the exception message. The new message is consistent with `new BigDecimal(double)`
      
      Yeas, we usually only rely on the exception type, not on the specific message, which is not part of the method spec.
      While it is nice to keep the message unchanged over releases, it is sometimes hard to do so consistently.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2872414863
      PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2872438246
      PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2084598684
      
      From rgiulietti at openjdk.org  Mon May 12 14:43:12 2025
      From: rgiulietti at openjdk.org (Raffaello Giulietti)
      Date: Mon, 12 May 2025 14:43:12 GMT
      Subject: RFR: 8356709: Avoid redundant String formatting in
       BigDecimal.valueOf(double)
      In-Reply-To: 
      References: 
      Message-ID: 
      
      On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham  wrote:
      
      > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
      
      macOS 15.4.1 / M1 Pro / 32 GiB RAM
      
      BigDecimals.testValueOfWithDouble        avgt   15    12.448 ?   0.280  ns/op
      BigDecimals.testValueOfWithDoubleString  avgt   15   115.253 ?   4.349  ns/op
      
      src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 38:
      
      > 36:  * f and e meeting d = f 10^e.
      > 37:  * It then rounds d to the appropriate number of digits, as per specification,
      > 38:  * and extracts the digits of both the significand and, where required, the?
      
      Suggestion:
      
       * and extracts the digits of both the significand and, where required, the
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2872554601
      PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2084591912
      
      From duke at openjdk.org  Mon May 12 14:43:12 2025
      From: duke at openjdk.org (Johannes Graham)
      Date: Mon, 12 May 2025 14:43:12 GMT
      Subject: RFR: 8356709: Avoid redundant String formatting in
       BigDecimal.valueOf(double)
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Sun, 11 May 2025 18:45:47 GMT, Chen Liang  wrote:
      
      >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
      >
      > test/jdk/java/math/BigDecimal/ValueOfDouble.java line 14:
      > 
      >> 12: 
      >> 13: public class ValueOfDouble {
      >> 14:     private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long
      > 
      > Should we consider including 0 in this list?
      > 
      > This file needs a license header, and the jtreg directive should be `/*` instead of `/**` and usually placed before imports, and usually we include a `@bug` tag (once there is an issue ID) and a `@summary` tag.
      
      I left out 0 specifically to ensure the all  precisions  were tried. The loop over the exponents effectively adds zeros afterwards.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2083600670
      
      From chen.l.liang at oracle.com  Mon May 12 14:50:38 2025
      From: chen.l.liang at oracle.com (Chen Liang)
      Date: Mon, 12 May 2025 14:50:38 +0000
      Subject: potential performance improvement in sun.nio.cs.UTF_8
      In-Reply-To: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>
      References: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>
      Message-ID: 
      
      Hi Johannes,
      I think the 3rd scenario you've mentioned is likely: we have Swedish or other languages that extend the ascii encoding with diacritics, which are non-ascii bytes are frequently interrupting ascii. For non-ascii heavy languages like Chinese, sometimes the text can include spaces or ascii digits; invoking the intrinsic for that scenario sounds a bit unwise too.
      
      Regards,
      Chen Liang
      ________________________________
      From: core-libs-dev  on behalf of Johannes D?bler 
      Sent: Monday, May 12, 2025 6:16 AM
      To: core-libs-dev at openjdk.org 
      Subject: potential performance improvement in sun.nio.cs.UTF_8
      
      I have a suggestion for a performance improvement in sun.nio.cs.UTF_8, the workhorse for stream based UTF-8 encoding and decoding, but don't know if this has been discussed before.
      I explain my idea for the decoding case:
      Claes Redestad describes in his blog https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html  how he used SIMD intrinsics (now JavaLangAccess.decodeASCII) to speed UTF_8 decoding when buffers are backed by arrays:
      
      https://github.com/openjdk/jdk/blob/0258d9998ebc523a6463818be00353c6ac8b7c9c/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L231
      
        *   first a call to JLA.decodeASCII harvests all ASCII-characters (=1-byte UTF-8 sequence) at the beginning of the input
        *   then enters the slow loop of looking at UTF-8 byte sequences in the input buffer and writing to the output buffer (this is basically the old implementation)
      
      If the input is all ASCII all decoding work is done in JLA.decodeASCII resulting in an extreme performance boost. But if the input contains a non-ASCII it will fall back to the slow array loop.
      
      Now here is my idea: Why not call JLA.decodeASCI whenever an ASCII input is seen:
      
      while (sp < sl) {
          int b1 = sa[sp];
          if (b1 >= 0) {
              // 1 byte, 7 bits: 0xxxxxxx
              if (dp >= dl)
                  return xflow(src, sp, sl, dst, dp, 1);
              // my change
              int n = JLA.decodeASCII(sa, sp, da, dp, Math.min(sl - sp, dl - dp));
              sp += n;
              dp += n;
          } else if ((b1 >> 5) == -2 && (b1 & 0x1e) != 0) {
      
      I setup a small improvised benchmark to get an idea of the impact:
      
      Benchmark                     (data)   Mode  Cnt        Score   Error  Units
      DecoderBenchmark.jdkDecoder  TD_8000  thrpt    2  2045960,037          ops/s
      DecoderBenchmark.jdkDecoder  TD_3999  thrpt    2   263744,675          ops/s
      DecoderBenchmark.jdkDecoder   TD_999  thrpt    2   154232,940          ops/s
      DecoderBenchmark.jdkDecoder   TD_499  thrpt    2   142239,763          ops/s
      DecoderBenchmark.jdkDecoder    TD_99  thrpt    2   128678,229          ops/s
      DecoderBenchmark.jdkDecoder     TD_9  thrpt    2   127388,649          ops/s
      DecoderBenchmark.jdkDecoder     TD_4  thrpt    2   119834,183          ops/s
      DecoderBenchmark.jdkDecoder     TD_2  thrpt    2   111733,115          ops/s
      DecoderBenchmark.jdkDecoder     TD_1  thrpt    2   102397,455          ops/s
      DecoderBenchmark.newDecoder  TD_8000  thrpt    2  2022997,518          ops/s
      DecoderBenchmark.newDecoder  TD_3999  thrpt    2  2909450,005          ops/s
      DecoderBenchmark.newDecoder   TD_999  thrpt    2  2140307,712          ops/s
      DecoderBenchmark.newDecoder   TD_499  thrpt    2  1171970,809          ops/s
      DecoderBenchmark.newDecoder    TD_99  thrpt    2   686771,614          ops/s
      DecoderBenchmark.newDecoder     TD_9  thrpt    2    95181,541          ops/s
      DecoderBenchmark.newDecoder     TD_4  thrpt    2    65656,184          ops/s
      DecoderBenchmark.newDecoder     TD_2  thrpt    2    45439,240          ops/s
      DecoderBenchmark.newDecoder     TD_1  thrpt    2    36994,738          ops/s
      
      (The benchmark uses only memory buffers, each test input is a UTF-8 encoded byte buffer which produces 8000 chars and consists of various length of pure ascii bytes, followed by a 2-byte UTF-8 sequence producing a non-ASCII char:
      TD_8000: 8000 ascii bytes -> 1 call to JLA.decodeASCII
      TD_3999: 3999 ascii bytes + 2 non-ascii bytes, repeated 2 times -> 2 calls to JLA.decodeASCII
      ...
      TD_1: 1 ascii byte + 2 non-ascii bytes, repeated 4000 times -> 4000 calls to JLA.decodeASCII
      
      Interpretation:
      
        *   Input all ASCII: same performance as before
        *   Input contains pure ASCII sequence of considerable length interrupted by non ASCII bytes: now seeing huge performance improvements similar to the pure ASCII case.
        *   Input has lot of short sequences of ASCII-bytes interrupted by non ASCII bytes: at some point performance drops below current implementation.
      
      Thanks for reading and happy to hear your opinions,
      Johannes
      
      -------------- next part --------------
      An HTML attachment was scrubbed...
      URL: 
      
      From jpai at openjdk.org  Mon May 12 14:54:52 2025
      From: jpai at openjdk.org (Jaikiran Pai)
      Date: Mon, 12 May 2025 14:54:52 GMT
      Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
       again with junit action timed out [v6]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Mon, 12 May 2025 14:41:27 GMT, Per Minborg  wrote:
      
      >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
      >> 
      >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
      >
      > Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Remove delimiter between JBS issues
      
      Looks good to me and thank you for the updates.
      
      If this was failing every single time in tier5, then it might be useful to run these changes once in tier5 in our CI before integrating.
      
      -------------
      
      Marked as reviewed by jpai (Reviewer).
      
      PR Review: https://git.openjdk.org/jdk/pull/25177#pullrequestreview-2833538419
      
      From liach at openjdk.org  Mon May 12 15:07:00 2025
      From: liach at openjdk.org (Chen Liang)
      Date: Mon, 12 May 2025 15:07:00 GMT
      Subject: RFR: 8356080: Address post-integration comments for Stable Values
       [v3]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Mon, 12 May 2025 07:42:16 GMT, Per Minborg  wrote:
      
      >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
      >> 
      >> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
      >> 
      >> Unfortunately, this PR shows the total commit history for stable values.
      >
      > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits:
      > 
      >  - Address comments
      >  - Merge branch 'master' into jep502-followup
      >  - Fix an issue with toString on nested constructs
      >  - Merge branch 'master' into jep502-followup
      >  - Merge branch 'master' into jep502-followup
      >  - Update src/java.base/share/classes/java/lang/StableValue.java
      >    
      >    Co-authored-by: Chen Liang 
      >  - Simplify furhter
      >  - Address comments in PR
      >  - Merge master
      >  - Remove unused method and add comment
      >  - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336
      
      lgtm!
      
      -------------
      
      Marked as reviewed by liach (Reviewer).
      
      PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2833581429
      
      From rriggs at openjdk.org  Mon May 12 15:24:51 2025
      From: rriggs at openjdk.org (Roger Riggs)
      Date: Mon, 12 May 2025 15:24:51 GMT
      Subject: RFR: 8356694: Removed unused subclass audits in
       ObjectInput/OutputStream
      In-Reply-To: 
      References: 
      Message-ID: 
      
      On Mon, 12 May 2025 02:18:05 GMT, Chen Liang  wrote:
      
      > These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
      > 
      > Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress
      
      looks good
      
      -------------
      
      Marked as reviewed by rriggs (Reviewer).
      
      PR Review: https://git.openjdk.org/jdk/pull/25174#pullrequestreview-2833637774
      
      From liach at openjdk.org  Mon May 12 15:24:52 2025
      From: liach at openjdk.org (Chen Liang)
      Date: Mon, 12 May 2025 15:24:52 GMT
      Subject: RFR: 8356694: Removed unused subclass audits in
       ObjectInput/OutputStream
      In-Reply-To: 
      References: 
      Message-ID: 
      
      On Mon, 12 May 2025 02:18:05 GMT, Chen Liang  wrote:
      
      > These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
      > 
      > Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress
      
      Thanks for the reviews! JDK tier 1-3 all pass. Will wait for review from all time zones before integrating.
      
      -------------
      
      PR Comment: https://git.openjdk.org/jdk/pull/25174#issuecomment-2873005732
      
      From kvn at openjdk.org  Mon May 12 15:39:52 2025
      From: kvn at openjdk.org (Vladimir Kozlov)
      Date: Mon, 12 May 2025 15:39:52 GMT
      Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
       Ergonomics [v4]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Wed, 7 May 2025 05:11:01 GMT, Ioi Lam  wrote:
      
      >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
      >> 
      >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
      >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
      >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
      >> 
      >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
      >> 
      >> Examples:
      >> 
      >> 
      >> # Create an AOT cache with a single command:
      >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
      >> Hello World
      >> Temporary AOTConfiguration recorded: foo.aot.config
      >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
      >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
      >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
      >> AOTCache creation is complete: foo.aot 10240000 bytes
      >> 
      >> # Create logging file for the AOT cache assembly phase
      >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
      >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
      >> 
      >> 
      >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
      >
      > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java
      
      @dholmes-ora pointed that we forgot update Java man page with new AOT flags.
      @iklam, please do that here for this JEP and JEP 483.
      
      -------------
      
      Changes requested by kvn (Reviewer).
      
      PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2833694086
      
      From jd at civilian-framework.org  Mon May 12 15:46:24 2025
      From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
      Date: Mon, 12 May 2025 17:46:24 +0200
      Subject: potential performance improvement in sun.nio.cs.UTF_8
      In-Reply-To: 
      References: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>
       
      Message-ID: 
      
      Hi Chen,
      
      thanks for your feedback. Indeed it does not make sense to optimize 
      UTF-8 processing for a rather vague set of beneficiaries when there are 
      realistic counterexamples.
      Still I don't want to give up on my idea too early :-)
      I tried this modification:
      
        * harvest pure ASCII-bytes before the loop (as in the current decoder)
        * within the loop if a 1-byte-UTF8-sequence is recognized invoke
          JLA.decodeAscii but only limited times (e.g. 10), else just copy the
          byte to the output buffer (like in the current implementation)
        * in my benchmark timings this give the JLA.decodeAscii-boost for
          inputs which have rather long ASCII input sequences, whereas not
          degrading performance due to JLA call overhead in other scenarios
      
      Thanks
      Johannes
      -------------- next part --------------
      An HTML attachment was scrubbed...
      URL: 
      
      From rriggs at openjdk.org  Mon May 12 15:58:25 2025
      From: rriggs at openjdk.org (Roger Riggs)
      Date: Mon, 12 May 2025 15:58:25 GMT
      Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with
       OOME
      Message-ID: 
      
      The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's.
      It could be reliably reproduced with the serialGC and parallelGC's.
      
      Raise the memory limit from 6G to 8G to accommodate the new test with all GCs.
      
      -------------
      
      Commit messages:
       - 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME
      
      Changes: https://git.openjdk.org/jdk/pull/25186/files
        Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25186&range=00
        Issue: https://bugs.openjdk.org/browse/JDK-8356695
        Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
        Patch: https://git.openjdk.org/jdk/pull/25186.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25186/head:pull/25186
      
      PR: https://git.openjdk.org/jdk/pull/25186
      
      From alanb at openjdk.org  Mon May 12 16:06:52 2025
      From: alanb at openjdk.org (Alan Bateman)
      Date: Mon, 12 May 2025 16:06:52 GMT
      Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
       [v3]
      In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
      References: 
       <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
      Message-ID: 
      
      On Mon, 12 May 2025 10:16:33 GMT, David Beaumont  wrote:
      
      >> Adding read-only support to ZipFileSystem.
      >> 
      >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
      >> 
      >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
      >> 
      >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
      >
      > David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Fix comment based on current behaviour.
      
      src/jdk.zipfs/share/classes/module-info.java line 160:
      
      > 158:  *       will always be opened read-write (see {@code "accessMode"}
      > 159:  *       below), regardless of whether the underlying ZIP already existed or
      > 160:  *       not.
      
      In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist.
      
      For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system.
      
      src/jdk.zipfs/share/classes/module-info.java line 281:
      
      > 279:  *       Even if a zip file system is writable ({@code fs.isReadOnly() == false}),
      > 280:  *       this says nothing about whether individual files can be created or
      > 281:  *       modified, simply that it might be possible.
      
      Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean?
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084997941
      PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085009060
      
      From abarashev at openjdk.org  Mon May 12 16:12:04 2025
      From: abarashev at openjdk.org (Artur Barashev)
      Date: Mon, 12 May 2025 16:12:04 GMT
      Subject: RFR: 8353113: Peer supported certificate signature algorithms are not
       being checked with default SunX509 key manager
      Message-ID: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
      
      When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
      https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
      https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
      
      X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
      
      -------------
      
      Commit messages:
       - Add unit test
       - Code refactoring
       - Fix open unit tests
       - Adding a system property to skip the constraints checking. Remove SunX509c.
       - Fix constraints check
       - Revert SSLHandshake.java. Set SunX509c as default. Update copyright.
       - 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager
       - Address review comments
       - Skip explicit KeyPair initialization and let the provider default set it
       - Rework unit tests
       - ... and 3 more: https://git.openjdk.org/jdk/compare/cd8adf13...75528109
      
      Changes: https://git.openjdk.org/jdk/pull/25016/files
        Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=00
        Issue: https://bugs.openjdk.org/browse/JDK-8353113
        Stats: 1168 lines in 15 files changed: 769 ins; 333 del; 66 mod
        Patch: https://git.openjdk.org/jdk/pull/25016.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016
      
      PR: https://git.openjdk.org/jdk/pull/25016
      
      From scolebourne at joda.org  Mon May 12 16:28:28 2025
      From: scolebourne at joda.org (Stephen Colebourne)
      Date: Mon, 12 May 2025 17:28:28 +0100
      Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
      In-Reply-To: 
      References: <8721e7784793451187c5b6099eb37756@amazon.com>
       <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
       <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
       
       
       <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
       
       <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
       
       
       
       <4741eceb3beb40c2bc82613c67836d66@amazon.com>
       
       
       
       <4c4aac5737d844a4959885c65f17efee@amazon.com>
       <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
       <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>
       
       
       
      Message-ID: 
      
      I agree that ByteArrayOutputStream is a problem child, and often a
      performance pain. While it probably doesn't add much to the debate, I
      recently wrote my own replacement class
      https://github.com/JodaOrg/joda-beans/blob/main/src/main/java/org/joda/beans/ser/LinkedByteArrayOutputStream.java
      thanks
      Stephen
      
      
      On Mon, 12 May 2025 at 15:36, Engebretson, John  wrote:
      >
      >   Friendly ping.  There seems to be support for this idea in some form (especially on the PR) but I haven?t received anything definitive from this email discussion.  The safest proposal on the table is from @liach: make this a JDK-internal class (for now) and modify JDK classes to rely on it.  Assuming good results, we consider making it public in future releases.
      >
      >   Could I please get some form of signoff from the core team?  I?d really like to deliver something here soon, otherwise I have to move on.
      >
      >   Thank you very much!  ?
      >
      >     John
      >
      >
      >
      > From: core-libs-dev  On Behalf Of Engebretson, John
      > Sent: Tuesday, April 22, 2025 7:52 AM
      >
      >
      >
      >   Thank you Alan!  I?ll try to address each of your points, apologies if I miss anything:
      >
      >
      >
      >         Maybe the two efforts should be separated.
      >
      >
      >
      >   I?m good with that, and will operate that way unless someone argues otherwise.
      >
      >
      >
      >        The factory methods can return a different implementation, in particular BAOS.unsynchronized (or whatever name it gets) does not need to collect the bytes in a contiguous array. So having a BAOS.unsynchronized may help with some of the scenarios that you are looking at.
      >
      >
      >
      >   I think this is a clever way to go and I?m in favor? just not sold on the name.  I won?t abandon the effort if you feel otherwise.  ?  Let me know if we?re ready to proceed with this or another name.
      >
      >
      >
      >       I think the PR proposing MemoryOutputStream is a bit premature
      >
      >
      >
      >   This was intended solely to share code for discussion, and it?s been effective in that sense.  I agree that the PR is nowhere near merging.
      >
      >
      >
      >       Maybe you have explored a segment like API or a cursor or consumer API to handle the bytes?
      >
      >
      >
      >   The current version of the PR is along these lines, providing one public class whose contents are available via views (SeekableByteChannel, BAOS, ByteArrayInputStream) as well as the usual add/write/updates, long size(), and lambda-based applyToSegment(Function) and applyToIndex(Function).  The public wrapping needs to evolve but I think these provide the core of the API.
      >
      >     John
      >
      >
      
      From archie.cobbs at gmail.com  Mon May 12 17:00:39 2025
      From: archie.cobbs at gmail.com (Archie Cobbs)
      Date: Mon, 12 May 2025 12:00:39 -0500
      Subject: Proposal: Add new methods get(int) and set(int, E) to ArrayDeque
      Message-ID: 
      
      I was wondering for the n'th time why ArrayDeque does not have
      get(int) and set(int,
      E) methods and eventually came across JDK-8143850
       which was created 10 years
      ago...
      
      This comment exactly describes my own experience:
      
      People write code, they need an "addFirst" or "removeLast" type method.
      > Especially for "removeLast" they find that for List this is the rather
      > wordy "list.remove(list.size() - 1);" with that ugly -1 constant. So they
      > try an ArrayDeque, and are happy that these methods exist there and show
      > the intent clearly... only to find a few minutes later that ArrayDeque
      > doesn't have a get by index method, even though the structure can support
      > that trivially in O(1) time -- people really expect it to be there, as an
      > queue backed by an array almost implies it. I'm pretty sure that it is the
      > 3rd or 4th time I tried using an ArrayDeque over the past few years only to
      > realize (again) that this method is missing.
      
      
      I would like to offer to do the following:
      
         - Change the title of this bug from "retrofit ArrayDeque to implement
         List" to "Add indexed get() and set() methods to ArrayDeque"
      
      
         - Propose a corresponding PR and CSR to add get(int) and set(int, E)
         methods to ArrayDeque
      
      But first I want to check with this list first to see if there are any
      objections?
      
      Thanks,
      -Archie
      
      -- 
      Archie L. Cobbs
      -------------- next part --------------
      An HTML attachment was scrubbed...
      URL: 
      
      From markus.karg at gmx.net  Sun May 11 06:45:39 2025
      From: markus.karg at gmx.net (Markus KARG)
      Date: Sun, 11 May 2025 08:45:39 +0200
      Subject: RFC: 8356679: Using CharSequence::getChars internally
      Message-ID: 
      
      Dear Core Libs Team,
      
      I am hereby requesting comments on JDK-8356679.
      
      I would like to invest some time and set up a PR implementing Chen 
      Liangs's proposal laid out in 
      https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, the 
      text of that JBS is copied below. According to the Developer's Guide I 
      do need to get broad agreement BEFORE filing a PR. Therefore, I kindly 
      ask everybody to briefly show consent, so I may file a PR.
      
      Thanks
      -Markus
      
      
      Copy from https://bugs.openjdk.org/browse/JDK-8356679:
      
      Recently OpenJDK adopted the new method CharSequence::getChars(int, int, 
      char[], int) for inclusion in Java 25. As a bulk reader method, it 
      allows potentially improved efficiency over the previously available 
      char-by-char reader method CharSequence::charAt(int).
      
      Chen Liang suggested on March 23rd on the core-lib-dev mailing list to 
      use the new method within the internal source code of OpenJDK for the 
      implementation of Appendables (see 
      https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
      The idea behind this is that the implementations might be more efficient 
      then.
      
      A quick analysis of the OpenJDK source code identified (at least) the 
      following classes which could potentially run more efficient when using 
      CharSequence::getChars internally, thanks to bulk reading and / or 
      prevention of internal copies / toString() conversions:
      * java.io.Writer
      * java.io.StringWriter
      * java.io.PrintWriter
      * java.io.BufferedWriter
      * java.io.CharArrayWriter
      * java.io.FileWriter
      * java.io.OutputStreamWriter
      * sun.nio.cs.StreamEncoder
      * java.io.PrintStream
      * java.nio.CharBuffer
      
      In the sense of "eat your own dog food", it makes sense to implement 
      Chen's idea in (at least) those classes. Possibly more classes could get 
      identified when taking a deeper look. Besides the potential efficiency 
      improvements, it would be a good show case for the usage of the new API.
      
      The risk of this change should be low, as test coverage exists, and as 
      the intended changes are solely internal to the implementation. No API 
      will get changed. In some cases the JavaDocs will get slightly adapted 
      where it currently exposes the actual implementation (to not lie in future).
      
      
      From godmlzkf1 at naver.com  Tue May  6 07:18:35 2025
      From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=)
      Date: Tue, 06 May 2025 16:18:35 +0900
      Subject: =?utf-8?B?VW5uZWNlc3NhcnkgbG9naWMgaXMgYWRkZWQgdG8gcmVtb3ZlRmlyc3QgYW5kIHJlbW92ZQ==?=
       =?utf-8?B?TGFzdCBvZiBBcnJheUxpc3Qu?=
      Message-ID: 
      
      Hi.
      
      In removeFirst, if size is not 0, the logic is the same as the remove logic.
      
      removeLast also has the same logic as remove when size is not exceeded.
      
      I want to fix this.
      
      thank you.
      -------------- next part --------------
      An HTML attachment was scrubbed...
      URL: 
      
      From rriggs at openjdk.org  Mon May 12 17:20:03 2025
      From: rriggs at openjdk.org (Roger Riggs)
      Date: Mon, 12 May 2025 17:20:03 GMT
      Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
       [v5]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Mon, 12 May 2025 10:17:46 GMT, Volkan Yazici  wrote:
      
      >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
      >
      > Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
      > 
      >  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
      >  - Fix `HexDigits` copyright year
      
      src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328:
      
      > 326:      * {@linkplain java.nio.charset.Charset charset}.
      > 327:      * 

      > 328: * WARNING: This method return the {@code byte[]} backing the provided Suggestion: * WARNING: This method returns the {@code byte[]} backing the provided Should this more explicitly say the returned byte array must not be modified? src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 413: > 411: > 412: /** > 413: * Encodes ASCII codepoints as possible from the source array into Suggestion: * Encodes as many ASCII codepoints as possible from the source array into ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085106836 PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085112564 From alanb at openjdk.org Mon May 12 17:25:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 May 2025 17:25:55 GMT Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v6] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 14:41:27 GMT, Per Minborg wrote: >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. >> >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove delimiter between JBS issues Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25177#pullrequestreview-2833962965 From rgiulietti at openjdk.org Mon May 12 17:40:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 12 May 2025 17:40:51 GMT Subject: RFR: 8077587: BigInteger Roots [v6] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 11:57:32 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch > - Restore nthRoot() public methods in BigInteger.java @fabioromano1 Is [this proof](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf) still relevant? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2873412219 From bchristi at openjdk.org Mon May 12 17:50:51 2025 From: bchristi at openjdk.org (Brent Christian) Date: Mon, 12 May 2025 17:50:51 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property In-Reply-To: References: Message-ID: On Sat, 10 May 2025 00:25:23 GMT, Naoto Sato wrote: > I think `test/jdk/java/lang/System/NonAnsiFileEncodingTest.java` can be removed, as it does not provide any value today OK, great! Thanks, Naoto. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25163#issuecomment-2873452048 From bchristi at openjdk.org Mon May 12 17:55:33 2025 From: bchristi at openjdk.org (Brent Christian) Date: Mon, 12 May 2025 17:55:33 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v2] In-Reply-To: References: Message-ID: <4-ABB3u3CsP-o3Y-daEGVJuOi_MkYdqzz5I9oJAL_T0=.aec2d7cf-850b-48b2-9602-96fa5f6e3cd6@github.com> > For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. > > Automated test results are omitted as expected. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: NonAnsiFileEncodingTest.java is no longer applicable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25163/files - new: https://git.openjdk.org/jdk/pull/25163/files/c5a255a8..737b222d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=00-01 Stats: 64 lines in 1 file changed: 0 ins; 64 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25163/head:pull/25163 PR: https://git.openjdk.org/jdk/pull/25163 From bchristi at openjdk.org Mon May 12 17:58:29 2025 From: bchristi at openjdk.org (Brent Christian) Date: Mon, 12 May 2025 17:58:29 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v3] In-Reply-To: References: Message-ID: > For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. > > Automated test results are omitted as expected. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: apostrophize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25163/files - new: https://git.openjdk.org/jdk/pull/25163/files/737b222d..5b05ee36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25163/head:pull/25163 PR: https://git.openjdk.org/jdk/pull/25163 From roger.riggs at oracle.com Mon May 12 18:18:20 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 12 May 2025 14:18:20 -0400 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: References: Message-ID: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> Hi Markus, On the surface, its looks constructive. I suspect that many of these cases will turn into discussions about the right/best/better way to buffer the characters. The getChars method only helps when extracting to a char array, many of the current implementations create strings as the intermediary. The advantage of the 1 character at a time technique is not needing a (separated allocated) buffer. Consider taking a few at a time before launching into the whole set. $.02, Roger On 5/11/25 2:45 AM, Markus KARG wrote: > Dear Core Libs Team, > > I am hereby requesting comments on JDK-8356679. > > I would like to invest some time and set up a PR implementing Chen > Liangs's proposal laid out in > https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, the > text of that JBS is copied below. According to the Developer's Guide I > do need to get broad agreement BEFORE filing a PR. Therefore, I kindly > ask everybody to briefly show consent, so I may file a PR. > > Thanks > -Markus > > > Copy from https://bugs.openjdk.org/browse/JDK-8356679: > > Recently OpenJDK adopted the new method CharSequence::getChars(int, > int, char[], int) for inclusion in Java 25. As a bulk reader method, > it allows potentially improved efficiency over the previously > available char-by-char reader method CharSequence::charAt(int). > > Chen Liang suggested on March 23rd on the core-lib-dev mailing list to > use the new method within the internal source code of OpenJDK for the > implementation of Appendables (see > https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). > The idea behind this is that the implementations might be more > efficient then. > > A quick analysis of the OpenJDK source code identified (at least) the > following classes which could potentially run more efficient when > using CharSequence::getChars internally, thanks to bulk reading and / > or prevention of internal copies / toString() conversions: > * java.io.Writer > * java.io.StringWriter > * java.io.PrintWriter > * java.io.BufferedWriter > * java.io.CharArrayWriter > * java.io.FileWriter > * java.io.OutputStreamWriter > * sun.nio.cs.StreamEncoder > * java.io.PrintStream > * java.nio.CharBuffer > > In the sense of "eat your own dog food", it makes sense to implement > Chen's idea in (at least) those classes. Possibly more classes could > get identified when taking a deeper look. Besides the potential > efficiency improvements, it would be a good show case for the usage of > the new API. > > The risk of this change should be low, as test coverage exists, and as > the intended changes are solely internal to the implementation. No API > will get changed. In some cases the JavaDocs will get slightly adapted > where it currently exposes the actual implementation (to not lie in > future). > From rriggs at openjdk.org Mon May 12 18:35:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 May 2025 18:35:53 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:11:54 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/StringUTF16.java line 1322: >> >>> 1320: val, >>> 1321: Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1), >>> 1322: ((long) (end - off)) << 1); >> >> This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is. > >> This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is. > > The core library also uses Unsafe.copyMemory in many places. Can it be used in this scenario? Or can we find other ways to copy char[] to byte[]? You may have overlooked the behavior of putChar to swap the order of the bytes depending on whether its big or little endian. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2085236701 From naoto at openjdk.org Mon May 12 18:40:50 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 12 May 2025 18:40:50 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v3] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 17:58:29 GMT, Brent Christian wrote: >> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. >> >> Automated test results are omitted as expected. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > apostrophize LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25163#pullrequestreview-2834153460 From abarashev at openjdk.org Mon May 12 18:45:10 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 12 May 2025 18:45:10 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v2] In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> Message-ID: <1Gpnwbv3_IexuWpsDF0ebvnlgcVpRzY_t3NTR639sMA=.c69a02d9-8139-4068-bfba-23ba8424b5f7@github.com> > When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3 > > X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Add PeerConstraintsCheck unit test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25016/files - new: https://git.openjdk.org/jdk/pull/25016/files/75528109..88cd4016 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=00-01 Stats: 284 lines in 3 files changed: 277 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016 PR: https://git.openjdk.org/jdk/pull/25016 From vyazici at openjdk.org Mon May 12 19:13:29 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 12 May 2025 19:13:29 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v6] In-Reply-To: References: Message-ID: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Roger Riggs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24982/files - new: https://git.openjdk.org/jdk/pull/24982/files/5da9465c..0ac2101a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From duke at openjdk.org Mon May 12 19:25:53 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 12 May 2025 19:25:53 GMT Subject: RFR: 8077587: BigInteger Roots [v6] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 17:37:54 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch >> - Restore nthRoot() public methods in BigInteger.java > > @fabioromano1 Is [this proof](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf) still relevant? @rgiulietti No, the proof of the recurrence used is the one by Zimmermann linked in the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2873741605 From liach at openjdk.org Mon May 12 19:29:53 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 12 May 2025 19:29:53 GMT Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME In-Reply-To: References: Message-ID: On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs wrote: > The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's. > It could be reliably reproduced with the serialGC and parallelGC's. > > Raise the memory limit from 6G to 8G to accommodate the new test with all GCs. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25186#pullrequestreview-2834264417 From vyazici at openjdk.org Mon May 12 19:42:15 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 12 May 2025 19:42:15 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into jla - Improve `uncheckedGetBytesNoRepl` docs - Apply suggestions from code review Co-authored-by: Roger Riggs - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` - Fix `HexDigits` copyright year - Fix copyright years - Prefix touched methods with `unchecked` - Fix typo in pre-existing JavaDoc - Improve `JavaLangAccess` documentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24982/files - new: https://git.openjdk.org/jdk/pull/24982/files/0ac2101a..0e06ce1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=05-06 Stats: 38505 lines in 1296 files changed: 26044 ins; 7087 del; 5374 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From vyazici at openjdk.org Mon May 12 19:42:15 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 12 May 2025 19:42:15 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v5] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 17:07:57 GMT, Roger Riggs wrote: >> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: >> >> - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` >> - Fix `HexDigits` copyright year > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328: > >> 326: * {@linkplain java.nio.charset.Charset charset}. >> 327: *

      >> 328: * WARNING: This method return the {@code byte[]} backing the provided > > Suggestion: > > * WARNING: This method returns the {@code byte[]} backing the provided > > Should this more explicitly say the returned byte array must not be modified? Improved as suggested in cd156fbab46. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085329577 From lancea at openjdk.org Mon May 12 19:49:52 2025 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 12 May 2025 19:49:52 GMT Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME In-Reply-To: References: Message-ID: On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs wrote: > The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's. > It could be reliably reproduced with the serialGC and parallelGC's. > > Raise the memory limit from 6G to 8G to accommodate the new test with all GCs. Looks good to me ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25186#pullrequestreview-2834305295 From rgiulietti at openjdk.org Mon May 12 19:58:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 12 May 2025 19:58:51 GMT Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME In-Reply-To: References: Message-ID: On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs wrote: > The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's. > It could be reliably reproduced with the serialGC and parallelGC's. > > Raise the memory limit from 6G to 8G to accommodate the new test with all GCs. Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25186#pullrequestreview-2834324813 From rriggs at openjdk.org Mon May 12 20:04:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 May 2025 20:04:56 GMT Subject: Integrated: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME In-Reply-To: References: Message-ID: <7fKJIeDWzh9ebXj2hju1EzYfcDyRVBmfJzn_bgHNqVg=.9092cad6-b6ae-444a-822b-b4712a2c19e9@github.com> On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs wrote: > The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's. > It could be reliably reproduced with the serialGC and parallelGC's. > > Raise the memory limit from 6G to 8G to accommodate the new test with all GCs. This pull request has now been integrated. Changeset: 0f5c6081 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/0f5c608143413bc0d40fca31e097c7b40c7a6618 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME Reviewed-by: liach, lancea, rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/25186 From abarashev at openjdk.org Mon May 12 20:05:18 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 12 May 2025 20:05:18 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3] In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> Message-ID: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com> > When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3 > > X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Make sure the exception happens during KeyManager's algorithm check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25016/files - new: https://git.openjdk.org/jdk/pull/25016/files/88cd4016..5c137c14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=01-02 Stats: 17 lines in 1 file changed: 2 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016 PR: https://git.openjdk.org/jdk/pull/25016 From duke at openjdk.org Mon May 12 20:11:18 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 12 May 2025 20:11:18 GMT Subject: RFR: 8077587: BigInteger Roots [v7] In-Reply-To: References: Message-ID: <2CM-BPYVSY7yVGxTMnU-R1-Vd0OD5g9kMy3zw4BjW1M=.7532a6d6-91f5-4cda-ad23-0db6d00965ec@github.com> > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Factor out newton's recurrence in a separate method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/823d2f63..30a1b828 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=05-06 Stats: 29 lines in 1 file changed: 15 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From duke at openjdk.org Mon May 12 20:15:52 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 May 2025 20:15:52 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 16:04:22 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > src/jdk.zipfs/share/classes/module-info.java line 281: > >> 279: * Even if a zip file system is writable ({@code fs.isReadOnly() == false}), >> 280: * this says nothing about whether individual files can be created or >> 281: * modified, simply that it might be possible. > > Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean? Hmm, you're right, it's not totally clear. It's trying to draw the same sort of distinction that you have with mounted file systems, in which the mode that something is mounted in doesn't override any underlying read-only state. For example you can still open a ZipFileSystem for a ZIP file which is on a remote drive, where the permissions show the underlying file as "writable", but an attempt to modify the contents would still fail. The POSIX stuff is mentioned at the end, and while it's related, it's not quite the same point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085372871 From duke at openjdk.org Mon May 12 20:19:09 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 12 May 2025 20:19:09 GMT Subject: RFR: 8077587: BigInteger Roots [v8] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: correct typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/30a1b828..3e3d45c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From duke at openjdk.org Mon May 12 20:21:51 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 May 2025 20:21:51 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 15:57:35 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > src/jdk.zipfs/share/classes/module-info.java line 160: > >> 158: * will always be opened read-write (see {@code "accessMode"} >> 159: * below), regardless of whether the underlying ZIP already existed or >> 160: * not. > > In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist. > > For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system. Is this comment just agreeing with the proposed behaviour stated here? At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests). The only allowed access mode options with "create" are "readWrite" or , and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085381219 From liach at openjdk.org Mon May 12 20:25:57 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 12 May 2025 20:25:57 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2834380249 From jlu at openjdk.org Mon May 12 20:37:58 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 May 2025 20:37:58 GMT Subject: RFR: 8348351: Improve lazy initialization of the available currencies set [v2] In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com> References: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com> Message-ID: On Thu, 8 May 2025 23:30:06 GMT, Justin Lu wrote: >> Please review this PR which stems from discussion in the PR of JDK-8347949. >> >> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. >> >> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.) > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Chen's review - method name clarification Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25134#issuecomment-2873923357 From jlu at openjdk.org Mon May 12 20:37:59 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 May 2025 20:37:59 GMT Subject: Integrated: 8348351: Improve lazy initialization of the available currencies set In-Reply-To: References: Message-ID: On Thu, 8 May 2025 22:55:34 GMT, Justin Lu wrote: > Please review this PR which stems from discussion in the PR of JDK-8347949. > > The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. > > (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.) This pull request has now been integrated. Changeset: b6b5ac1e Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/b6b5ac1ef9042ed62a8358aa6943b8dc87dcf0ab Stats: 46 lines in 1 file changed: 3 ins; 2 del; 41 mod 8348351: Improve lazy initialization of the available currencies set Reviewed-by: liach, naoto ------------- PR: https://git.openjdk.org/jdk/pull/25134 From duke at openjdk.org Mon May 12 21:00:01 2025 From: duke at openjdk.org (Luca Kellermann) Date: Mon, 12 May 2025 21:00:01 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v3] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 07:42:16 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits: > > - Address comments > - Merge branch 'master' into jep502-followup > - Fix an issue with toString on nested constructs > - Merge branch 'master' into jep502-followup > - Merge branch 'master' into jep502-followup > - Update src/java.base/share/classes/java/lang/StableValue.java > > Co-authored-by: Chen Liang > - Simplify furhter > - Address comments in PR > - Merge master > - Remove unused method and add comment > - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336 src/java.base/share/classes/java/lang/StableValue.java line 730: > 728: *

      > 729: * Any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are > 730: * also stable. You resolved https://github.com/openjdk/jdk/pull/23972#discussion_r2058903119, so the following lines can also get rid of "direct": https://github.com/openjdk/jdk/blob/fbc4691bfa11f31601fd89d05da63e689343e214/src/java.base/share/classes/java/lang/StableValue.java#L687-L688 src/java.base/share/classes/java/util/ImmutableCollections.java line 518: > 516: > 517: private boolean allowNulls() { > 518: return root instanceof ListN listN && listN.allowNulls; I think this should stay here (or some other change is needed). `StableSubList` doesn't override `indexOf` and `lastIndexOf`, so they will throw when given `null`, even though the list could contain `null`. src/java.base/share/classes/java/util/ImmutableCollections.java line 884: > 882: @Override > 883: public String toString() { > 884: return StableUtil.renderElements(this, "StableList", delegates); Suggestion: return StableUtil.renderElements(this, "StableCollection", delegates); I think `StableList`, `StableSubList`, `StableReverseOrderListView`, `StableMapEntrySet` and `StableMapValues` should all use `"StableCollection"` to be consistent with `AbstractCollection`'s use of `"Collection"`. `StableMap` should use `"StableMap"` to be consistent with `AbstractMap`'s use of `"Map"`. src/java.base/share/classes/java/util/ImmutableCollections.java line 1660: > 1658: @Override > 1659: public String toString() { > 1660: return StableUtil.renderMappings(this, "StableSet", delegateEntrySet, false); Suggestion: return StableUtil.renderMappings(this, "StableCollection", delegateEntrySet, false); I think `StableList`, `StableSubList`, `StableReverseOrderListView`, `StableMapEntrySet` and `StableMapValues` should all use `"StableCollection"` to be consistent with `AbstractCollection`'s use of `"Collection"`. `StableMap` should use `"StableMap"` to be consistent with `AbstractMap`'s use of `"Map"`. src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 70: > 68: } > 69: final int index = value.ordinal() - firstOrdinal; > 70: final StableValueImpl delegate; Suggestion: This local variable is no longer used. src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 57: > 55: UNSAFE.objectFieldOffset(StableValueImpl.class, "contents"); > 56: > 57: // Used to indicate a holder value is `null` (see field `value` below) Suggestion: // Used to indicate a holder value is `null` (see field `contents` below) The field is named `contents`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085444718 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085348072 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085372556 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085422959 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085265954 PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085289780 From duke at openjdk.org Mon May 12 21:00:03 2025 From: duke at openjdk.org (Luca Kellermann) Date: Mon, 12 May 2025 21:00:03 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v2] In-Reply-To: <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com> References: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com> <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com> Message-ID: On Fri, 9 May 2025 14:53:59 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits: >> >> - Fix an issue with toString on nested constructs >> - Merge branch 'master' into jep502-followup >> - Merge branch 'master' into jep502-followup >> - Update src/java.base/share/classes/java/lang/StableValue.java >> >> Co-authored-by: Chen Liang >> - Simplify furhter >> - Address comments in PR >> - Merge master >> - Remove unused method and add comment >> - Address comments >> - Merge branch 'master' into jep502-followup >> - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504 > > src/java.base/share/classes/java/util/ImmutableCollections.java line 1715: > >> 1713: >> 1714: // For @ValueBased >> 1715: static private LazyMapIterator of(StableMapEntrySet outer) { > > Suggestion: > > private static LazyMapIterator of(StableMapEntrySet outer) { This doesn't seem to be resolved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085387406 From duke at openjdk.org Mon May 12 21:05:04 2025 From: duke at openjdk.org (Luca Kellermann) Date: Mon, 12 May 2025 21:05:04 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v3] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 07:42:16 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits: > > - Address comments > - Merge branch 'master' into jep502-followup > - Fix an issue with toString on nested constructs > - Merge branch 'master' into jep502-followup > - Merge branch 'master' into jep502-followup > - Update src/java.base/share/classes/java/lang/StableValue.java > > Co-authored-by: Chen Liang > - Simplify furhter > - Address comments in PR > - Merge master > - Remove unused method and add comment > - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336 I noticed that this code will throw `NoSuchElementException` instead of `IndexOutOfBoundsException` and will swallow the message because of the `try`/`catch` in `ImmutableCollections.ListItr.next`/`previous`: StableValue .list(42, _ -> {throw new IndexOutOfBoundsException("important message");}) .listIterator(5) .next(); // same for previous() Do you plan to implement this suggestion: https://github.com/openjdk/jdk/pull/23972#discussion_r2050713377? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2874060190 PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2874062775 From bpb at openjdk.org Mon May 12 21:06:03 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 May 2025 21:06:03 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v16] In-Reply-To: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com> Message-ID: On Tue, 6 May 2025 15:43:07 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test > Both methods will need to specify what they return when already at end of stream, does readAllAsString return an empty or null, Empty string. > does readAllLines return an empty list? Empty list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2874062856 From duke at openjdk.org Mon May 12 21:15:04 2025 From: duke at openjdk.org (Luca Kellermann) Date: Mon, 12 May 2025 21:15:04 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v3] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:53:41 GMT, Luca Kellermann wrote: >> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits: >> >> - Address comments >> - Merge branch 'master' into jep502-followup >> - Fix an issue with toString on nested constructs >> - Merge branch 'master' into jep502-followup >> - Merge branch 'master' into jep502-followup >> - Update src/java.base/share/classes/java/lang/StableValue.java >> >> Co-authored-by: Chen Liang >> - Simplify furhter >> - Address comments in PR >> - Merge master >> - Remove unused method and add comment >> - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336 > > src/java.base/share/classes/java/util/ImmutableCollections.java line 518: > >> 516: >> 517: private boolean allowNulls() { >> 518: return root instanceof ListN listN && listN.allowNulls; > > I think this should stay here (or some other change is needed). `StableSubList` doesn't override `indexOf` and `lastIndexOf`, so they will throw when given `null`, even though the list could contain `null`. Example code that I think will fail with the changes in this PR: var list = StableValue.list(42, x -> x == 23 ? null : x); IO.println(list.indexOf(null)); // 23 IO.println(list.subList(10, 30).indexOf(null)); // NPE, should be 13 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085512298 From iklam at openjdk.org Mon May 12 21:17:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 21:17:10 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: References: Message-ID: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam 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' into 8355798-implement-leyden-ergo-jep-8350022 - Update java man page - Use one-step training by default in AOT testing - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java - @vnkozlov comments - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS - Remove %t restriction - Added %p substitution; clean up - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04 Stats: 1893 lines in 22 files changed: 1387 ins; 456 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From naoto at openjdk.org Mon May 12 21:17:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 12 May 2025 21:17:53 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v3] In-Reply-To: References: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> Message-ID: On Sun, 11 May 2025 16:46:42 GMT, Alan Bateman wrote: > 1. FileDescriptor.in: Unfortunately FileInputStream(FileDescriptor) has no overload that supports custom charsets. We should probably document both on this FD and that constructor. The description of `FileDescriptor.in` reads: Usually, this file descriptor is not used directly, but rather via the input stream known as System.in And its `System.in` is hyperlinked. So I'd not add an example here. > 2. JShell.in and JavaShellToolBuilder.in (I assumed the first one as `JShell.Builder.in`) These are not fields but methods to set the InputStream, so I don't think this example exercise applies to either. `jdk.jshell` package info has a code sample which uses `System.console()` instead of reading from `System.in` which is good. > 3. A few usages in security, like password reading in sun.security.tools.keytool.Main, or javax.security.auth.callback.CallbackHandler The former are within `sun` package which is internal, so no need for examples. The latter has code sample in the class description. In there: new InputStreamReader(System.in) So this one indeed need to be updated. Will address it in the next iteration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2874120922 From iklam at openjdk.org Mon May 12 21:35:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 21:35:52 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam 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' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e Per suggestion by @katyapav , I've updated RunTests.gmk to use the new "one step training" when creating the AOT cache for running jtreg test cases. `twostep` is the old behavior. E.g.: make test JTREG=AOT_JDK=onestep TEST=open/test/hotspot/jtreg/runtime/invokedynamic make test JTREG=AOT_JDK=twostep TEST=open/test/hotspot/jtreg/runtime/invokedynamic Also, for the existing CDS jtreg tests that use CDSAppTester, the default testing mode is to use "one step training" for creating the AOT cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2874205674 From erikj at openjdk.org Mon May 12 21:43:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 May 2025 21:43:53 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: <8FryhUnn09RpstrSVIOwKLTPBwgh3HzS50dY2cMct5w=.b9e0840e-e585-4178-bd41-f19db4a6a016@github.com> On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam 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' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e This change in functionality for the `JTREG=AOT_JDK` makefile argument should probably be mentioned somewhere in `doc/testing.md`. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834697107 From duke at openjdk.org Mon May 12 21:46:06 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 12 May 2025 21:46:06 GMT Subject: RFR: 8077587: BigInteger Roots [v9] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Removed useless code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/3e3d45c4..08e94a79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From bpb at openjdk.org Mon May 12 21:58:18 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 May 2025 21:58:18 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v17] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/java/io/Reader.java 8354724: Apply suggested changes for readAllLines. Co-authored-by: Roger Riggs - Update src/java.base/share/classes/java/io/Reader.java 8354724: Apply suggested changes for readAllAsString. Co-authored-by: Roger Riggs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/983aeb50..a4cf9224 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=15-16 Stats: 22 lines in 1 file changed: 9 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From naoto at openjdk.org Mon May 12 21:59:29 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 12 May 2025 21:59:29 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v4] In-Reply-To: References: Message-ID: > With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects more comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25155/files - new: https://git.openjdk.org/jdk/pull/25155/files/6f8101cf..9621320c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=02-03 Stats: 16 lines in 3 files changed: 8 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155 PR: https://git.openjdk.org/jdk/pull/25155 From naoto at openjdk.org Mon May 12 21:59:30 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 12 May 2025 21:59:30 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v3] In-Reply-To: References: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com> Message-ID: On Mon, 12 May 2025 07:21:49 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects another review comment > > src/java.base/share/classes/java/io/InputStreamReader.java line 54: > >> 52: * } >> 53: * This example also demonstrates how to wrap {@link System#in} with {@link >> 54: * System##stdin.encoding stdin.encoding}. > > This example communicates two concerns, one is buffering, the other is the charset to use when running from System.in. I think we should separate these two, maybe with two examples? Made it two examples. > src/java.base/share/classes/java/util/Scanner.java line 82: > >> 80: * >> 81: *

      This code reads lines from {@link System#in} with {@link >> 82: * System##stdin.encoding stdin.encoding}: > > "from System.in with stdin.encoding" isn't very clear. I think you we can expand the sentence, or make it two sentences, so to that is uses a Scanner to read lines from System.in, and uses the value of stdin.encoding as the charset. Made it two sentences. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085595822 PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085595798 From swen at openjdk.org Mon May 12 22:50:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 12 May 2025 22:50:52 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 18:33:03 GMT, Roger Riggs wrote: >>> This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is. >> >> The core library also uses Unsafe.copyMemory in many places. Can it be used in this scenario? Or can we find other ways to copy char[] to byte[]? > > You may have overlooked the behavior of putChar to swap the order of the bytes depending on whether its big or little endian. There is no endianness issue here. The byte[] of StringUTF16 has the same endianness order in memory as char[]. The Unsafe::CopyMemory operation here is the same as the Unsafe::putChar and StringUTF16::putChar operation on StringUTF16 byte[], so there is no endianness issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2085638167 From duke at openjdk.org Mon May 12 23:14:10 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 12 May 2025 23:14:10 GMT Subject: RFR: 8077587: BigInteger Roots [v10] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch - correct and optimize the final loop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/08e94a79..8f55229f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=08-09 Stats: 15 lines in 1 file changed: 9 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From liach at openjdk.org Mon May 12 23:23:57 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 12 May 2025 23:23:57 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects more comments Do we need a CSR for this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2874442044 From epavlova at openjdk.org Mon May 12 23:24:04 2025 From: epavlova at openjdk.org (Ekaterina Pavlova) Date: Mon, 12 May 2025 23:24:04 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam 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' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e make/RunTests.gmk changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834836628 From jlu at openjdk.org Mon May 12 23:26:55 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 May 2025 23:26:55 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() [v2] In-Reply-To: References: Message-ID: On Sun, 11 May 2025 08:42:41 GMT, Abhishek N wrote: >> Create a Test case to have special cases coverage for currency.getInstance(). >> >> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API. >> >> test results: >> >> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java >> Directory "JTwork" not found: creating >> Directory "JTreport" not found: creating >> Test results: passed: 1 >> Report written to JTreport\html\report.html >> Results written to JTwork > > Abhishek N has updated the pull request incrementally with one additional commit since the last revision: > > correcting jtreg header order, add meaningful comments for each test methods and properties file Hi @abhn-git, I think it would be beneficial if we first addressed the concerns raised before continuing work on this PR. [JDK-8355393](https://bugs.openjdk.org/browse/JDK-8355393) assigned to you and [JDK-8355045](https://bugs.openjdk.org/browse/JDK-8355045) assigned to @weibxiao appear to be duplicates. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2874462568 From bpb at openjdk.org Mon May 12 23:51:19 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 May 2025 23:51:19 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: > Implement the requested methods and add a test thereof. Brian Burkhalter 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: - 8354724: Attempt to further improve verbiage - Merge - Update src/java.base/share/classes/java/io/Reader.java 8354724: Apply suggested changes for readAllLines. Co-authored-by: Roger Riggs - Update src/java.base/share/classes/java/io/Reader.java 8354724: Apply suggested changes for readAllAsString. Co-authored-by: Roger Riggs - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test - 8354724: Fix potential NPE in test - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test - 8354724: Improve test per reviewer comments - 8354724: Add missing toList(), tweak verbiage; update test - 8354724: Add Reader.readAllLines; test not yet updated - ... and 11 more: https://git.openjdk.org/jdk/compare/b1ab1054...1d811589 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/a4cf9224..1d811589 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=16-17 Stats: 94574 lines in 2581 files changed: 69278 ins; 15222 del; 10074 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From iklam at openjdk.org Tue May 13 00:01:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 00:01:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v6] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Allow one-step training even when -XX:AOTMode=auto is specified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/b044953e..f33d5994 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04-05 Stats: 81 lines in 3 files changed: 62 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From bpb at openjdk.org Tue May 13 00:03:51 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 May 2025 00:03:51 GMT Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v3] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 17:58:29 GMT, Brent Christian wrote: >> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. >> >> Automated test results are omitted as expected. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > apostrophize Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25163#pullrequestreview-2834957477 From serb at openjdk.org Tue May 13 00:13:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 13 May 2025 00:13:50 GMT Subject: RFR: 8356644: Update encoding declaration to UTF-8 In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> Message-ID: On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper. > > I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8. src/demo/share/jfc/CodePointIM/README.html line 5: > 3: > 4: README - CodePointIM > 5: I believe this line is equivalent to simple `` which is widely used in java.desktop's docs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2085710719 From darcy at openjdk.org Tue May 13 00:21:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 May 2025 00:21:51 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v4] In-Reply-To: References: Message-ID: <5faXt--bztWwFfeQ-eHeLK6BWuE4qYisWy6ctMeN-Zs=.721f2f24-6152-4081-8d93-05de39e22ac8@github.com> On Mon, 12 May 2025 23:21:15 GMT, Chen Liang wrote: > Do we need a CSR for this? No; from a quick look, I don't see a need for a CSR here as the semantics aren't being changed. HTH ------------- PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2874629944 From liach at openjdk.org Tue May 13 00:25:51 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 00:25:51 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects more comments Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2834978752 From almatvee at openjdk.org Tue May 13 00:35:08 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 May 2025 00:35:08 GMT Subject: RFR: 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Message-ID: `openssl` from macOS will ignore `faketime` and as result expired certificates will not be generated correctly. By default we should use these tools from Homebrew. ------------- Commit messages: - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Changes: https://git.openjdk.org/jdk/pull/25196/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356819 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25196/head:pull/25196 PR: https://git.openjdk.org/jdk/pull/25196 From smarks at openjdk.org Tue May 13 00:57:52 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 13 May 2025 00:57:52 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects more comments src/java.base/share/classes/java/lang/System.java line 129: > 127: * within the object that handles character encoding. After this is done, > 128: * subsequent reading should use only the wrapper object; operating directly > 129: * on {@code System.in} results in unspecified behavior. Sorry, I think I suggested this wording initially, but I now think it needs to be changed. I'd suggest changing the text after the semicolon to > continuing to operate directly on {@code System.in} results in unspecified behavior. src/java.base/share/classes/javax/security/auth/callback/CallbackHandler.java line 116: > 114: * System.err.flush(); > 115: * nc.setName((new BufferedReader > 116: * (new InputStreamReader(System.in, "stdin.encoding"))).readLine()); Needs to be `System.getProperty("stdin.encoding"))`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085741488 PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085739806 From smarks at openjdk.org Tue May 13 01:02:59 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 13 May 2025 01:02:59 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects more comments src/java.base/share/classes/java/util/Scanner.java line 89: > 87: * String aLine = sc.nextLine(); > 88: * } > 89: * } Now that I'm looking at the other examples, I have what I think is better example for using Scanner on System.in. Take this example and move it after the example below, which reads long values from the file `myNumbers`. The new example could do the same thing with the hasNextLong/nextLong loop. But instead it would read from System.in using the encoding specified by `stdin.encoding`. The example could explain that reading from files uses the default encoding (`file.encoding`) whereas reading from System.in should use `stdin.encoding` because on some systems this differs from the default encoding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085745213 From asemenyuk at openjdk.org Tue May 13 01:53:02 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 13 May 2025 01:53:02 GMT Subject: RFR: 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default In-Reply-To: References: Message-ID: On Tue, 13 May 2025 00:30:08 GMT, Alexander Matveev wrote: > `openssl` from macOS will ignore `faketime` and as result expired certificates will not be generated correctly. By default we should use these tools from Homebrew. Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25196#pullrequestreview-2835070598 From jpai at openjdk.org Tue May 13 02:11:03 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 02:11:03 GMT Subject: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 10:34:37 GMT, Markus KARG wrote: >> Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change? > > We could also simply include it in the PR for https://bugs.openjdk.org/browse/JDK-8356679 to reduce organizational overhead. Hello Markus, it's OK to do this text change as part of JDK-8356679. Like Roger noted in the corresponding core-libs-dev mailing list, it would be good to do the 8356679 changes in smaller pieces and include this change in one of those. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2085794320 From naoto at openjdk.org Tue May 13 02:31:42 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 May 2025 02:31:42 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v5] In-Reply-To: References: Message-ID: > With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting further comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25155/files - new: https://git.openjdk.org/jdk/pull/25155/files/9621320c..9af90274 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=03-04 Stats: 28 lines in 3 files changed: 15 ins; 10 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155 PR: https://git.openjdk.org/jdk/pull/25155 From naoto at openjdk.org Tue May 13 02:31:43 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 May 2025 02:31:43 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v4] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 00:55:14 GMT, Stuart Marks wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects more comments > > src/java.base/share/classes/java/lang/System.java line 129: > >> 127: * within the object that handles character encoding. After this is done, >> 128: * subsequent reading should use only the wrapper object; operating directly >> 129: * on {@code System.in} results in unspecified behavior. > > Sorry, I think I suggested this wording initially, but I now think it needs to be changed. I'd suggest changing the text after the semicolon to > >> continuing to operate directly on {@code System.in} results in unspecified behavior. Done. > src/java.base/share/classes/java/util/Scanner.java line 89: > >> 87: * String aLine = sc.nextLine(); >> 88: * } >> 89: * } > > Now that I'm looking at the other examples, I have what I think is better example for using Scanner on System.in. Take this example and move it after the example below, which reads long values from the file `myNumbers`. The new example could do the same thing with the hasNextLong/nextLong loop. But instead it would read from System.in using the encoding specified by `stdin.encoding`. The example could explain that reading from files uses the default encoding (`file.encoding`) whereas reading from System.in should use `stdin.encoding` because on some systems this differs from the default encoding. I added an extra sentence for the explanation. > src/java.base/share/classes/javax/security/auth/callback/CallbackHandler.java line 116: > >> 114: * System.err.flush(); >> 115: * nc.setName((new BufferedReader >> 116: * (new InputStreamReader(System.in, "stdin.encoding"))).readLine()); > > Needs to be `System.getProperty("stdin.encoding"))`. Good catch! Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085812565 PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085812615 PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085812480 From iklam at openjdk.org Tue May 13 03:06:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 03:06:44 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v7] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added param to makefile function SetupAOT for choosing onestep vs twostep ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/f33d5994..3cc2cb3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05-06 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From naoto at openjdk.org Tue May 13 03:15:25 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 May 2025 03:15:25 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: Message-ID: > With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed an erroneous curly brace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25155/files - new: https://git.openjdk.org/jdk/pull/25155/files/9af90274..cfcae707 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155 PR: https://git.openjdk.org/jdk/pull/25155 From hchao at openjdk.org Tue May 13 03:58:53 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Tue, 13 May 2025 03:58:53 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3] In-Reply-To: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com> References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com> Message-ID: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com> On Mon, 12 May 2025 20:05:18 GMT, Artur Barashev wrote: >> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: >> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 >> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3 >> >> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Make sure the exception happens during KeyManager's algorithm check It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. When setting this property to true, it will disable the existing RFC compliant algorithm constraints checking even in `X509KeyManagerImpl`, and we?d want to avoid that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2874984309 From darcy at openjdk.org Tue May 13 04:02:04 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 May 2025 04:02:04 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v10] In-Reply-To: <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com> References: <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com> Message-ID: On Sat, 10 May 2025 10:08:39 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Addressed reviewer comments. Marked as reviewed by darcy (Reviewer). src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1878: > 1876: > 1877: /* > 1878: * In some places the idiom Might be easier to read the code if this logic were refactored into a method. ------------- PR Review: https://git.openjdk.org/jdk/pull/22737#pullrequestreview-2835206552 PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2085876226 From duke at openjdk.org Tue May 13 04:06:34 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Tue, 13 May 2025 04:06:34 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v2] In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: > 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Update TestDockerMemoryMetricsSubgroup.java remove extra space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24930/files - new: https://git.openjdk.org/jdk/pull/24930/files/1b131d86..ad855247 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24930/head:pull/24930 PR: https://git.openjdk.org/jdk/pull/24930 From darcy at openjdk.org Tue May 13 04:07:52 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 May 2025 04:07:52 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) In-Reply-To: References: Message-ID: On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham wrote: > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 141: > 139: /** > 140: * Value scale, such that > 141: * value = (f × 10-scale) Raw javadoc nit: wherever possible, please use `{@code foo}` rather than `foo`. I find the former much easier to read and it is fewer characters too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2085880551 From smarks at openjdk.org Tue May 13 04:53:57 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 13 May 2025 04:53:57 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed an erroneous curly brace Thanks for the updates! Looks good. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2835259395 From darcy at openjdk.org Tue May 13 05:06:54 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 May 2025 05:06:54 GMT Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 15:13:19 GMT, Raffaello Giulietti wrote: >> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. >> Further, add `unsignedMultiplyExact` methods as well. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Added tests. Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25003#pullrequestreview-2835276748 From pminborg at openjdk.org Tue May 13 05:49:59 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 May 2025 05:49:59 GMT Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v6] In-Reply-To: References: Message-ID: <5WpfLr2AvhUjY8uD3QfVNo46T0Jew2PfpUm9cHjiC3k=.8423e3d7-186f-41a3-bed4-7773f87fd090@github.com> On Mon, 12 May 2025 14:41:27 GMT, Per Minborg wrote: >> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. >> >> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove delimiter between JBS issues Test run in tier5 passes now. Thanks for the reviews and suggestions for improvement here! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2875116994 From pminborg at openjdk.org Tue May 13 05:49:59 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 May 2025 05:49:59 GMT Subject: Integrated: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out In-Reply-To: References: Message-ID: On Mon, 12 May 2025 08:57:59 GMT, Per Minborg wrote: > This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly. > > Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal. This pull request has now been integrated. Changeset: 6e084691 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/6e0846918ce1286ea1571a6ec0de8e6b44e24218 Stats: 19 lines in 1 file changed: 8 ins; 4 del; 7 mod 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25177 From alanb at openjdk.org Tue May 13 06:14:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 06:14:51 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 20:19:43 GMT, David Beaumont wrote: >> src/jdk.zipfs/share/classes/module-info.java line 160: >> >>> 158: * will always be opened read-write (see {@code "accessMode"} >>> 159: * below), regardless of whether the underlying ZIP already existed or >>> 160: * not. >> >> In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist. >> >> For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system. > > Is this comment just agreeing with the proposed behaviour stated here? > > At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests). > > The only allowed access mode options with "create" are "readWrite" or , and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured. I agree that read-only && create is a combination to be rejected. My comment is about the update to the description of the "create" option. It's the first row in the table and the changes suggests that it is forcing the file system to be read-write. I think the wording for the "readOnly" option is sufficient, meaning just one place to document the conflict between these two options. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085993836 From pminborg at openjdk.org Tue May 13 06:25:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 May 2025 06:25:03 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v3] In-Reply-To: References: Message-ID: <7Q5c-KaZ4iDbK_Byf57NABfWRZUMNy-KIpNwYF9910g=.88424cfa-c849-4a1f-aef8-ce37fafa25a1@github.com> On Mon, 12 May 2025 21:12:36 GMT, Luca Kellermann wrote: >> src/java.base/share/classes/java/util/ImmutableCollections.java line 518: >> >>> 516: >>> 517: private boolean allowNulls() { >>> 518: return root instanceof ListN listN && listN.allowNulls; >> >> I think this should stay here (or some other change is needed). `StableSubList` doesn't override `indexOf` and `lastIndexOf`, so they will throw when given `null`, even though the list could contain `null`. > > Example code that I think will fail with the changes in this PR: > > var list = StableValue.list(42, x -> x == 23 ? null : x); > IO.println(list.indexOf(null)); // 23 > IO.println(list.subList(10, 30).indexOf(null)); // NPE, should be 13 Good catch. I will add a test that will test all list view combinations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2086007633 From pminborg at openjdk.org Tue May 13 07:31:58 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 May 2025 07:31:58 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v3] In-Reply-To: References: Message-ID: <06AUoZOUqKnr59GqEmJeVU8X38OXrOJq6c4Oh18-KY8=.275c08eb-8778-41b5-bc03-390d74e91883@github.com> On Mon, 12 May 2025 07:42:16 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits: > > - Address comments > - Merge branch 'master' into jep502-followup > - Fix an issue with toString on nested constructs > - Merge branch 'master' into jep502-followup > - Merge branch 'master' into jep502-followup > - Update src/java.base/share/classes/java/lang/StableValue.java > > Co-authored-by: Chen Liang > - Simplify furhter > - Address comments in PR > - Merge master > - Remove unused method and add comment > - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336 > I noticed that this code will throw `NoSuchElementException` instead of `IndexOutOfBoundsException` and will swallow the message because of the `try`/`catch` in `ImmutableCollections.ListItr.next`/`previous`: > > ```java > StableValue > .list(42, _ -> {throw new IndexOutOfBoundsException("important message");}) > .listIterator(5) > .next(); // same for previous() > ``` We will take a look at this under a separate issue: https://bugs.openjdk.org/browse/JDK-8356842 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2875362328 From pminborg at openjdk.org Tue May 13 07:57:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 May 2025 07:57:15 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v4] In-Reply-To: References: Message-ID: > This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. > > Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. > > Unfortunately, this PR shows the total commit history for stable values. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25004/files - new: https://git.openjdk.org/jdk/pull/25004/files/a2826336..cebd1c0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=02-03 Stats: 83 lines in 6 files changed: 71 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004 PR: https://git.openjdk.org/jdk/pull/25004 From alanb at openjdk.org Tue May 13 08:34:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 08:34:52 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed an erroneous curly brace Good. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2835788543 From alanb at openjdk.org Tue May 13 08:46:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 08:46:05 GMT Subject: Integrated: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 15:47:55 GMT, Alan Bateman wrote: > Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically: > > - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. > - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. > - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. > - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. > - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. > > The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. This pull request has now been integrated. Changeset: 132a890a Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/132a890a9b3b70f2358237ebd9242b6747ba03dd Stats: 4036 lines in 14 files changed: 1818 ins; 1438 del; 780 mod 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) Co-authored-by: Alan Bateman Co-authored-by: Viktor Klang Reviewed-by: vklang ------------- PR: https://git.openjdk.org/jdk/pull/21934 From markus at headcrashing.eu Tue May 13 09:05:59 2025 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 13 May 2025 11:05:59 +0200 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> Message-ID: Thank you, Roger. Actually the method helps in the "toString()" variants, too, as in some places we could *get rid* of "toString()" (which is more work than "just" a buffer due to the added compression complexity). In fact, I already took the time to rewrite *all* of them while waiting for the approval of this list posting. In *all* cases *less* buffering / copying is needed, and *less* "toString()" conversion (which is a copy under the hood) is needed. So if I would be allowed to show the code as a PR, it would be much easier to explain and discuss. A PR is the best place to discuss "how to code would change". In the worst case, let's drop it if we see that it is actually a bad thing. -Markus Am 12.05.2025 um 20:18 schrieb Roger Riggs: > Hi Markus, > > On the surface, its looks constructive. > I suspect that many of these cases will turn into discussions about > the right/best/better way to buffer the characters. > The getChars method only helps when extracting to a char array, many > of the current implementations create strings as the intermediary. The > advantage of the 1 character at a time technique is not needing a > (separated allocated) buffer. > Consider taking a few at a time before launching into the whole set. > > $.02, Roger > > On 5/11/25 2:45 AM, Markus KARG wrote: >> Dear Core Libs Team, >> >> I am hereby requesting comments on JDK-8356679. >> >> I would like to invest some time and set up a PR implementing Chen >> Liangs's proposal laid out in >> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, >> the text of that JBS is copied below. According to the Developer's >> Guide I do need to get broad agreement BEFORE filing a PR. Therefore, >> I kindly ask everybody to briefly show consent, so I may file a PR. >> >> Thanks >> -Markus >> >> >> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >> >> Recently OpenJDK adopted the new method CharSequence::getChars(int, >> int, char[], int) for inclusion in Java 25. As a bulk reader method, >> it allows potentially improved efficiency over the previously >> available char-by-char reader method CharSequence::charAt(int). >> >> Chen Liang suggested on March 23rd on the core-lib-dev mailing list >> to use the new method within the internal source code of OpenJDK for >> the implementation of Appendables (see >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >> The idea behind this is that the implementations might be more >> efficient then. >> >> A quick analysis of the OpenJDK source code identified (at least) the >> following classes which could potentially run more efficient when >> using CharSequence::getChars internally, thanks to bulk reading and / >> or prevention of internal copies / toString() conversions: >> * java.io.Writer >> * java.io.StringWriter >> * java.io.PrintWriter >> * java.io.BufferedWriter >> * java.io.CharArrayWriter >> * java.io.FileWriter >> * java.io.OutputStreamWriter >> * sun.nio.cs.StreamEncoder >> * java.io.PrintStream >> * java.nio.CharBuffer >> >> In the sense of "eat your own dog food", it makes sense to implement >> Chen's idea in (at least) those classes. Possibly more classes could >> get identified when taking a deeper look. Besides the potential >> efficiency improvements, it would be a good show case for the usage >> of the new API. >> >> The risk of this change should be low, as test coverage exists, and >> as the intended changes are solely internal to the implementation. No >> API will get changed. In some cases the JavaDocs will get slightly >> adapted where it currently exposes the actual implementation (to not >> lie in future). >> > From abimpoudis at openjdk.org Tue May 13 09:16:53 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 13 May 2025 09:16:53 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: References: Message-ID: On Mon, 12 May 2025 09:16:30 GMT, Maurizio Cimadamore wrote: >> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. >> >> For example this is not valid Java (and protected) by javac: >> >> >> byte b = 1; >> switch (b) { >> case String s -> System.out.println("How did we get here? byte is " + s.getClass()); >> } >> >> >> but this is a valid call (and not protected): >> >> >> CallSite shortSwitch = SwitchBootstraps.typeSwitch( >> MethodHandles.lookup(), >> "", >> MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int >> String.class); >> >> >> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. >> >> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 725: > >> 723: >> 724: private static boolean isNotValidPair(Class selectorType, Object caseLabel) { >> 725: return (selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class) || > > What happens if `caseLabel` is a reference class? E.g. a `boolean` selector is incompatible with `String`. `(selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class)` -> true so it is not a valid pair. Do you think it is wrong? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086329296 From shade at openjdk.org Tue May 13 09:16:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 May 2025 09:16:56 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: On Tue, 6 May 2025 10:51:14 GMT, Thomas Stuefe wrote: >> 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 six additional commits since the last revision: >> >> - Add bug ID >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Pull message into a field >> - Test cases >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Initial fix >> >> Good spawnhelper failure message >> >> Trying tests >> >> Print helper message on all IOExceptions >> >> Final > > src/java.base/unix/native/libjava/ProcessImpl_md.c line 377: > >> 375: throwIOExceptionImpl(env, errnum, defaultDetail, ""); >> 376: } >> 377: } > > Why only for POSIX_SPAWN? We use jspawnhelper also for fork/vfork+exec. Er? This is news to me. Where do you see this? I see we only pass the `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode: static pid_t startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) { switch (c->mode) { /* vfork(2) is deprecated on Darwin*/ #ifndef __APPLE__ case MODE_VFORK: return vforkChild(c); #endif case MODE_FORK: return forkChild(c); case MODE_POSIX_SPAWN: return spawnChild(env, process, c, helperpath); default: return -1; } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086328349 From abimpoudis at openjdk.org Tue May 13 09:16:54 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 13 May 2025 09:16:54 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: References: Message-ID: On Sun, 11 May 2025 21:45:46 GMT, Luca Kellermann wrote: >> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. >> >> For example this is not valid Java (and protected) by javac: >> >> >> byte b = 1; >> switch (b) { >> case String s -> System.out.println("How did we get here? byte is " + s.getClass()); >> } >> >> >> but this is a valid call (and not protected): >> >> >> CallSite shortSwitch = SwitchBootstraps.typeSwitch( >> MethodHandles.lookup(), >> "", >> MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int >> String.class); >> >> >> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. >> >> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 782: > >> 780: else if (selectorType.equals(targetType) || >> 781: (targetType.isPrimitive() && selectorType.isPrimitive() && >> 782: ((selectorType.equals(byte.class) && !targetType.equals(char.class)) || > > Will `unconditionalExactnessMatch(byte.class, boolean.class` return `true`? I think it shouldn't, even if `isNotValidPair` is called before. `unconditionalExactnessMatch` needs to return an answer whether a pair is unconditional assuming it is applicable. Fusing them would need to elaborate the type of the returned answer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086329089 From shade at openjdk.org Tue May 13 09:23:10 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 May 2025 09:23:10 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: <2_ZJ4felyiQJG0af-znFqWwU0DPFohr6hN7duZn7Rqs=.37dfe269-aad6-429c-a068-8576a0e84977@github.com> On Tue, 6 May 2025 10:56:54 GMT, Thomas Stuefe wrote: >> 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 six additional commits since the last revision: >> >> - Add bug ID >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Pull message into a field >> - Test cases >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Initial fix >> >> Good spawnhelper failure message >> >> Trying tests >> >> Print helper message on all IOExceptions >> >> Final > > src/java.base/unix/native/libjava/ProcessImpl_md.c line 348: > >> 346: } >> 347: /* ASCII Decimal representation uses 2.4 times as many bits as binary. */ >> 348: fmtsize = sizeof(IOE_FORMAT) + strlen(internalErrorDetail) + strlen(detail) + 3 * sizeof(errnum); > > Suggestion: > > fmtsize = sizeof(IOE_FORMAT) + 3 * sizeof(errnum) + strlen(detail) + strlen(internalErrorDetail) + 1; > > ... just to appease my OCD. Right. Will be done in new commit. > src/java.base/unix/native/libjava/ProcessImpl_md.c line 351: > >> 349: errmsg = NEW(char, fmtsize); >> 350: if (errmsg == NULL) >> 351: return; > > Preexisting: seems to be weird to just quietly swallow the allocation error. Yes. I am guessing the allocation error here means we are likely unable to allocate the `IOException` later on. History shows this check was added by JDK-8008118 -- and it looks only to please the static analysis tools. So I left this unchanged. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086340557 PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086340234 From abimpoudis at openjdk.org Tue May 13 09:25:11 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 13 May 2025 09:25:11 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler [v2] In-Reply-To: References: Message-ID: > While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. > > For example this is not valid Java (and protected) by javac: > > > byte b = 1; > switch (b) { > case String s -> System.out.println("How did we get here? byte is " + s.getClass()); > } > > > but this is a valid call (and not protected): > > > CallSite shortSwitch = SwitchBootstraps.typeSwitch( > MethodHandles.lookup(), > "", > MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int > String.class); > > > The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. > > This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Add test for boolean selector and String case label ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25090/files - new: https://git.openjdk.org/jdk/pull/25090/files/835fb6ab..7b030bee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25090.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25090/head:pull/25090 PR: https://git.openjdk.org/jdk/pull/25090 From abimpoudis at openjdk.org Tue May 13 09:25:12 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 13 May 2025 09:25:12 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler [v2] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 09:14:28 GMT, Aggelos Biboudis wrote: >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 725: >> >>> 723: >>> 724: private static boolean isNotValidPair(Class selectorType, Object caseLabel) { >>> 725: return (selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class) || >> >> What happens if `caseLabel` is a reference class? E.g. a `boolean` selector is incompatible with `String`. > > `(selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class)` -> true so it is not a valid pair. Do you think it is wrong? e.g., https://github.com/openjdk/jdk/pull/25090/commits/7b030bee3e23206c030970f6c24be3bcb5241361 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086343743 From abimpoudis at openjdk.org Tue May 13 09:56:31 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 13 May 2025 09:56:31 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler [v3] In-Reply-To: References: Message-ID: > While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. > > For example this is not valid Java (and protected) by javac: > > > byte b = 1; > switch (b) { > case String s -> System.out.println("How did we get here? byte is " + s.getClass()); > } > > > but this is a valid call (and not protected): > > > CallSite shortSwitch = SwitchBootstraps.typeSwitch( > MethodHandles.lookup(), > "", > MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int > String.class); > > > The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. > > This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Simplify unconditional exactness in both Types and SwitchBootstraps ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25090/files - new: https://git.openjdk.org/jdk/pull/25090/files/7b030bee..a7c4e398 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=01-02 Stats: 15 lines in 2 files changed: 0 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25090.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25090/head:pull/25090 PR: https://git.openjdk.org/jdk/pull/25090 From abimpoudis at openjdk.org Tue May 13 09:58:52 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 13 May 2025 09:58:52 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler [v3] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 09:15:56 GMT, Maurizio Cimadamore wrote: >> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify unconditional exactness in both Types and SwitchBootstraps > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 786: > >> 784: (selectorType.equals(char.class) && (selectorWrapper.isStrictSubRangeOf(targetWrapper))) || >> 785: (selectorType.equals(int.class) && (targetType.equals(double.class) || targetType.equals(long.class))) || >> 786: (selectorType.equals(float.class) && (selectorWrapper.isStrictSubRangeOf(targetWrapper)))))) return true; > > Is `double` the only allowed target for `float` ? If so, perhaps we could simplify like for other selector types. > Or, alternatively, I wonder if it wouldn't be simpler to _always_ check for strict subrange on the wrappers, but then ban the conversions that are not exact (e.g. int -> float), as those are few? Thanks @mcimadamore. I gave it a shot, despite the fact that it touches the mirrored code in Types because it is a good recommendation. But please take a look again since it is a very central part: https://github.com/openjdk/jdk/pull/25090/commits/a7c4e398f2a163083853a2a6e58a97d6a06d592f ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086413064 From shade at openjdk.org Tue May 13 10:30:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 May 2025 10:30:14 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v5] In-Reply-To: References: Message-ID: > When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. > > It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. > > I am very open to bike-shedding about the actual message :) > > Additional testing: > - [x] Ad-hoc experiments with breaking jspawnhelper > - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` 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 nine additional commits since the last revision: - Print error decoding - Touch up formatting message - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions - Add bug ID - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions - Pull message into a field - Test cases - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions - Initial fix Good spawnhelper failure message Trying tests Print helper message on all IOExceptions Final ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24149/files - new: https://git.openjdk.org/jdk/pull/24149/files/74ddf9af..254f7f88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24149&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24149&range=03-04 Stats: 38080 lines in 1284 files changed: 25679 ins; 7079 del; 5322 mod Patch: https://git.openjdk.org/jdk/pull/24149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24149/head:pull/24149 PR: https://git.openjdk.org/jdk/pull/24149 From shade at openjdk.org Tue May 13 10:30:17 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 May 2025 10:30:17 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: On Tue, 6 May 2025 11:23:32 GMT, Thomas Stuefe wrote: >> 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 six additional commits since the last revision: >> >> - Add bug ID >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Pull message into a field >> - Test cases >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Initial fix >> >> Good spawnhelper failure message >> >> Trying tests >> >> Print helper message on all IOExceptions >> >> Final > > src/java.base/unix/native/libjava/ProcessImpl_md.c line 346: > >> 344: if (ret != EINVAL) >> 345: detail = tmpbuf; >> 346: } > > Pre-existing, possibly as follow-up: > > I wonder whether we can do more. I don't like how we either only print out the errno string, or only print out the "Default" detail (I don't like the "default" prefix since it's really useful context information about this errno). > > For a problem on this side, we mostly pass in errno, then swallow the "defaultdetail". E.g. for posix_spawn failure, we'd print e.g. "12:Out of memory\nPossible reasons: ... " (or whatever localized string strerror returns). > > For errors that happen inside the jspawnhelper (see line 790ff where we pass 0 for the errno), we print out "0:Bad code from spawn helper\nPossible reasons: ... ", so we swallow the errno we got from the jspawnhelper. > > Could we print out instead the default, then the errno string, then the Possible reasons text? E.g. > "posix_spawn failed (12:Out of memory)\nPossible reasons: ..." > or > "Bad code from spawn helper (12:Out of memory)\nPossible reasons: ..." > > There is an issue of errnum values from the far side possibly intersecting with valid errno. Could be solved simply by assigning negative values to ERR_MALLOC, ERR_PIPE and ERR_ARGS. I am not aware of any errno values being negative. The errno printing would need to recognise these three values in addition to errno values. We also could remove the +3 workaround in the test. > > The only argument I see against is some vague form of backward compatibility, in case people get confused about the new information, or that existing tools parse this output. Yeah, I dislike `defaultDetail` naming and the fact we swallow it. I see good reason to print it unconditionally. I think we can do this with just a little code massaging. See new commit. It prints the message like: Recursively executing 'JspawnhelperProtocol simulateCrashInChild4' posix_spawn:0 java.io.IOException: Cannot run program "pwd": Failed to exec spawn helper: pid: 1405770, exit code: 4, error: 0 (none) Possible reasons: - Spawn helper ran into JDK version mismatch - Spawn helper ran into unexpected internal error - Spawn helper was terminated by another process Possible solutions: - Restart JVM, especially after in-place JDK updates - Check system logs for JDK-related errors - Re-install JDK to fix permission/versioning problems - Switch to legacy launch mechanism with -Djdk.lang.Process.launchMechanism=VFORK at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1044) at java.base/java.lang.Runtime.exec(Runtime.java:605) at java.base/java.lang.Runtime.exec(Runtime.java:470) at JspawnhelperProtocol.parentCode(JspawnhelperProtocol.java:58) at JspawnhelperProtocol.main(JspawnhelperProtocol.java:232) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086480179 From duke at openjdk.org Tue May 13 10:33:33 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 10:33:33 GMT Subject: RFR: 8077587: BigInteger Roots [v11] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Avoid needless box/unbox conversion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/8f55229f..3d8562f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From alanb at openjdk.org Tue May 13 10:59:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 10:59:05 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Mon, 12 May 2025 23:51:19 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter 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: > > - 8354724: Attempt to further improve verbiage > - Merge > - Update src/java.base/share/classes/java/io/Reader.java > > 8354724: Apply suggested changes for readAllLines. > > Co-authored-by: Roger Riggs > - Update src/java.base/share/classes/java/io/Reader.java > > 8354724: Apply suggested changes for readAllAsString. > > Co-authored-by: Roger Riggs > - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test > - 8354724: Fix potential NPE in test > - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test > - 8354724: Improve test per reviewer comments > - 8354724: Add missing toList(), tweak verbiage; update test > - 8354724: Add Reader.readAllLines; test not yet updated > - ... and 11 more: https://git.openjdk.org/jdk/compare/fa3173d5...1d811589 src/java.base/share/classes/java/io/Reader.java line 430: > 428: *

      The behavior for the case where the reader is > 429: * asynchronously closed, or the thread interrupted during the > 430: * read, is highly input stream specific, and therefore not specified. The carry over of this paragraph needs to replace "input stream" with reader (same thing in the other method). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2086530955 From alanb at openjdk.org Tue May 13 11:10:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 11:10:59 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Mon, 12 May 2025 23:51:19 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter 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: > > - 8354724: Attempt to further improve verbiage > - Merge > - Update src/java.base/share/classes/java/io/Reader.java > > 8354724: Apply suggested changes for readAllLines. > > Co-authored-by: Roger Riggs > - Update src/java.base/share/classes/java/io/Reader.java > > 8354724: Apply suggested changes for readAllAsString. > > Co-authored-by: Roger Riggs > - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test > - 8354724: Fix potential NPE in test > - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test > - 8354724: Improve test per reviewer comments > - 8354724: Add missing toList(), tweak verbiage; update test > - 8354724: Add Reader.readAllLines; test not yet updated > - ... and 11 more: https://git.openjdk.org/jdk/compare/fea75845...1d811589 A lot of iterations and changes in direction but I think the API proposal in 1d811589 is okay. The method names and API docs looks fine. One thing that is missing is specifying how the 2 methods behaves when the reader is closed. Sadly, we can't do this because the base methods doesn't specify this so it becomes Reader specific. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2876052846 From rgiulietti at openjdk.org Tue May 13 11:26:53 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 13 May 2025 11:26:53 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v10] In-Reply-To: References: <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com> Message-ID: <4LHUOWN7xir23Jm2Cc356LRCZUh227lQU4HttoJtbVw=.17eb22b5-d759-4be8-bc0d-981fe75f8396@github.com> On Tue, 13 May 2025 03:58:44 GMT, Joe Darcy wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed reviewer comments. > > src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1878: > >> 1876: >> 1877: /* >> 1878: * In some places the idiom > > Might be easier to read the code if this logic were refactored into a method. Right. I'll take this note into account in the next phase of the cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2086586796 From vyazici at openjdk.org Tue May 13 11:41:54 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 13 May 2025 11:41:54 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: Message-ID: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com> On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed an erroneous curly brace src/java.base/share/classes/java/io/InputStreamReader.java line 59: > 57: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); > 58: * } > 59: * There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2086612688 From jpai at openjdk.org Tue May 13 11:54:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 11:54:54 GMT Subject: RFR: 8350765: Need to pin when accessing thread container from virtual thread [v2] In-Reply-To: References: Message-ID: <4gAZ3IXpfztVsnHnnwWt9uApLl3OGqt5fp2FpaeuSnk=.ee029f80-79b0-423c-bca1-133570a31bb0@github.com> On Mon, 12 May 2025 14:01:16 GMT, Alan Bateman wrote: >> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code. Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues. >> >> Testing tier1-5, quick statup/footprint, noreg-hard > > 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 10 additional commits since the last revision: > > - Fix/improve comment > - Merge branch 'master' into JDK-8350765 > - Merge branch 'master' into JDK-8350765 > - No need to used qualified name > - Merge branch 'master' into JDK-8350765 > - Update > - Merge branch 'master' into JDK-8350765 > - Add method to ContinuationSupport > - Missing / > - Initial commit Thank you for the update Alan. The change looks reasonable to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23810#pullrequestreview-2836451768 From liach at openjdk.org Tue May 13 12:32:04 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 12:32:04 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v4] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 07:57:15 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments The latest change set looks fine. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2836572592 From jpai at openjdk.org Tue May 13 12:35:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 12:35:58 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 147: > 145: // this could exist somewhere common, but if it's definitely never going to > 146: // be shared, it could be made public here. > 147: private enum AccessMode { Hello David, I think having it `private` is fine and in fact more appropriate. I would suggest removing the comment though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086711632 From liach at openjdk.org Tue May 13 12:36:53 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 12:36:53 GMT Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if capacity has been reached In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 18:39:30 GMT, kabutz wrote: > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > Our suggestion is to make count volatile, and then exiting early from poll() and offer() @viktorklang-ora Is it possible for you to take a look at this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2876335323 From liach at openjdk.org Tue May 13 12:36:58 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 12:36:58 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com> References: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com> Message-ID: On Tue, 13 May 2025 11:39:16 GMT, Volkan Yazici wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed an erroneous curly brace > > src/java.base/share/classes/java/io/InputStreamReader.java line 59: > >> 57: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); >> 58: * } >> 59: * > > There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?) How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2086713392 From vklang at openjdk.org Tue May 13 12:46:57 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 May 2025 12:46:57 GMT Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if capacity has been reached In-Reply-To: References: Message-ID: On Tue, 13 May 2025 12:34:38 GMT, Chen Liang wrote: >> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. >> >> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. >> >> Our suggestion is to make count volatile, and then exiting early from poll() and offer() > > @viktorklang-ora Is it possible for you to take a look at this? @liach This PR should be closed, it's superseded by https://github.com/openjdk/jdk/pull/24925 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2876363296 From jpai at openjdk.org Tue May 13 12:46:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 12:46:59 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. src/jdk.zipfs/share/classes/module-info.java line 277: > 275: *

      ScriptNewOld
      > 276: * A value defining the desired read/write access mode of the file system > 277: * (either read-write or read-only). This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system. Perhaps we could reword this to something like: > > A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086732377 From vklang at openjdk.org Tue May 13 12:46:56 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 May 2025 12:46:56 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com> <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com> Message-ID: On Wed, 7 May 2025 17:01:29 GMT, kabutz wrote: > > @kabutz I think @AlanBateman might be able to have a look as well. > > As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in _after_ JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense. > > That sound reasonable. When would this be? About a month or so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2876366432 From stuefe at openjdk.org Tue May 13 12:50:08 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 13 May 2025 12:50:08 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com> On Tue, 13 May 2025 09:13:58 GMT, Aleksey Shipilev wrote: >> src/java.base/unix/native/libjava/ProcessImpl_md.c line 377: >> >>> 375: throwIOExceptionImpl(env, errnum, defaultDetail, ""); >>> 376: } >>> 377: } >> >> Why only for POSIX_SPAWN? We use jspawnhelper also for fork/vfork+exec. > > Er? This is news to me. Where do you see this? I see we only pass the `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode: > > > static pid_t > startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) { > switch (c->mode) { > /* vfork(2) is deprecated on Darwin*/ > #ifndef __APPLE__ > case MODE_VFORK: > return vforkChild(c); > #endif > case MODE_FORK: > return forkChild(c); > case MODE_POSIX_SPAWN: > return spawnChild(env, process, c, helperpath); > default: > return -1; > } > } You are right and I am confused. I always assumed that the primary function of jspawnhelper was to make vfork safe. Historically, that was the typical reason for an intermediate exec() to a helper - basically, you first exec() the helper as quickly as possible to get your own process memory. Then you do all the things you need to do in preparation for the final exec(), then exec again. I am surprised that this has worked with vfork() so flawlessly all this time. Maybe it didn't; maybe the libc's have all internally replaced vfork() with fork(), since fork() is fast enough nowadays. I actually don't understand why the jspawnhelper is even needed for posix_spawn, since all the things one does in jspawnhelper can be done also via posix_spawn process attributes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086739029 From stuefe at openjdk.org Tue May 13 12:56:54 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 13 May 2025 12:56:54 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v5] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote: >> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. >> >> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. >> >> I am very open to bike-shedding about the actual message :) >> >> Additional testing: >> - [x] Ad-hoc experiments with breaking jspawnhelper >> - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` > > 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 nine additional commits since the last revision: > > - Print error decoding > - Touch up formatting message > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Add bug ID > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Pull message into a field > - Test cases > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Initial fix > > Good spawnhelper failure message > > Trying tests > > Print helper message on all IOExceptions > > Final Looks good to me now. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2836654880 From stuefe at openjdk.org Tue May 13 12:56:56 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 13 May 2025 12:56:56 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: On Tue, 13 May 2025 10:26:51 GMT, Aleksey Shipilev wrote: >> src/java.base/unix/native/libjava/ProcessImpl_md.c line 346: >> >>> 344: if (ret != EINVAL) >>> 345: detail = tmpbuf; >>> 346: } >> >> Pre-existing, possibly as follow-up: >> >> I wonder whether we can do more. I don't like how we either only print out the errno string, or only print out the "Default" detail (I don't like the "default" prefix since it's really useful context information about this errno). >> >> For a problem on this side, we mostly pass in errno, then swallow the "defaultdetail". E.g. for posix_spawn failure, we'd print e.g. "12:Out of memory\nPossible reasons: ... " (or whatever localized string strerror returns). >> >> For errors that happen inside the jspawnhelper (see line 790ff where we pass 0 for the errno), we print out "0:Bad code from spawn helper\nPossible reasons: ... ", so we swallow the errno we got from the jspawnhelper. >> >> Could we print out instead the default, then the errno string, then the Possible reasons text? E.g. >> "posix_spawn failed (12:Out of memory)\nPossible reasons: ..." >> or >> "Bad code from spawn helper (12:Out of memory)\nPossible reasons: ..." >> >> There is an issue of errnum values from the far side possibly intersecting with valid errno. Could be solved simply by assigning negative values to ERR_MALLOC, ERR_PIPE and ERR_ARGS. I am not aware of any errno values being negative. The errno printing would need to recognise these three values in addition to errno values. We also could remove the +3 workaround in the test. >> >> The only argument I see against is some vague form of backward compatibility, in case people get confused about the new information, or that existing tools parse this output. > > Yeah, I dislike `defaultDetail` naming and the fact we swallow it. I see good reason to print it unconditionally. I think we can do this with just a little code massaging. See new commit. It prints the message like: > > > Recursively executing 'JspawnhelperProtocol simulateCrashInChild4' > posix_spawn:0 > java.io.IOException: Cannot run program "pwd": Failed to exec spawn helper: pid: 1405770, exit code: 4, error: 0 (none) > Possible reasons: > - Spawn helper ran into JDK version mismatch > - Spawn helper ran into unexpected internal error > - Spawn helper was terminated by another process > Possible solutions: > - Restart JVM, especially after in-place JDK updates > - Check system logs for JDK-related errors > - Re-install JDK to fix permission/versioning problems > - Switch to legacy launch mechanism with -Djdk.lang.Process.launchMechanism=VFORK > > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1044) > at java.base/java.lang.Runtime.exec(Runtime.java:605) > at java.base/java.lang.Runtime.exec(Runtime.java:470) > at JspawnhelperProtocol.parentCode(JspawnhelperProtocol.java:58) > at JspawnhelperProtocol.main(JspawnhelperProtocol.java:232) I like this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086751118 From stuefe at openjdk.org Tue May 13 12:56:56 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 13 May 2025 12:56:56 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com> References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com> Message-ID: On Tue, 13 May 2025 12:47:39 GMT, Thomas Stuefe wrote: >> Er? This is news to me. Where do you see this? I see we only pass the `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode: >> >> >> static pid_t >> startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) { >> switch (c->mode) { >> /* vfork(2) is deprecated on Darwin*/ >> #ifndef __APPLE__ >> case MODE_VFORK: >> return vforkChild(c); >> #endif >> case MODE_FORK: >> return forkChild(c); >> case MODE_POSIX_SPAWN: >> return spawnChild(env, process, c, helperpath); >> default: >> return -1; >> } >> } > > You are right and I am confused. I always assumed that the primary function of jspawnhelper was to make vfork safe. Historically, that was the typical reason for an intermediate exec() to a helper - basically, you first exec() the helper as quickly as possible to get your own process memory. Then you do all the things you need to do in preparation for the final exec(), then exec again. > > I am surprised that this has worked with vfork() so flawlessly all this time. Maybe it didn't; maybe the libc's have all internally replaced vfork() with fork(), since fork() is fast enough nowadays. > > I actually don't understand why the jspawnhelper is even needed for posix_spawn, since all the things one does in jspawnhelper can be done also via posix_spawn process attributes. Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some implementations, vfork() is equivalent to fork()." AIX manpage says just "The vfork subroutine is supported as a compatibility interface for older Berkeley Software Distribution (BSD) system programs" which sounds to me its just an alias for fork(). MacOS has no vfork anymore. So maybe Solaris was the last platform with a true vfork. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086748837 From duke at openjdk.org Tue May 13 12:59:58 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 12:59:58 GMT Subject: RFR: 8354138: LinkedBlockingDeque allows us to exceed size with addAll() In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 06:24:30 GMT, kabutz wrote: > In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceeded the capacity with "if (count + n <= capacity)". However, if we pass in a collection that has more than Integer.MAX_VALUE items in it, then we can overflow n, making it negative. Since "count + n" is also negative, we can add the chain to our last item, and thus we end up with a LinkedBlockingDeque with more than Integer.MAX_VALUE of items and a negative size(). stream().count() gives the correct number of items. > > This happens both via the bulk add constructor LinkedBlockingDeque(Collection) and when we call addAll(Collection) directly. > > In Java 8, they didn't have the clever addAll() method, and thus it failed immediately. > > Here is some test code: > > > import java.util.*; > import java.util.concurrent.*; > > // To see the issue, run with at least 90 GB of memory: > // -XX:+UnlockExperimentalVMOptions -Xmx90g -Xms90g -XX:+UseEpsilonGC -verbose:gc > // To verify the fix, run with at least 200 GB of memory: > // -XX:+UnlockExperimentalVMOptions -Xmx200g -Xms200g -XX:+UseEpsilonGC -verbose:gc > // To try on older versions of Java that don't have the EpsilonGC, you can use: > // -XX:+UseG1GC -verbose:gc -Xmx91g -Xms91g -XX:NewSize=89g > public class NegativeSizedLinkedBlockingDeque { > public static void main(String... args) { > HUUUGECollection list = new HUUUGECollection(Integer.MAX_VALUE + 1L); > LinkedBlockingDeque lbd = new LinkedBlockingDeque<>(10); > lbd.addAll(list); > System.out.println("lbd.size() = " + lbd.size()); > System.out.println(lbd.stream().count()); > } > > public static class HUUUGECollection extends AbstractCollection { > private final long size; > > public HUUUGECollection(long size) { > this.size = size; > } > > @Override > public int size() { > return size < Integer.MAX_VALUE ? (int) size : Integer.MAX_VALUE; > } > > @Override > public Iterator iterator() { > return new Iterator() { > private long count = 0; > > public boolean hasNext() { > return count < size; > } > > public Integer next() { > if (!hasNext()) throw new NoSuchElementException(); > count++; > return 42; > ... These changes have been included in https://github.com/openjdk/jdk/pull/24925 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24538#issuecomment-2876405630 From duke at openjdk.org Tue May 13 12:59:58 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 12:59:58 GMT Subject: Withdrawn: 8354138: LinkedBlockingDeque allows us to exceed size with addAll() In-Reply-To: References: Message-ID: <6-uiOxLuI3xXGxOgHoN6TwdrQaOyaJqGeYPh1ljvbF0=.77bc6b9b-cdbb-4cf7-99c8-e48f3e7daef6@github.com> On Wed, 9 Apr 2025 06:24:30 GMT, kabutz wrote: > In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceeded the capacity with "if (count + n <= capacity)". However, if we pass in a collection that has more than Integer.MAX_VALUE items in it, then we can overflow n, making it negative. Since "count + n" is also negative, we can add the chain to our last item, and thus we end up with a LinkedBlockingDeque with more than Integer.MAX_VALUE of items and a negative size(). stream().count() gives the correct number of items. > > This happens both via the bulk add constructor LinkedBlockingDeque(Collection) and when we call addAll(Collection) directly. > > In Java 8, they didn't have the clever addAll() method, and thus it failed immediately. > > Here is some test code: > > > import java.util.*; > import java.util.concurrent.*; > > // To see the issue, run with at least 90 GB of memory: > // -XX:+UnlockExperimentalVMOptions -Xmx90g -Xms90g -XX:+UseEpsilonGC -verbose:gc > // To verify the fix, run with at least 200 GB of memory: > // -XX:+UnlockExperimentalVMOptions -Xmx200g -Xms200g -XX:+UseEpsilonGC -verbose:gc > // To try on older versions of Java that don't have the EpsilonGC, you can use: > // -XX:+UseG1GC -verbose:gc -Xmx91g -Xms91g -XX:NewSize=89g > public class NegativeSizedLinkedBlockingDeque { > public static void main(String... args) { > HUUUGECollection list = new HUUUGECollection(Integer.MAX_VALUE + 1L); > LinkedBlockingDeque lbd = new LinkedBlockingDeque<>(10); > lbd.addAll(list); > System.out.println("lbd.size() = " + lbd.size()); > System.out.println(lbd.stream().count()); > } > > public static class HUUUGECollection extends AbstractCollection { > private final long size; > > public HUUUGECollection(long size) { > this.size = size; > } > > @Override > public int size() { > return size < Integer.MAX_VALUE ? (int) size : Integer.MAX_VALUE; > } > > @Override > public Iterator iterator() { > return new Iterator() { > private long count = 0; > > public boolean hasNext() { > return count < size; > } > > public Integer next() { > if (!hasNext()) throw new NoSuchElementException(); > count++; > return 42; > ... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24538 From duke at openjdk.org Tue May 13 13:01:21 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 13:01:21 GMT Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if capacity has been reached In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 18:39:30 GMT, kabutz wrote: > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > Our suggestion is to make count volatile, and then exiting early from poll() and offer() These changes have been included in https://github.com/openjdk/jdk/pull/24925 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2876408149 From duke at openjdk.org Tue May 13 13:01:10 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 13:01:10 GMT Subject: RFR: 8354060: LinkedBlockingDeque.clear() should preserve weakly-consistent iterators In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 11:55:08 GMT, kabutz wrote: > LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. > > The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator all support this. > > This can be fixed very easily by linking both f.prev and f.next back to f. These changes have been included in https://github.com/openjdk/jdk/pull/24925 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24488#issuecomment-2876408558 From duke at openjdk.org Tue May 13 13:01:22 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 13:01:22 GMT Subject: Withdrawn: 8354076: LinkedBlockingDeque offer() creates nodes even if capacity has been reached In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 18:39:30 GMT, kabutz wrote: > In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking. > > In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field. > > Our suggestion is to make count volatile, and then exiting early from poll() and offer() This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24521 From duke at openjdk.org Tue May 13 13:01:11 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 13:01:11 GMT Subject: Withdrawn: 8354060: LinkedBlockingDeque.clear() should preserve weakly-consistent iterators In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 11:55:08 GMT, kabutz wrote: > LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work. > > The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator all support this. > > This can be fixed very easily by linking both f.prev and f.next back to f. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24488 From duke at openjdk.org Tue May 13 13:02:16 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 13:02:16 GMT Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw InterrruptedException in put/take In-Reply-To: References: Message-ID: <9zB863pIeHWzsHIMR9Yj_woTvMmW9f2Q0uFuEDofmhQ=.fcb3989b-a29c-4084-bde6-e5a841090c95@github.com> On Wed, 5 Feb 2025 15:36:15 GMT, kabutz wrote: > The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down. These changes have been included in https://github.com/openjdk/jdk/pull/24925 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23464#issuecomment-2876413837 From duke at openjdk.org Tue May 13 13:03:42 2025 From: duke at openjdk.org (Johannes Graham) Date: Tue, 13 May 2025 13:03:42 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v2] In-Reply-To: References: Message-ID: > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: fix code tag in javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25173/files - new: https://git.openjdk.org/jdk/pull/25173/files/569a6dfc..ba8d3933 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173 PR: https://git.openjdk.org/jdk/pull/25173 From roger.riggs at oracle.com Tue May 13 13:10:40 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 13 May 2025 09:10:40 -0400 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> Message-ID: <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> Hi Markus, A main point was to avoid trying to do everything at once. The PR comments become hard to follow and intermingled and it takes longer to get agreement because of the thrash in the PR. Roger On 5/13/25 5:05 AM, Markus KARG wrote: > Thank you, Roger. > > Actually the method helps in the "toString()" variants, too, as in > some places we could *get rid* of "toString()" (which is more work > than "just" a buffer due to the added compression complexity). > > In fact, I already took the time to rewrite *all* of them while > waiting for the approval of this list posting. In *all* cases *less* > buffering / copying is needed, and *less* "toString()" conversion > (which is a copy under the hood) is needed. So if I would be allowed > to show the code as a PR, it would be much easier to explain and discuss. > > A PR is the best place to discuss "how to code would change". In the > worst case, let's drop it if we see that it is actually a bad thing. > > -Markus > > > Am 12.05.2025 um 20:18 schrieb Roger Riggs: >> Hi Markus, >> >> On the surface, its looks constructive. >> I suspect that many of these cases will turn into discussions about >> the right/best/better way to buffer the characters. >> The getChars method only helps when extracting to a char array, many >> of the current implementations create strings as the intermediary. >> The advantage of the 1 character at a time technique is not needing a >> (separated allocated) buffer. >> Consider taking a few at a time before launching into the whole set. >> >> $.02, Roger >> >> On 5/11/25 2:45 AM, Markus KARG wrote: >>> Dear Core Libs Team, >>> >>> I am hereby requesting comments on JDK-8356679. >>> >>> I would like to invest some time and set up a PR implementing Chen >>> Liangs's proposal laid out in >>> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, >>> the text of that JBS is copied below. According to the Developer's >>> Guide I do need to get broad agreement BEFORE filing a PR. >>> Therefore, I kindly ask everybody to briefly show consent, so I may >>> file a PR. >>> >>> Thanks >>> -Markus >>> >>> >>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >>> >>> Recently OpenJDK adopted the new method CharSequence::getChars(int, >>> int, char[], int) for inclusion in Java 25. As a bulk reader method, >>> it allows potentially improved efficiency over the previously >>> available char-by-char reader method CharSequence::charAt(int). >>> >>> Chen Liang suggested on March 23rd on the core-lib-dev mailing list >>> to use the new method within the internal source code of OpenJDK for >>> the implementation of Appendables (see >>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >>> The idea behind this is that the implementations might be more >>> efficient then. >>> >>> A quick analysis of the OpenJDK source code identified (at least) >>> the following classes which could potentially run more efficient >>> when using CharSequence::getChars internally, thanks to bulk reading >>> and / or prevention of internal copies / toString() conversions: >>> * java.io.Writer >>> * java.io.StringWriter >>> * java.io.PrintWriter >>> * java.io.BufferedWriter >>> * java.io.CharArrayWriter >>> * java.io.FileWriter >>> * java.io.OutputStreamWriter >>> * sun.nio.cs.StreamEncoder >>> * java.io.PrintStream >>> * java.nio.CharBuffer >>> >>> In the sense of "eat your own dog food", it makes sense to implement >>> Chen's idea in (at least) those classes. Possibly more classes could >>> get identified when taking a deeper look. Besides the potential >>> efficiency improvements, it would be a good show case for the usage >>> of the new API. >>> >>> The risk of this change should be low, as test coverage exists, and >>> as the intended changes are solely internal to the implementation. >>> No API will get changed. In some cases the JavaDocs will get >>> slightly adapted where it currently exposes the actual >>> implementation (to not lie in future). >>> >> From duke at openjdk.org Tue May 13 13:19:59 2025 From: duke at openjdk.org (kabutz) Date: Tue, 13 May 2025 13:19:59 GMT Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements In-Reply-To: References: <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com> <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com> Message-ID: On Tue, 13 May 2025 12:44:38 GMT, Viktor Klang wrote: > About a month or so. Perfect, thanks @viktorklang-ora. I've marked the other issues as closed - duplicates, and referenced this single umbrella PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2876484773 From vklang at openjdk.org Tue May 13 13:27:55 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 May 2025 13:27:55 GMT Subject: RFR: 8350765: Need to pin when accessing thread container from virtual thread [v2] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 14:01:16 GMT, Alan Bateman wrote: >> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code. Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues. >> >> Testing tier1-5, quick statup/footprint, noreg-hard > > 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 10 additional commits since the last revision: > > - Fix/improve comment > - Merge branch 'master' into JDK-8350765 > - Merge branch 'master' into JDK-8350765 > - No need to used qualified name > - Merge branch 'master' into JDK-8350765 > - Update > - Merge branch 'master' into JDK-8350765 > - Add method to ContinuationSupport > - Missing / > - Initial commit Nice work, Alan! ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23810#pullrequestreview-2836780689 From vklang at openjdk.org Tue May 13 13:29:00 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 May 2025 13:29:00 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 20:43:20 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Jaikiran comments, improve thread reference tracking, more documents > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove > - Update src/java.base/share/classes/java/lang/ClassValue.java > > Co-authored-by: Shaojin Wen > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove > - Reviews from viktor > - Rewrite impl to follow the new simplified spec > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove > - Try to simplify the model - use the finish of computeValue > > - Test updates - remove repetition, test case for no stale installation > - Fix incorrect promise removal when unnecessary and add regression test > - ... and 12 more: https://git.openjdk.org/jdk/compare/60bb1184...e24a1fd7 src/java.base/share/classes/java/lang/ClassValue.java line 99: > 97: * that computed the value to associate. A new invocation to {@code > 98: * computeValue}, which that {@code remove} call happens-before, happens to > 99: * re-establish this happens-before relationship. Suggestion: * computeValue}, which that {@code remove} call happens-before, * re-establishes this happens-before relationship. src/java.base/share/classes/java/lang/ClassValue.java line 126: > 124: * value if it exists. Otherwise, this method tries to associate a value > 125: * from a {@link #computeValue computeValue} invocation until the associated > 126: * value exists, which may be from another thread. Suggestion: * value exists, which could be associated by a competing thread. src/java.base/share/classes/java/lang/ClassValue.java line 347: > 345: } > 346: > 347: // Arguments are nullable, intentionally to allow initial tokens Suggestion: // Arguments are intentionally nullable, to allow initial tokens src/java.base/share/classes/java/lang/ClassValue.java line 348: > 346: > 347: // Arguments are nullable, intentionally to allow initial tokens > 348: static boolean areCompatible(RemovalToken current, RemovalToken original) { Are "equivalent"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086738186 PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086742731 PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086745684 PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086747420 From liach at openjdk.org Tue May 13 13:34:38 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 13:34:38 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v14] In-Reply-To: References: Message-ID: <8C47-4udZPDRsG3vwfP03C3l2YOsBcUD3F_fTl1kqL0=.ead02b84-2cd3-4949-bb4d-1f4ed9cec366@github.com> > The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. > > The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. > > The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. > > Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Viktor Klang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24043/files - new: https://git.openjdk.org/jdk/pull/24043/files/e24a1fd7..be5dd3cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=12-13 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043 PR: https://git.openjdk.org/jdk/pull/24043 From liach at openjdk.org Tue May 13 13:34:41 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 13:34:41 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 12:47:12 GMT, Viktor Klang wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: >> >> - Jaikiran comments, improve thread reference tracking, more documents >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove >> - Update src/java.base/share/classes/java/lang/ClassValue.java >> >> Co-authored-by: Shaojin Wen >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove >> - Reviews from viktor >> - Rewrite impl to follow the new simplified spec >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove >> - Try to simplify the model - use the finish of computeValue >> >> - Test updates - remove repetition, test case for no stale installation >> - Fix incorrect promise removal when unnecessary and add regression test >> - ... and 12 more: https://git.openjdk.org/jdk/compare/f1e84a54...e24a1fd7 > > src/java.base/share/classes/java/lang/ClassValue.java line 99: > >> 97: * that computed the value to associate. A new invocation to {@code >> 98: * computeValue}, which that {@code remove} call happens-before, happens to >> 99: * re-establish this happens-before relationship. > > Suggestion: > > * computeValue}, which that {@code remove} call happens-before, > * re-establishes this happens-before relationship. I think `can re-establish` or `will re-establish` is better just because this happens after the outcome. What do you think? > src/java.base/share/classes/java/lang/ClassValue.java line 348: > >> 346: >> 347: // Arguments are nullable, intentionally to allow initial tokens >> 348: static boolean areCompatible(RemovalToken current, RemovalToken original) { > > Are "equivalent"? Not really: if you have an original token and a current token created during the computeValue of the original token, they are compatible but not really "equivalent" (i.e. the threadId case) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086833475 PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086837740 From liach at openjdk.org Tue May 13 13:34:41 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 13:34:41 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:30:18 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/ClassValue.java line 348: >> >>> 346: >>> 347: // Arguments are nullable, intentionally to allow initial tokens >>> 348: static boolean areCompatible(RemovalToken current, RemovalToken original) { >> >> Are "equivalent"? > > Not really: if you have an original token and a current token created during the computeValue of the original token, they are compatible but not really "equivalent" (i.e. the threadId case) Maybe `canAssociate`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086840404 From alanb at openjdk.org Tue May 13 13:38:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 13:38:56 GMT Subject: Integrated: 8350765: Need to pin when accessing thread container from virtual thread In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman wrote: > Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code. Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues. > > Testing tier1-5, quick statup/footprint, noreg-hard This pull request has now been integrated. Changeset: fa419489 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/fa419489d3769a989ee5bd948eeda0ed9be071e2 Stats: 94 lines in 6 files changed: 50 ins; 25 del; 19 mod 8350765: Need to pin when accessing thread container from virtual thread Reviewed-by: vklang, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23810 From pminborg at openjdk.org Tue May 13 13:44:07 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 May 2025 13:44:07 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v4] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 07:57:15 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments Thank you all reviewers for reviewing this PR! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2876567924 From pminborg at openjdk.org Tue May 13 13:44:08 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 13 May 2025 13:44:08 GMT Subject: Integrated: 8356080: Address post-integration comments for Stable Values In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote: > This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. > > Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. > > Unfortunately, this PR shows the total commit history for stable values. This pull request has now been integrated. Changeset: 066477de Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/066477de80fc8719651b7b7bf2d02b1f58135f77 Stats: 437 lines in 14 files changed: 307 ins; 50 del; 80 mod 8356080: Address post-integration comments for Stable Values Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/25004 From jpai at openjdk.org Tue May 13 13:52:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 13:52:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167: > 165: return null; > 166: } > 167: case String label when READ_WRITE.label.equals(label) -> { I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler: case "readWrite" -> { return READ_WRITE; } case "readOnly" -> { return READ_ONLY; } src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 174: > 172: } > 173: default -> { > 174: } Since we don't allow for any other value, I think moving the `throw new IllegalArgumentException` from outside of the switch into this `default` case might be suitable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086881780 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086877658 From liach at openjdk.org Tue May 13 13:56:37 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 13:56:37 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v15] In-Reply-To: References: Message-ID: > The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. > > The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. > > The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. > > Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: More suggestions from viktor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24043/files - new: https://git.openjdk.org/jdk/pull/24043/files/be5dd3cc..08f78fc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=13-14 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043 PR: https://git.openjdk.org/jdk/pull/24043 From liach at openjdk.org Tue May 13 13:56:37 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 13:56:37 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v14] In-Reply-To: <8C47-4udZPDRsG3vwfP03C3l2YOsBcUD3F_fTl1kqL0=.ead02b84-2cd3-4949-bb4d-1f4ed9cec366@github.com> References: <8C47-4udZPDRsG3vwfP03C3l2YOsBcUD3F_fTl1kqL0=.ead02b84-2cd3-4949-bb4d-1f4ed9cec366@github.com> Message-ID: On Tue, 13 May 2025 13:34:38 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Viktor Klang I have updated per suggestions; also reflected these minor corrections in the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2876622878 From vklang at openjdk.org Tue May 13 13:56:37 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 May 2025 13:56:37 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:28:27 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/ClassValue.java line 99: >> >>> 97: * that computed the value to associate. A new invocation to {@code >>> 98: * computeValue}, which that {@code remove} call happens-before, happens to >>> 99: * re-establish this happens-before relationship. >> >> Suggestion: >> >> * computeValue}, which that {@code remove} call happens-before, >> * re-establishes this happens-before relationship. > > I think `can re-establish` or `will re-establish` is better just because this happens after the outcome. What do you think? `will re-establish the happens-before relationship` sounds good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086880480 From vklang at openjdk.org Tue May 13 13:56:38 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 May 2025 13:56:38 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:31:25 GMT, Chen Liang wrote: >> Not really: if you have an original token and a current token created during the computeValue of the original token, they are compatible but not really "equivalent" (i.e. the threadId case) > > Maybe `canAssociate`? `allowsAssociation`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086878283 From jpai at openjdk.org Tue May 13 13:59:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 13:59:52 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 160: > 158: > 159: // Parses the file system permission from an environmental parameter. While > 160: // the FileSystemAccessMode is private, we don't need to check if it was The second sentence perhaps is a leftover? I don't see any `FileSystemAccessMode` type. I think it would be better to remove that second sentence altogether. The rest of the comment looks good and clearly states what this method does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086897450 From abarashev at openjdk.org Tue May 13 14:03:57 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 13 May 2025 14:03:57 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3] In-Reply-To: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com> References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com> <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com> Message-ID: On Tue, 13 May 2025 03:56:25 GMT, Hai-May Chao wrote: > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code). @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it's disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this. @seanjmullan What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2876654496 From rgiulietti at openjdk.org Tue May 13 14:08:02 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 13 May 2025 14:08:02 GMT Subject: Integrated: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath In-Reply-To: References: Message-ID: <3RupE3VvfgCe2Y10eyg2xF_YxKq0sXZ0EgCCh5yJ6Gs=.3a5500c0-c00a-405f-8040-8a6c40ccc90b@github.com> On Fri, 2 May 2025 11:47:32 GMT, Raffaello Giulietti wrote: > Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments. > Further, add `unsignedMultiplyExact` methods as well. This pull request has now been integrated. Changeset: 64a858c7 Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/64a858c7b832447c3dcf4a39a2b0929bc4d70c39 Stats: 724 lines in 3 files changed: 724 ins; 0 del; 0 mod 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/25003 From shade at openjdk.org Tue May 13 14:09:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 May 2025 14:09:56 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> Message-ID: On Wed, 30 Apr 2025 16:06:23 GMT, Roger Riggs wrote: >> 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 six additional commits since the last revision: >> >> - Add bug ID >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Pull message into a field >> - Test cases >> - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions >> - Initial fix >> >> Good spawnhelper failure message >> >> Trying tests >> >> Print helper message on all IOExceptions >> >> Final > > Thanks for the bugid. Thanks! @RogerRiggs, @simonis, @lutkerd -- are you good with new output message? The line here: java.io.IOException: Cannot run program "pwd": Failed to exec spawn helper: pid: 1405770, exit code: 4, error: 0 (none) ... https://github.com/openjdk/jdk/pull/24149#issuecomment-2742889069 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2876680588 From amaembo at gmail.com Tue May 13 14:12:21 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 13 May 2025 16:12:21 +0200 Subject: Finding max or min of exactly two objects Message-ID: Hello! Several times already when writing Java programs, I stumbled with a simple task: given two objects with natural order, find the maximal of them. The algorithm I need could be formulated like this: > T max(T a, T b) { return a.compareTo(b) > 0 ? a : b; } Writing manually compareTo >= 0 looks too verbose, not very readable and error-prone: one has to mention both objects twice, and it's possible to mix > with <. I can surely add a method mentioned above to a utility class in my project and use it everywhere. However, I feel that it deserves a place in the standard library. The alternatives we have now: BinaryOperator.maxBy(Comparator.naturalOrder()).apply(a, b); This speaks clearly about the intent (we'd like to get the maximum and we write 'maxBy') but very wordy. Stream.of(a, b).max(Comparator.naturalOrder()).get(); Also clear and a little bit shorter, but has an unnecessary Optional in-between (we know that we have at least one element, so the result is always present) and we have to mention the comparator. Finally, it might be much less efficient than expected. Probably we can add simple static methods `max` and `min` either to the `Comparator` interface, or to `java.util.Objects`? Such methods would complement methods from the `Math` class for numbers. In addition, having default methods `max` and `min` in the `Comparator` interface would also be nice: String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world"); What do you think? Can we proceed with such an enhancement? With best regards, Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From heidinga at openjdk.org Tue May 13 14:15:57 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 13 May 2025 14:15:57 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v7] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:06:44 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added param to makefile function SetupAOT for choosing onestep vs twostep src/java.base/share/man/java.md line 4073: > 4071: - `-XX:AOTMode=record` is specified, or > 4072: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode=auto` is specified, or > 4073: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specidied. Suggestion: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specified. src/java.base/share/man/java.md line 4084: > 4082: - `record`: Execute the application in the Training phase. > 4083: At least one of `-XX:AOTConfiguration=`*configfile* and/or > 4084: `-XX:AOTCache=`*cachefile* must be specified. Suggestion: `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* must be specified. AOTCacheOutput is also a valid configuration for mode record, right? src/java.base/share/man/java.md line 4087: > 4085: If `-XX:AOTConfiguration=`*configfile* is specified, the JVM gathers > 4086: statistical data and stores them into *configfile*. > 4087: If `-XX:AOTCache=`*cachefile* is specified, a second JVM process is launched Suggestion: If `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* is specified, a second JVM process is launched ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086925261 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086929891 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086934364 From aph at openjdk.org Tue May 13 14:17:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 13 May 2025 14:17:14 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v4] In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: <_YHxBGEeUL7hfvcstwV9F0BCAC-ijDjoI__DrDAQuqM=.5e56c31b-5cf1-447f-83cf-2166dccf7b0e@github.com> > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25147/files - new: https://git.openjdk.org/jdk/pull/25147/files/47179d57..23838f8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=02-03 Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From duke at openjdk.org Tue May 13 14:30:12 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 14:30:12 GMT Subject: RFR: 8077587: BigInteger Roots [v12] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch - Compute remainder in the final loop to do less iterations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/3d8562f1..0cfb4f65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=10-11 Stats: 60 lines in 2 files changed: 17 ins; 13 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From brian.goetz at oracle.com Tue May 13 14:30:33 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 13 May 2025 10:30:33 -0400 Subject: Finding max or min of exactly two objects In-Reply-To: References: Message-ID: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> When we did Lambda, we made a few mistakes in the category of adding default methods to some "highly abstract" types, such as Function::andThen.? You were there; these were well-intentioned, but we neglected to think sufficiently about the consequences for subclasses.? For example: ??? interface Function { ??????? U apply(T t); ??????? default Function andThen(Function g) { ... } ??? } seems fine, but then when you extend it: ??? interface UnaryOperator extends Function { ??? } you kind of lose, because you can't compose _unary operators_ using Function::compose.? And if you try to refine it: ??? interface UnaryOperator extends Function { ??????? default UnaryOperator andThen(UnaryOperator g) { ... } ??? } you end up overloading, not overriding the method, in a way that clients cannot distinguish: `f.andThen(lambda)` will likely not be able to distinguish between the overloads, because they have the same shape.? Ooops. So with that as background, I am very cautious to consider adding methods to Comparable, because it is a highly abstract type that was designed for extension, and the risk of the above kind of clash seems "not low". Comparator seems less risky, because it is not designed to be extended by domain objects, but instead functions more like a type class in Haskell -- it is behavior _about_ a type, defined from the outside.? And Haskell would agree with you that this move is sensible; here's Haskell's `Ord` (like Comparator), which extends `Eq` (providing equality.) class? (Eq a) => Ord a? where ??? compare????????????? :: a -> a -> Ordering ??? (<), (<=), (>), (>=) :: a -> a -> Bool ??? max, min???????????? :: a -> a -> a ??? compare x y = if x == y then EQ ????????????????? -- NB: must be '<=' not '<' to validate the ????????????????? -- above claim about the minimal things that ????????????????? -- can be defined for an instance of Ord: ????????????????? else if x <= y then LT ????????????????? else GT ??? x <= y = case compare x y of { GT -> False; _ -> True } ??? x >= y = y <= x ??? x > y = not (x <= y) ??? x < y = not (y <= x) ??????? -- These two default methods use '<=' rather than 'compare' ??????? -- because the latter is often more expensive ??? max x y = if x <= y then y else x ??? min x y = if x <= y then x else y ??? {-# MINIMAL compare | (<=) #-} The `compare` method is like our Comparator method, just returning a three-valued enum rather than an int.? (Haskell has a cool feature here, where you can define all the methods in terms of others, and then you can override whichever ones make sense to break the cycles.? The MINIMAL annotation says "if you provide either compare or <=, you're good."? I wish we had this for interfaces with default methods.)? It then proceeds to derive `min` and `max` from `<=` (which might itself be derived from `compare`.) OK, "comparative languages" lesson over, back to your point. There are two ways to get where you want: a static method that takes a comparator and the operands (`Comparator.max(c, a, b)`), or a default method on Comparator (`c.max(a, b)`).? (You say "add simple static methods ... to Comparator" but I think you mean to put the word `static` elsewhere in that sentence.) I am receptive to the idea of extending Comparator here, but would want to think about it more to feel out potential mistakes like the `andThen` one above.? But your point is solid: a "comparator" is also a "maxxer" and a "minner" (neither of those are words, and if they were, are probably spelled wrong), and that is a natural place to locate such behavior. On 5/13/2025 10:12 AM, Tagir Valeev wrote: > Hello! > > Several times already when writing Java programs, I stumbled with a > simple task: given two objects with natural order, find the maximal of > them. The algorithm I need could be formulated like this: > > ? ? > T max(T a, T b) { > ? ? ? ? return a.compareTo(b) > 0 ? a : b; > ? ? } > > Writing manually compareTo >= 0 looks too verbose, not very readable > and error-prone: one has to mention both objects twice, and it's > possible to mix > with <. I can surely add a method mentioned above to > a utility class in my project and use it everywhere. However, I feel > that it deserves a place in the standard library. > > The alternatives we have now: > BinaryOperator.maxBy(Comparator.naturalOrder()).apply(a, b); > This speaks clearly about the intent (we'd like to get the maximum and > we write 'maxBy') but very wordy. > > Stream.of(a, b).max(Comparator.naturalOrder()).get(); > Also clear and a little bit shorter, but has an unnecessary Optional > in-between (we know that we have at least one element, so the result > is always present) and we have to mention the comparator. Finally, it > might be much less efficient than expected. > > Probably we can add simple static methods `max` and `min` either to > the `Comparator` interface, or to `java.util.Objects`? Such methods > would complement methods from the `Math` class for numbers. In > addition, having default methods `max` and `min` in the `Comparator` > interface would also be nice: > > String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world"); > > What do you think? Can we proceed with such an enhancement? > > With best regards, > Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue May 13 14:45:07 2025 From: duke at openjdk.org (Luca Kellermann) Date: Tue, 13 May 2025 14:45:07 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v4] In-Reply-To: References: Message-ID: <2UtDeU1Gh1l-OfzmdnMo7_vjm6LMoZ6iQoPNIETn-Ag=.83b1fd1a-a7a4-4492-9cd5-bb6e3632a51d@github.com> On Tue, 13 May 2025 07:57:15 GMT, Per Minborg wrote: >> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration. >> >> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example. >> >> Unfortunately, this PR shows the total commit history for stable values. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments src/java.base/share/classes/java/util/ImmutableCollections.java line 1732: > 1730: && Objects.equals(getKey(), e.getKey()) > 1731: // Invoke `getValue()` as late as possible to avoid evaluation > 1732: && Objects.equals(getValue(), e.getValue()); Suggestion: && Objects.equals(e.getValue(), getValue()); You already integrated and it's probably not that important, but this would additionally avoid evaluation if `e.getValue()` throws. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2086998430 From liach at openjdk.org Tue May 13 14:45:07 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 14:45:07 GMT Subject: RFR: 8356080: Address post-integration comments for Stable Values [v4] In-Reply-To: <2UtDeU1Gh1l-OfzmdnMo7_vjm6LMoZ6iQoPNIETn-Ag=.83b1fd1a-a7a4-4492-9cd5-bb6e3632a51d@github.com> References: <2UtDeU1Gh1l-OfzmdnMo7_vjm6LMoZ6iQoPNIETn-Ag=.83b1fd1a-a7a4-4492-9cd5-bb6e3632a51d@github.com> Message-ID: <4DT0NAevUHChM45tCJX8h7dPmCSc2a83OqH87bx3HAo=.96a4fbbf-33b0-467d-b70f-0f3fa577532b@github.com> On Tue, 13 May 2025 14:39:36 GMT, Luca Kellermann wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > src/java.base/share/classes/java/util/ImmutableCollections.java line 1732: > >> 1730: && Objects.equals(getKey(), e.getKey()) >> 1731: // Invoke `getValue()` as late as possible to avoid evaluation >> 1732: && Objects.equals(getValue(), e.getValue()); > > Suggestion: > > && Objects.equals(e.getValue(), getValue()); > > You already integrated and it's probably not that important, but this would additionally avoid evaluation if `e.getValue()` throws. This is in the realms of microoptimization now... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2087007810 From duke at openjdk.org Tue May 13 14:48:55 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 13 May 2025 14:48:55 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Refactor container runtime version code The change looks good. There might be some issues with container engine version parsing. I wrote 2 comments. but cold not post them. They are in "pending" state. Not sure why. Should the comments be first reviewed by {Committers|Reviewers}? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2876826791 From rriggs at openjdk.org Tue May 13 14:51:00 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 May 2025 14:51:00 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Mon, 12 May 2025 23:51:19 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter 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: > > - 8354724: Attempt to further improve verbiage > - Merge > - Update src/java.base/share/classes/java/io/Reader.java > > 8354724: Apply suggested changes for readAllLines. > > Co-authored-by: Roger Riggs > - Update src/java.base/share/classes/java/io/Reader.java > > 8354724: Apply suggested changes for readAllAsString. > > Co-authored-by: Roger Riggs > - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test > - 8354724: Fix potential NPE in test > - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test > - 8354724: Improve test per reviewer comments > - 8354724: Add missing toList(), tweak verbiage; update test > - 8354724: Add Reader.readAllLines; test not yet updated > - ... and 11 more: https://git.openjdk.org/jdk/compare/dcf15854...1d811589 Looks good, I think this (with fix above for stream -> reader) is ready to create the CSR and get that review process moving. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2876832823 From rriggs at openjdk.org Tue May 13 14:57:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 May 2025 14:57:54 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v5] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote: >> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. >> >> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. >> >> I am very open to bike-shedding about the actual message :) >> >> Additional testing: >> - [x] Ad-hoc experiments with breaking jspawnhelper >> - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` > > 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 nine additional commits since the last revision: > > - Print error decoding > - Touch up formatting message > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Add bug ID > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Pull message into a field > - Test cases > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Initial fix > > Good spawnhelper failure message > > Trying tests > > Print helper message on all IOExceptions > > Final Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2837127473 From simonis at openjdk.org Tue May 13 14:57:54 2025 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 13 May 2025 14:57:54 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v5] In-Reply-To: References: Message-ID: <0fWy_XJXD0_iSnux8cE6jWFf03Ukfs_FowPzvJWAzn8=.068f793e-aa66-4b2e-bd33-d7f020a50924@github.com> On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote: >> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. >> >> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. >> >> I am very open to bike-shedding about the actual message :) >> >> Additional testing: >> - [x] Ad-hoc experiments with breaking jspawnhelper >> - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` > > 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 nine additional commits since the last revision: > > - Print error decoding > - Touch up formatting message > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Add bug ID > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Pull message into a field > - Test cases > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Initial fix > > Good spawnhelper failure message > > Trying tests > > Print helper message on all IOExceptions > > Final Still OK. Time to ship... ------------- Marked as reviewed by simonis (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2837131004 From forax at univ-mlv.fr Tue May 13 14:58:29 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 May 2025 16:58:29 +0200 (CEST) Subject: Finding max or min of exactly two objects In-Reply-To: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> References: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> Message-ID: <1307830774.264764550.1747148309305.JavaMail.zimbra@univ-eiffel.fr> > From: "Brian Goetz" > To: "Tagir Valeev" , "core-libs-dev" > > Sent: Tuesday, May 13, 2025 4:30:33 PM > Subject: Re: Finding max or min of exactly two objects > When we did Lambda, we made a few mistakes in the category of adding default > methods to some "highly abstract" types, such as Function::andThen. You were > there; these were well-intentioned, but we neglected to think sufficiently > about the consequences for subclasses. For example: > interface Function { > U apply(T t); > default Function andThen(Function g) { ... } > } > seems fine, but then when you extend it: > interface UnaryOperator extends Function { > } > you kind of lose, because you can't compose _unary operators_ using > Function::compose. And if you try to refine it: > interface UnaryOperator extends Function { > default UnaryOperator andThen(UnaryOperator g) { ... } > } > you end up overloading, not overriding the method, in a way that clients cannot > distinguish: `f.andThen(lambda)` will likely not be able to distinguish between > the overloads, because they have the same shape. Ooops. It's not clear to me that the mistake was adding a default method but not using inheritance in between UnaryOperator and Function. A functional interface represents a structural type but by adding inheritance, we made it a weird mix. > So with that as background, I am very cautious to consider adding methods to > Comparable, because it is a highly abstract type that was designed for > extension, and the risk of the above kind of clash seems "not low". > Comparator seems less risky, because it is not designed to be extended by domain > objects, but instead functions more like a type class in Haskell -- it is > behavior _about_ a type, defined from the outside. And Haskell would agree with > you that this move is sensible; here's Haskell's `Ord` (like Comparator), which > extends `Eq` (providing equality.) > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<), (<=), (>), (>=) :: a -> a -> Bool > max, min :: a -> a -> a > compare x y = if x == y then EQ > -- NB: must be '<=' not '<' to validate the > -- above claim about the minimal things that > -- can be defined for an instance of Ord: > else if x <= y then LT > else GT > x <= y = case compare x y of { GT -> False; _ -> True } > x >= y = y <= x > x > y = not (x <= y) > x < y = not (y <= x) > -- These two default methods use '<=' rather than 'compare' > -- because the latter is often more expensive > max x y = if x <= y then y else x > min x y = if x <= y then x else y > {-# MINIMAL compare | (<=) #-} > The `compare` method is like our Comparator method, just returning a > three-valued enum rather than an int. (Haskell has a cool feature here, where > you can define all the methods in terms of others, and then you can override > whichever ones make sense to break the cycles. The MINIMAL annotation says "if > you provide either compare or <=, you're good." I wish we had this for > interfaces with default methods.) It then proceeds to derive `min` and `max` > from `<=` (which might itself be derived from `compare`.) > OK, "comparative languages" lesson over, back to your point. There are two ways > to get where you want: a static method that takes a comparator and the operands > (`Comparator.max(c, a, b)`), or a default method on Comparator (`c.max(a, b)`). > (You say "add simple static methods ... to Comparator" but I think you mean to > put the word `static` elsewhere in that sentence.) > I am receptive to the idea of extending Comparator here, but would want to think > about it more to feel out potential mistakes like the `andThen` one above. But > your point is solid: a "comparator" is also a "maxxer" and a "minner" (neither > of those are words, and if they were, are probably spelled wrong), and that is > a natural place to locate such behavior. In terms of performance, unlike Kotlin where you can create an inline method, static methods that wrap an interface call sometimes behave funnily in Java because the profiling done by the VM is attached to a bytecode instruction and not to the call graph (or at least to the caller site). Sadly that means that Comparator.max(c a, b) can be significantly slower than c.compare(a, b). R?mi > On 5/13/2025 10:12 AM, Tagir Valeev wrote: >> Hello! >> Several times already when writing Java programs, I stumbled with a simple task: >> given two objects with natural order, find the maximal of them. The algorithm I >> need could be formulated like this: >> > T max(T a, T b) { >> return a.compareTo(b) > 0 ? a : b; >> } >> Writing manually compareTo >= 0 looks too verbose, not very readable and >> error-prone: one has to mention both objects twice, and it's possible to mix > >> with <. I can surely add a method mentioned above to a utility class in my >> project and use it everywhere. However, I feel that it deserves a place in the >> standard library. >> The alternatives we have now: >> BinaryOperator.maxBy(Comparator.naturalOrder()).apply(a, b); >> This speaks clearly about the intent (we'd like to get the maximum and we write >> 'maxBy') but very wordy. >> Stream.of(a, b).max(Comparator.naturalOrder()).get(); >> Also clear and a little bit shorter, but has an unnecessary Optional in-between >> (we know that we have at least one element, so the result is always present) >> and we have to mention the comparator. Finally, it might be much less efficient >> than expected. >> Probably we can add simple static methods `max` and `min` either to the >> `Comparator` interface, or to `java.util.Objects`? Such methods would >> complement methods from the `Math` class for numbers. In addition, having >> default methods `max` and `min` in the `Comparator` interface would also be >> nice: >> String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world"); >> What do you think? Can we proceed with such an enhancement? >> With best regards, >> Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From vklang at openjdk.org Tue May 13 15:01:02 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 May 2025 15:01:02 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v15] In-Reply-To: References: Message-ID: <1lbIVV3fiKrSnDK9EZSff2FCwFWA79ehFI8kk2vpycA=.9a0bc674-f178-42b7-9ffa-26797dbfc538@github.com> On Tue, 13 May 2025 13:56:37 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > More suggestions from viktor Marked as reviewed by vklang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24043#pullrequestreview-2837139440 From shade at openjdk.org Tue May 13 15:17:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 May 2025 15:17:53 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v5] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote: >> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. >> >> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. >> >> I am very open to bike-shedding about the actual message :) >> >> Additional testing: >> - [x] Ad-hoc experiments with breaking jspawnhelper >> - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` > > 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 nine additional commits since the last revision: > > - Print error decoding > - Touch up formatting message > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Add bug ID > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Pull message into a field > - Test cases > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Initial fix > > Good spawnhelper failure message > > Trying tests > > Print helper message on all IOExceptions > > Final Thanks. I am re-running testing, and will integrate once it turns back green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2876937488 From acobbs at openjdk.org Tue May 13 15:22:27 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 13 May 2025 15:22:27 GMT Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque Message-ID: Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API. Please review this PR which adds the following two new methods to `ArrayDeque`: * `public E get(int index)` * `public E set(int index, E element)` ------------- Commit messages: - Add placeholder @since Javadoc tags. - Use inline @return Javadoc tag per review suggestion. - Add indexed get() and set() methods to ArrayDeque. Changes: https://git.openjdk.org/jdk/pull/25189/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8143850 Stats: 146 lines in 2 files changed: 146 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25189/head:pull/25189 PR: https://git.openjdk.org/jdk/pull/25189 From duke at openjdk.org Tue May 13 15:22:27 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 13 May 2025 15:22:27 GMT Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque In-Reply-To: References: Message-ID: On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote: > Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API. > > Please review this PR which adds the following two new methods to `ArrayDeque`: > * `public E get(int index)` > * `public E set(int index, E element)` src/java.base/share/classes/java/util/ArrayDeque.java line 360: > 358: * > 359: * @param index index of the element to return > 360: * @return the element at the specified position in this deque This?can?use the?inline?form of?`@return`: Suggestion: * {@return the element at the specified position in this deque} * * @param index index of the element to return ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2086299413 From acobbs at openjdk.org Tue May 13 15:22:27 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 13 May 2025 15:22:27 GMT Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque In-Reply-To: References: Message-ID: On Tue, 13 May 2025 08:58:28 GMT, ExE Boss wrote: >> Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API. >> >> Please review this PR which adds the following two new methods to `ArrayDeque`: >> * `public E get(int index)` >> * `public E set(int index, E element)` > > src/java.base/share/classes/java/util/ArrayDeque.java line 360: > >> 358: * >> 359: * @param index index of the element to return >> 360: * @return the element at the specified position in this deque > > This?can?use the?inline?form of?`@return`: > Suggestion: > > * {@return the element at the specified position in this deque} > * > * @param index index of the element to return Indeed - thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2086995656 From amaembo at gmail.com Tue May 13 15:22:50 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 13 May 2025 17:22:50 +0200 Subject: Finding max or min of exactly two objects In-Reply-To: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> References: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> Message-ID: Hello, Brian! On Tue, May 13, 2025 at 4:30?PM Brian Goetz wrote: > So with that as background, I am very cautious to consider adding methods to Comparable, because it is a highly abstract type that was designed for extension, and the risk of the above kind of clash seems "not low". Sure, extending the Comparable interface is a no-go. Comparable implementations in the wild are often big classes with different semantics and a lot of functionality. This means that the chance of signature clash is high, and even if not, the names like 'max' or 'min' may not be the best choice for the user object that happens to implement Comparable. > Comparator seems less risky, because it is not designed to be extended by domain objects, but instead functions more like a type class in Haskell -- it is behavior _about_ a type, defined from the outside. And Haskell would agree with you that this move is sensible; here's Haskell's `Ord` (like Comparator), which extends `Eq` (providing equality.) Exactly, Comparator is less risky. Usually, user-defined comparators have nothing except a `compare` method or very few additional methods related to comparison. The Comparator's primary job is to compare, and finding the minimum or the maximum of two objects is pretty much related to comparison. In contrast, the primary job of Comparable objects is often something else, other than being compared, and implementing comparable is just a convenience, which is rarely necessary. > OK, "comparative languages" lesson over, back to your point. There are two ways to get where you want: a static method that takes a comparator and the operands (`Comparator.max(c, a, b)`), or a default method on Comparator (`c.max(a, b)`). (You say "add simple static methods ... to Comparator" but I think you mean to put the word `static` elsewhere in that sentence.) Well, probably I formulated it not so clearly. I'd like to have the following additions: public interface Comparator { ... default T max(T a, T b) { return compare(a, b) > 0 ? a : b; } default T min(T a, T b) { return compare(a, b) > 0 ? b : a; } static > T max(T a, T b) { return a.compareTo(b) > 0 ? a : b; } static > T min(T a, T b) { return a.compareTo(b) > 0 ? b : a; } } The static methods are not exactly related to the Comparator interface. That's why I'm somewhat dubious about the proper place for them (probably j.u.Objects fits better). They are just convenient shortcuts for Comparator.naturalOrder().max(...) and Comparator.naturalOrder().min(...) (and having one indirection less, which sometimes might be helpful for performance). We can omit static methods, keeping only default ones, so users will need to write fully Comparator.naturalOrder().max(...). This is still better than what we have today, but I think that natural order is an important enough concept to have dedicated methods for it. Passing a comparator as an argument to a static method (like Comparator.max(c, a, b)) is possible and somewhat in-line with existing APIs like Collections.max(coll[, comp]). However, I feel that adding default method is better. With best regards, Tagir Valeev > > I am receptive to the idea of extending Comparator here, but would want to think about it more to feel out potential mistakes like the `andThen` one above. But your point is solid: a "comparator" is also a "maxxer" and a "minner" (neither of those are words, and if they were, are probably spelled wrong), and that is a natural place to locate such behavior. > > > > > On 5/13/2025 10:12 AM, Tagir Valeev wrote: > > Hello! > > Several times already when writing Java programs, I stumbled with a simple task: given two objects with natural order, find the maximal of them. The algorithm I need could be formulated like this: > > > T max(T a, T b) { > return a.compareTo(b) > 0 ? a : b; > } > > Writing manually compareTo >= 0 looks too verbose, not very readable and error-prone: one has to mention both objects twice, and it's possible to mix > with <. I can surely add a method mentioned above to a utility class in my project and use it everywhere. However, I feel that it deserves a place in the standard library. > > The alternatives we have now: > BinaryOperator.maxBy(Comparator.naturalOrder()).apply(a, b); > This speaks clearly about the intent (we'd like to get the maximum and we write 'maxBy') but very wordy. > > Stream.of(a, b).max(Comparator.naturalOrder()).get(); > Also clear and a little bit shorter, but has an unnecessary Optional in-between (we know that we have at least one element, so the result is always present) and we have to mention the comparator. Finally, it might be much less efficient than expected. > > Probably we can add simple static methods `max` and `min` either to the `Comparator` interface, or to `java.util.Objects`? Such methods would complement methods from the `Math` class for numbers. In addition, having default methods `max` and `min` in the `Comparator` interface would also be nice: > > String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world"); > > What do you think? Can we proceed with such an enhancement? > > With best regards, > Tagir Valeev > > From bpb at openjdk.org Tue May 13 15:33:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 May 2025 15:33:43 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Tue, 13 May 2025 10:55:50 GMT, Alan Bateman wrote: >> Brian Burkhalter 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: >> >> - 8354724: Attempt to further improve verbiage >> - Merge >> - Update src/java.base/share/classes/java/io/Reader.java >> >> 8354724: Apply suggested changes for readAllLines. >> >> Co-authored-by: Roger Riggs >> - Update src/java.base/share/classes/java/io/Reader.java >> >> 8354724: Apply suggested changes for readAllAsString. >> >> Co-authored-by: Roger Riggs >> - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test >> - 8354724: Fix potential NPE in test >> - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test >> - 8354724: Improve test per reviewer comments >> - 8354724: Add missing toList(), tweak verbiage; update test >> - 8354724: Add Reader.readAllLines; test not yet updated >> - ... and 11 more: https://git.openjdk.org/jdk/compare/58731a34...1d811589 > > src/java.base/share/classes/java/io/Reader.java line 430: > >> 428: *

      The behavior for the case where the reader is >> 429: * asynchronously closed, or the thread interrupted during the >> 430: * read, is highly input stream specific, and therefore not specified. > > The carry over of this paragraph needs to replace "input stream" with reader (same thing in the other method). Yeah, I slipped up bringing the words over from `InputStream`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2087105321 From bpb at openjdk.org Tue May 13 15:33:39 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 May 2025 15:33:39 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: "stream" -> "reader" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/1d811589..98387b0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=17-18 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From bpb at openjdk.org Tue May 13 15:33:39 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 May 2025 15:33:39 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Tue, 13 May 2025 14:47:53 GMT, Roger Riggs wrote: > I think this (with fix above for stream -> reader) is ready to create the CSR ... Will do today. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2876983943 From bpb at openjdk.org Tue May 13 15:33:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 May 2025 15:33:43 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Tue, 13 May 2025 15:25:57 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 430: >> >>> 428: *

      The behavior for the case where the reader is >>> 429: * asynchronously closed, or the thread interrupted during the >>> 430: * read, is highly input stream specific, and therefore not specified. >> >> The carry over of this paragraph needs to replace "input stream" with reader (same thing in the other method). > > Yeah, I slipped up bringing the words over from `InputStream`. Fixed in 98387b0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2087112048 From brian.goetz at oracle.com Tue May 13 15:52:57 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 13 May 2025 11:52:57 -0400 Subject: Finding max or min of exactly two objects In-Reply-To: References: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> Message-ID: <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com> > Well, probably I formulated it not so clearly. I'd like to have the > following additions: > > public interface Comparator { > ... > default T max(T a, T b) { > return compare(a, b) > 0 ? a : b; > } > > default T min(T a, T b) { > return compare(a, b) > 0 ? b : a; > } > > static > T max(T a, T b) { > return a.compareTo(b) > 0 ? a : b; > } > > static > T min(T a, T b) { > return a.compareTo(b) > 0 ? b : a; > } > } Let's separate these.? I think the first two have a good claim to be in Comparator; I think the latter two probably live better in Comparable, which feels like a separate conversation (and maybe less important?)?? (And also, there's some overlap with some yet-uncollapsed stuff going on in Valhalla that I'd like to steer clear of.) From alanb at openjdk.org Tue May 13 15:53:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 15:53:58 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation src/java.base/share/classes/java/lang/System.java line 2113: > 2111: > 2112: public int uncheckedCountPositives(byte[] bytes, int offset, int length) { > 2113: return StringCoding.countPositives(bytes, offset, length); The prefix means the method is uncheckedXXX when outside of java.lang, and XXX when in java.lang. Okay for this PR but I think we should follow-up and rename the methods in java.lang to uncheckedXXX, then introduce checked versions that do the bounds check. In this case, we could have countPositives exposed via JLA, its implementation would do the bounds check before calling the unchecked version. It would mean that "far away" callers in DIS, OIS, ZipCoder, ... would have a bounds check but it would make things easier to audit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087154008 From naoto at openjdk.org Tue May 13 16:23:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 May 2025 16:23:55 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com> Message-ID: On Tue, 13 May 2025 12:34:01 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/io/InputStreamReader.java line 59: >> >>> 57: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); >>> 58: * } >>> 59: * >> >> There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?) > > How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK. There are several locations in the jdk source (I simply grep'ed for `new InputStreamReader(System.in)`). And yes, they will need to be replaced with the recommended usage. I will address them with a different JBS issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2087206716 From aph at openjdk.org Tue May 13 16:27:41 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 13 May 2025 16:27:41 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v5] In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Copyright - Remove AArch64 exception from native threshold ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25147/files - new: https://git.openjdk.org/jdk/pull/25147/files/23838f8b..87eadb40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From aph at openjdk.org Tue May 13 16:27:41 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 13 May 2025 16:27:41 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2] In-Reply-To: <6iRBKELx-Xnkgfm4MbONISmz9D3SjO_38PlaQXijv7w=.d6cb630c-7e83-4695-9ccc-6cfa30da5e17@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> <6iRBKELx-Xnkgfm4MbONISmz9D3SjO_38PlaQXijv7w=.d6cb630c-7e83-4695-9ccc-6cfa30da5e17@github.com> Message-ID: On Mon, 12 May 2025 09:39:48 GMT, Andrew Haley wrote: > > Looking at the improvements made, I suggest we also change (in `SegmentBulkOperations`): > > ``` > > private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 18 : 5); > > ``` > > to > > ``` > > private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", 5); > > ``` > > Possibly so, yes, but I'm still looking at the reasons for the differences. OK, I've done that. Numbers below, and I think that makes the cut between Java code and the intrinsic at the right place. Benchmark (aligned) (size) Mode Cnt Score Error Units MemorySegmentFillUnsafe.panama true 1 avgt 10 1.522 ? 0.004 ns/op MemorySegmentFillUnsafe.panama true 2 avgt 10 1.385 ? 0.003 ns/op MemorySegmentFillUnsafe.panama true 3 avgt 10 1.387 ? 0.003 ns/op MemorySegmentFillUnsafe.panama true 4 avgt 10 1.520 ? 0.004 ns/op MemorySegmentFillUnsafe.panama true 5 avgt 10 1.530 ? 0.007 ns/op MemorySegmentFillUnsafe.panama true 6 avgt 10 1.523 ? 0.003 ns/op MemorySegmentFillUnsafe.panama true 7 avgt 10 1.538 ? 0.010 ns/op MemorySegmentFillUnsafe.panama true 8 avgt 10 1.663 ? 0.014 ns/op MemorySegmentFillUnsafe.panama true 15 avgt 10 1.940 ? 0.005 ns/op MemorySegmentFillUnsafe.panama true 16 avgt 10 1.812 ? 0.007 ns/op MemorySegmentFillUnsafe.panama true 63 avgt 10 2.332 ? 0.005 ns/op MemorySegmentFillUnsafe.panama true 64 avgt 10 2.157 ? 0.009 ns/op MemorySegmentFillUnsafe.panama true 255 avgt 10 3.857 ? 0.057 ns/op MemorySegmentFillUnsafe.panama true 256 avgt 10 3.506 ? 0.015 ns/op MemorySegmentFillUnsafe.panama false 1 avgt 10 1.522 ? 0.005 ns/op MemorySegmentFillUnsafe.panama false 2 avgt 10 1.384 ? 0.004 ns/op MemorySegmentFillUnsafe.panama false 3 avgt 10 1.386 ? 0.004 ns/op MemorySegmentFillUnsafe.panama false 4 avgt 10 1.520 ? 0.004 ns/op MemorySegmentFillUnsafe.panama false 5 avgt 10 1.528 ? 0.009 ns/op MemorySegmentFillUnsafe.panama false 6 avgt 10 1.525 ? 0.004 ns/op MemorySegmentFillUnsafe.panama false 7 avgt 10 1.533 ? 0.003 ns/op MemorySegmentFillUnsafe.panama false 8 avgt 10 1.665 ? 0.004 ns/op MemorySegmentFillUnsafe.panama false 15 avgt 10 1.941 ? 0.004 ns/op MemorySegmentFillUnsafe.panama false 16 avgt 10 1.811 ? 0.008 ns/op MemorySegmentFillUnsafe.panama false 63 avgt 10 2.332 ? 0.006 ns/op MemorySegmentFillUnsafe.panama false 64 avgt 10 2.152 ? 0.005 ns/op MemorySegmentFillUnsafe.panama false 255 avgt 10 5.040 ? 0.041 ns/op MemorySegmentFillUnsafe.panama false 256 avgt 10 4.859 ? 0.040 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2877178492 From alanb at openjdk.org Tue May 13 16:28:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 16:28:01 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test The implementation changes look good and nice to get this one fixed. I didn't spend time on the tests but I see others have reviewed in detail so you don't need me. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2837419251 From jpai at openjdk.org Tue May 13 16:28:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 16:28:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208: > 206: boolean shouldCreate = isTrue(env, "create"); > 207: if (shouldCreate && forceReadOnly) { > 208: throw new IllegalArgumentException( Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`. So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2087216326 From alanb at openjdk.org Tue May 13 16:39:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 May 2025 16:39:51 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com> On Tue, 13 May 2025 16:26:31 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208: > >> 206: boolean shouldCreate = isTrue(env, "create"); >> 207: if (shouldCreate && forceReadOnly) { >> 208: throw new IllegalArgumentException( > > Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`. > > So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API. I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2087233643 From naoto at openjdk.org Tue May 13 17:02:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 May 2025 17:02:54 GMT Subject: RFR: 8352755: Misconceptions about j.text.DecimalFormat digits during parsing [v3] In-Reply-To: <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com> References: <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com> Message-ID: On Thu, 8 May 2025 18:07:42 GMT, Justin Lu wrote: >> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed. >> >> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well. >> >> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as >> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing. >> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation. > > 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 five additional commits since the last revision: > > - CSR review - directed inheritDoc; make 'concrete subclass' wording normative > - Merge branch 'master' into JDK-8352755-limit-clarifications > - Merge branch 'master' into JDK-8352755-limit-clarifications > - Naoto's review: apiN -> implN. Rewording of maxintdig callout > - init Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24265#pullrequestreview-2837519548 From bchristi at openjdk.org Tue May 13 17:07:58 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 13 May 2025 17:07:58 GMT Subject: Integrated: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property In-Reply-To: References: Message-ID: On Fri, 9 May 2025 23:23:27 GMT, Brent Christian wrote: > For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`. > > Automated test results are omitted as expected. This pull request has now been integrated. Changeset: d1543429 Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/d1543429ff29ca0d761b8473b3fb8621abcd226d Stats: 82 lines in 4 files changed: 3 ins; 73 del; 6 mod 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Reviewed-by: naoto, bpb ------------- PR: https://git.openjdk.org/jdk/pull/25163 From duke at openjdk.org Tue May 13 17:26:08 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 17:26:08 GMT Subject: RFR: 8077587: BigInteger Roots [v13] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Code simplification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/0cfb4f65..32a5e5ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=11-12 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From forax at openjdk.org Tue May 13 17:39:55 2025 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 13 May 2025 17:39:55 GMT Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque In-Reply-To: References: Message-ID: On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote: > Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API. > > Please review this PR which adds the following two new methods to `ArrayDeque`: > * `public E get(int index)` > * `public E set(int index, E element)` src/java.base/share/classes/java/util/ArrayDeque.java line 384: > 382: public E set(int index, E element) { > 383: if (element == null) > 384: throw new NullPointerException(); please add curly braces around `throw ...` as described in the style guide. src/java.base/share/classes/java/util/ArrayDeque.java line 388: > 386: } > 387: > 388: private E getset(int index, E newValue) { Please keep the implementation simple and avoid this kind of tricks, we are not sure in the future if E will be forever nullable so calling getset(index, null) may not be valid in the future. test/jdk/java/util/ArrayDeque/IndexedAccess.java line 38: > 36: > 37: public class IndexedAccess { > 38: I think some tests are missing, if the ArrayDeque is empty, if the ArrayDeque is full, at least test/jdk/java/util/ArrayDeque/IndexedAccess.java line 75: > 73: > 74: try { > 75: a.set(0, null); assertThrow ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087336980 PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087335755 PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087338994 PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087337713 From duke at openjdk.org Tue May 13 18:02:03 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 18:02:03 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations Message-ID: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. ------------- Commit messages: - More clear comment - An optimization - Code simplification - Code simplification - Avoiding redundant code - Code simplification - Code simplifications for BigIntegers' bit operations Changes: https://git.openjdk.org/jdk/pull/25166/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356891 Stats: 83 lines in 1 file changed: 14 ins; 36 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From rgiulietti at openjdk.org Tue May 13 18:02:03 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 13 May 2025 18:02:03 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 wrote: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. @fabioromano1 While reviewers can of course file JBS issues on behalf of contributors, the recommende way is for the latter to file a [bug report](https://bugreport.java.com/bugreport/), as they know what they will work on better than anyone else. Contributors that are [JDK Project](https://openjdk.org/census#jdk) [authors](https://openjdk.org/guide/#becoming-an-author) can file [here](https://bugs.openjdk.org/). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2872531149 From duke at openjdk.org Tue May 13 18:02:04 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 18:02:04 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Mon, 12 May 2025 13:13:36 GMT, Raffaello Giulietti wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > @fabioromano1 While reviewers can of course file JBS issues on behalf of contributors, the recommende way is for the latter to file a [bug report](https://bugreport.java.com/bugreport/), as they know what they will work on better than anyone else. > > Contributors that are [JDK Project](https://openjdk.org/census#jdk) [authors](https://openjdk.org/guide/#becoming-an-author) can file [here](https://bugs.openjdk.org/). @rgiulietti I've submitted a bug report for the PR right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2872641531 From rgiulietti at openjdk.org Tue May 13 18:02:04 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 13 May 2025 18:02:04 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Mon, 12 May 2025 13:45:08 GMT, fabioromano1 wrote: >> @fabioromano1 While reviewers can of course file JBS issues on behalf of contributors, the recommende way is for the latter to file a [bug report](https://bugreport.java.com/bugreport/), as they know what they will work on better than anyone else. >> >> Contributors that are [JDK Project](https://openjdk.org/census#jdk) [authors](https://openjdk.org/guide/#becoming-an-author) can file [here](https://bugs.openjdk.org/). > > @rgiulietti I've submitted a bug report for the PR right now. @fabioromano1 FYI, your bug report landed now as [JDK-8356891](https://bugs.openjdk.org/browse/JDK-8356891). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2877471956 From duke at openjdk.org Tue May 13 18:02:04 2025 From: duke at openjdk.org (David Schlosnagle) Date: Tue, 13 May 2025 18:02:04 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 wrote: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. src/java.base/share/classes/java/math/BigInteger.java line 2642: > 2640: } > 2641: // (this.abs().bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE > 2642: if (scaleFactor + bitsToShift - exponent >= Integer.MAX_VALUE) { If this is overflow sensitive code, should this avoid adding on the left hand side? Suggestion: if (scaleFactor - exponent >= Integer.MAX_VALUE - bitsToShift) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083701393 From liach at openjdk.org Tue May 13 18:02:05 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 18:02:05 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Mon, 12 May 2025 01:46:25 GMT, David Schlosnagle wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > src/java.base/share/classes/java/math/BigInteger.java line 2642: > >> 2640: } >> 2641: // (this.abs().bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE >> 2642: if (scaleFactor + bitsToShift - exponent >= Integer.MAX_VALUE) { > > If this is overflow sensitive code, should this avoid adding on the left hand side? > > Suggestion: > > if (scaleFactor - exponent >= Integer.MAX_VALUE - bitsToShift) { I think we are fine here, `scaleFactor` is already `long` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083704486 From duke at openjdk.org Tue May 13 18:02:05 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 18:02:05 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Mon, 12 May 2025 01:52:51 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 2642: >> >>> 2640: } >>> 2641: // (this.abs().bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE >>> 2642: if (scaleFactor + bitsToShift - exponent >= Integer.MAX_VALUE) { >> >> If this is overflow sensitive code, should this avoid adding on the left hand side? >> >> Suggestion: >> >> if (scaleFactor - exponent >= Integer.MAX_VALUE - bitsToShift) { > > I think we are fine here, `scaleFactor` is already `long` > If this is overflow sensitive code, should this avoid adding on the left hand side? `scaleFactor` is a `long`, so `scaleFactor + bitsToShift - exponent == (bitLength() - 1L) * exponent`. Moreover, `scaleFactor + bitsToShift == (long) bitLength() * exponent`, so it does not oveflow a `long`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2084057073 From liach at openjdk.org Tue May 13 18:02:05 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 18:02:05 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 wrote: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. src/java.base/share/classes/java/math/BigInteger.java line 2828: > 2826: * assuming there are no leading zero ints. > 2827: */ > 2828: private static int bitLength(int[] val, int len) { This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount`: the `len` is always `val.length` and the `val` is always the `mag` array of some `BigInteger` from somewhere. Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083561722 From duke at openjdk.org Tue May 13 18:02:05 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 18:02:05 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Sun, 11 May 2025 16:00:55 GMT, Chen Liang wrote: > This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount` I would prefer `magBitLength` as a name, since `bitCount` is usually referred to one's bit count. But before do this, I'd hear the opinion of @rgiulietti about that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083563140 From duke at openjdk.org Tue May 13 18:02:05 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 18:02:05 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Sun, 11 May 2025 16:08:25 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 2828: >> >>> 2826: * assuming there are no leading zero ints. >>> 2827: */ >>> 2828: private static int bitLength(int[] val, int len) { >> >> This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount`: the `len` is always `val.length` and the `val` is always the `mag` array of some `BigInteger` from somewhere. Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive. > >> This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount` > > I would prefer `magBitLength` as a name, since `bitCount` is usually referred to one's bit count. But before do this, I'd hear the opinion of @rgiulietti about that. > Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive. I recall that `bitLength` is already cached, so it would be preferable to replace `bitLength`'s cache with `magBitLength`'s cache if we want to do so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083564019 From duke at openjdk.org Tue May 13 18:02:05 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 18:02:05 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Sun, 11 May 2025 16:12:38 GMT, fabioromano1 wrote: >>> This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount` >> >> I would prefer `magBitLength` as a name, since `bitCount` is usually referred to one's bit count. But before do this, I'd hear the opinion of @rgiulietti about that. > >> Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive. > > I recall that `bitLength` is already cached, so it would be preferable to replace `bitLength`'s cache with `magBitLength`'s cache if we want to do so. > the `len` is always `val.length` and the `val` is always the `mag` array of some `BigInteger` from somewhere. Yes, but making it an instance method could be too narrowing, as sometimes in the code `int[]` array local variables are used in preference of `mag` instance fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083567353 From almatvee at openjdk.org Tue May 13 18:08:58 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 May 2025 18:08:58 GMT Subject: Integrated: 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default In-Reply-To: References: Message-ID: On Tue, 13 May 2025 00:30:08 GMT, Alexander Matveev wrote: > `openssl` from macOS will ignore `faketime` and as result expired certificates will not be generated correctly. By default we should use these tools from Homebrew. This pull request has now been integrated. Changeset: 1569925a Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/1569925af49552268c4847bd201fb95e0e3819b7 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/25196 From naoto at openjdk.org Tue May 13 18:25:58 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 May 2025 18:25:58 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com> Message-ID: On Tue, 13 May 2025 16:21:36 GMT, Naoto Sato wrote: >> How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK. > > There are several locations in the jdk source (I simply grep'ed for `new InputStreamReader(System.in)`). And yes, they will need to be replaced with the recommended usage. I will address them with a different JBS issue. Issue filed: https://bugs.openjdk.org/browse/JDK-8356893 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2087403916 From vyazici at openjdk.org Tue May 13 19:14:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 13 May 2025 19:14:52 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com> Message-ID: <-VD4RPx9UU6KbJHprNmegMRJmsOsjlVTIRC4LqQa8m8=.10fa8ae0-dea8-43e4-91f8-8e0d6d380b06@github.com> On Tue, 13 May 2025 12:34:01 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/io/InputStreamReader.java line 59: >> >>> 57: * new InputStreamReader(System.in, System.getProperty("stdin.encoding")); >>> 58: * } >>> 59: * >> >> There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?) > > How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK. @liach, regex already reveals some, after tweaking it enough to eliminate false positives. ? `CTRL+Click`'ing on `InputStreamReader::new(InputStream)` gives an exhaustive list short enough to skim through. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2087471334 From archie.cobbs at gmail.com Tue May 13 19:20:34 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 13 May 2025 14:20:34 -0500 Subject: Proposal: Add new methods get(int) and set(int, E) to ArrayDeque In-Reply-To: References: Message-ID: On Mon, May 12, 2025 at 12:00?PM Archie Cobbs wrote: > I would like to offer to do the following: > > - Change the title of this bug from "retrofit ArrayDeque to implement > List" to "Add indexed get() and set() methods to ArrayDeque" > > > - Propose a corresponding PR and CSR to add get(int) and set(int, E) > methods to ArrayDeque > > But first I want to check with this list first to see if there are any > objections? > After some discussion it seems the more complete solution might be better, that is, giving ArrayDeque a true List view rather than just adding get() and set(). Since ArrayDeque's current hashCode()/equals() is not compatible with List, this would take the form of an asList() method, etc. Any thoughts appreciated. In the meantime I'll explore what that might look like. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrose at openjdk.org Tue May 13 19:31:54 2025 From: jrose at openjdk.org (John R Rose) Date: Tue, 13 May 2025 19:31:54 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:17:19 GMT, Volkan Yazici wrote: >> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302: >> >>> 300: * WARNING: This method does not perform any bound checks. >>> 301: */ >>> 302: int countPositives(byte[] ba, int off, int len); >> >> Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed. > > Submitted [8356380](https://bugs.openjdk.org/browse/JDK-8356380) to address this. See also pending PR https://github.com/openjdk/jdk/pull/24777 It documents the expectations of how an intrinsic method must be kept private. An intrinsic is a private "back door" in the VM, and must not be accessed (except perhaps in carefully documented unusual circumstances) outside of its own source file. There should be a non-private "front door" in the same source file which applies all relevant checks before calling the intrinsic. Such checks need to be at least as strong as the built-in JVM range checks, null checks, and type checks that would be performed, if the intrinsic were implemented in 100% pure Java bytecodes. In performance evaluations, such checks may appear to be redundant. But they must not be removed. Instead, whatever other checks are redundant with them (there must be some!) should be brought into the same C2 compilation task as the "front door" checks. This requires making the two sets of checks (if there are two) look similar enough that C2 (or another JIT) can recognize their redundance. Bringing the checks into the same task might require a ForceInline annotation (which is allowed only inside the JDK). Recognizing the checks as redundant might require a C2 bug fix or RFE. (The javadoc for IntrinsicCandidate says stuff like this.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087493446 From vyazici at openjdk.org Tue May 13 19:34:57 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 13 May 2025 19:34:57 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 15:51:12 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into jla >> - Improve `uncheckedGetBytesNoRepl` docs >> - Apply suggestions from code review >> >> Co-authored-by: Roger Riggs >> - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` >> - Fix `HexDigits` copyright year >> - Fix copyright years >> - Prefix touched methods with `unchecked` >> - Fix typo in pre-existing JavaDoc >> - Improve `JavaLangAccess` documentation > > src/java.base/share/classes/java/lang/System.java line 2113: > >> 2111: >> 2112: public int uncheckedCountPositives(byte[] bytes, int offset, int length) { >> 2113: return StringCoding.countPositives(bytes, offset, length); > > The prefix means the method is uncheckedXXX when outside of java.lang, and XXX when in java.lang. Okay for this PR but I think we should follow-up and rename the methods in java.lang to uncheckedXXX, then introduce checked versions that do the bounds check. In this case, we could have countPositives exposed via JLA, its implementation would do the bounds check before calling the unchecked version. It would mean that "far away" callers in DIS, OIS, ZipCoder, ... would have a bounds check but it would make things easier to audit. [8356380: Check bounds for JavaLangAccess::countPositives](https://bugs.openjdk.org/browse/JDK-8356380) will address this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087497657 From vromero at openjdk.org Tue May 13 19:36:11 2025 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 May 2025 19:36:11 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' into JDK-8354556 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java Co-authored-by: Chen Liang - additional changes from Archie - removing dead code - integrating code from Archie - fixing bugs, removing dead code - additional documentation changes and bug fixes - documentation and adding alias to lint categories - Merge branch 'master' into JDK-8354556 - addressing review comment - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29 ------------- Changes: https://git.openjdk.org/jdk/pull/24746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=12 Stats: 661 lines in 32 files changed: 576 ins; 37 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Tue May 13 20:00:00 2025 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 May 2025 20:00:00 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13] In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 02:25:24 GMT, Chen Liang wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8354556 >> - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java >> >> Co-authored-by: Chen Liang >> - additional changes from Archie >> - removing dead code >> - integrating code from Archie >> - fixing bugs, removing dead code >> - additional documentation changes and bug fixes >> - documentation and adding alias to lint categories >> - Merge branch 'master' into JDK-8354556 >> - addressing review comment >> - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29 > > make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1: > >> 1: /* > > Need to add handling of `RequiresIdentity` in `createAnnotation` update on CreateSymbols, the complete implementation with the changes for CreateSymbols should be included in the PR for [1]. Which will be developed in parallel to this proposal [1] https://bugs.openjdk.org/browse/JDK-8356894 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2087534670 From jlu at openjdk.org Tue May 13 20:26:07 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 May 2025 20:26:07 GMT Subject: Integrated: 8352755: Misconceptions about j.text.DecimalFormat digits during parsing In-Reply-To: References: Message-ID: <4MLN-99QTiXJX6PfuB3dSq2eurz9SVkYh0HBM7R8zB0=.a4eec50f-e68d-4a4f-a57f-31e536f073de@github.com> On Wed, 26 Mar 2025 20:31:07 GMT, Justin Lu wrote: > Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed. > > There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well. > > Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as > 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing. > 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation. This pull request has now been integrated. Changeset: e149bd3a Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/e149bd3a0c387698fe7b2ff6c373944ded773b8b Stats: 99 lines in 3 files changed: 9 ins; 20 del; 70 mod 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/24265 From duke at openjdk.org Tue May 13 21:09:31 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 21:09:31 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v2] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: <0qCm49dg55x2u_2FK4TFKtYsnH03F56rsFv82YzXqE0=.ecfd385a-a78d-4ef1-aed2-a4b8de0db116@github.com> > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: An optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/b6e47807..56ba43fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From duke at openjdk.org Tue May 13 21:17:06 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 21:17:06 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v3] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Same optimization of previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/56ba43fc..007d65cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From duke at openjdk.org Tue May 13 21:24:08 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 13 May 2025 21:24:08 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v4] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Update names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/007d65cc..5ad26a14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From jiangli at openjdk.org Tue May 13 21:33:03 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 13 May 2025 21:33:03 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk Message-ID: Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description: jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. ------------- Commit messages: - Skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk. Changes: https://git.openjdk.org/jdk/pull/25220/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25220&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356904 Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25220/head:pull/25220 PR: https://git.openjdk.org/jdk/pull/25220 From duke at openjdk.org Tue May 13 22:38:53 2025 From: duke at openjdk.org (Mohamed Issa) Date: Tue, 13 May 2025 22:38:53 GMT Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3] In-Reply-To: References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com> Message-ID: On Wed, 7 May 2025 09:25:30 GMT, Andrew Haley wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Add new set of cbrt micro-benchmarks > > src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 62: > >> 60: { >> 61: 0, 3220193280 >> 62: }; > > What is this constant? > > Its value is 0xbff0400000000000, which is -ve bit set, bias (top bit of exponent) clear, but one of the bits in the fraction is set. So its value is -0x1.04p+0. As well as the exponent it also sets the 1 bit, just below the 5 most significant bits of the fraction. I guess this in effect rounds up the value that is added in the final rounding. > > Is that right? The idea is mainly that the _EXP_MSK2_ constant operates on the input to match up with it's corresponding entries in the lookup tables: _rcp_table_, _cbrt_table_, and _D_table_. The key part starts with computing the difference (_r = x - x'_) shown in line 260 below. ```c++ __ subsd(xmm1, xmm3); Here _x_ is essentially the input fraction with all bits while _x'_ is the input fraction with _EXP_MSK2_ applied. This is then multiplied (_r = (x - x') * rcp_table(x')_) with the corresponding lookup table entry (_-1 / 1.b1 b2 b3 b4 b5 b6_ where _b6=1_) as shown in line 264 below. ```c++ __ mulsd(xmm1, xmm4); This value then gets used by subsequent steps that involve entries from _cbrt_table_ and _D_table_. It won't necessarily round the final result up though as those effects will depend on what the input is. However, the polynomial coefficients will have a bigger impact on rounding. For a summary of the approximations, please refer to the algorithm description comment block near the beginning of the source file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2087726049 From liach at openjdk.org Tue May 13 22:49:54 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 May 2025 22:49:54 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed an erroneous curly brace Let's address the other incorrect wrappings in a dedicated RFE. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2838287193 From liach at openjdk.org Wed May 14 00:05:55 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 14 May 2025 00:05:55 GMT Subject: Integrated: 8356694: Removed unused subclass audits in ObjectInput/OutputStream In-Reply-To: References: Message-ID: On Mon, 12 May 2025 02:18:05 GMT, Chen Liang wrote: > These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely. > > Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress This pull request has now been integrated. Changeset: a96424b2 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/a96424b24cc7734f04716a4459e5d5e0a5c73c0d Stats: 71 lines in 2 files changed: 0 ins; 69 del; 2 mod 8356694: Removed unused subclass audits in ObjectInput/OutputStream Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/25174 From dholmes at openjdk.org Wed May 14 00:34:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 May 2025 00:34:52 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com> Message-ID: On Tue, 13 May 2025 12:51:56 GMT, Thomas Stuefe wrote: >> You are right and I am confused. I always assumed that the primary function of jspawnhelper was to make vfork safe. Historically, that was the typical reason for an intermediate exec() to a helper - basically, you first exec() the helper as quickly as possible to get your own process memory. Then you do all the things you need to do in preparation for the final exec(), then exec again. >> >> I am surprised that this has worked with vfork() so flawlessly all this time. Maybe it didn't; maybe the libc's have all internally replaced vfork() with fork(), since fork() is fast enough nowadays. >> >> I actually don't understand why the jspawnhelper is even needed for posix_spawn, since all the things one does in jspawnhelper can be done also via posix_spawn process attributes. > > Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some implementations, vfork() is equivalent to fork()." AIX manpage says just "The vfork subroutine is supported as a compatibility interface for older Berkeley Software Distribution (BSD) system programs" which sounds to me its just an alias for fork(). MacOS has no vfork anymore. > > So maybe Solaris was the last platform with a true vfork. @tstuefe the helper was needed in part to enable a chdir between fork and exec - see this comment: https://bugs.openjdk.org/browse/JDK-5049299?focusedId=12148272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12148272 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2087830040 From jpai at openjdk.org Wed May 14 01:56:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 May 2025 01:56:00 GMT Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v8] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. >> >> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. >> >> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. >> >> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. >> >> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. >> >> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - update code comment in the test Thank you everyone for the reviews. tier1, tier2 and tier3 tests continue to pass with this change against latest master branch. I'll go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2878393844 From jpai at openjdk.org Wed May 14 01:56:01 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 May 2025 01:56:01 GMT Subject: Integrated: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset In-Reply-To: References: Message-ID: On Tue, 11 Mar 2025 14:23:02 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712. > > ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries. > > The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe. > > The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe. > > In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712. > > The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,... This pull request has now been integrated. Changeset: 2c4e8d21 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/2c4e8d211a030c85488e656a9a851d10dd0f9c11 Stats: 380 lines in 4 files changed: 323 ins; 14 del; 43 mod 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset 8355975: ZipFile uses incorrect Charset if another instance for the same ZIP file was constructed with a different Charset Co-authored-by: Eirik Bj?rsn?s Reviewed-by: eirbjo, lancea, redestad, alanb ------------- PR: https://git.openjdk.org/jdk/pull/23986 From xgong at openjdk.org Wed May 14 02:29:50 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 14 May 2025 02:29:50 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: <2os9gEZk7LXqHQkJ-FTv_8jsGrT9Cy0lAVDYLPgHst0=.6ea1f0d0-67a3-4a6a-9b47-5cb753c3d668@github.com> On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong wrote: > JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). > > Two key areas require improvement: > 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. > 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. > > This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. > > Main changes: > 1. Java-side API refactoring: > - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on > architectures like AArch64. > 2. C2 compiler IR refactoring: > - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. > 3. Backend changes: > - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. > > Performance: > The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: > > Benchmark Mode Cnt Unit SIZE Before After Gain > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.312 935.269 1.02 > GatherOperationsBenchmark.micr... Hi, could anyone please take a look at this PR? Thanks a lot in advance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2878450580 From duke at openjdk.org Wed May 14 02:44:14 2025 From: duke at openjdk.org (erifan) Date: Wed, 14 May 2025 02:44:14 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v6] In-Reply-To: References: Message-ID: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... erifan 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: - Refactor the JTReg tests for compare.xor(maskAll) Also made a bit change to support pattern `VectorMask.fromLong()`. - Merge branch 'master' into JDK-8354242 - Refactor code Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this optimization, making the code more modular. - Merge branch 'master' into JDK-8354242 - Update the jtreg test - Merge branch 'master' into JDK-8354242 - Addressed some review comments 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. 2. Improve code comments. - Merge branch 'master' into JDK-8354242 - Merge branch 'master' into JDK-8354242 - 8354242: VectorAPI: combine vector not operation with compare This patch optimizes the following patterns: For integer types: ``` (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) => (VectorMaskCmp src1 src2 ncond) (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) => (VectorMaskCmp src1 src2 ncond) ``` cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. For float and double types: ``` (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) ``` cond can be eq or ne. Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 testCompareLTMaskNotLong ops/s 856502.2695 12276.82851 1177671.815 496.723302 1.37 testCompareLTMaskNotShort ops/s 3325798.025 2412.702501 4711554.181 1779.302112 1.41 testCompareNEMaskNotByte ops/s 7910002.518 2771.82477 10245315.33 16321.93935 1.29 testCompareNEMaskNotDouble ops/s 863754.6022 523.140788 1179133.982 476.572178 1.36 testCompareNEMaskNotFloat ops/s 1723321.883 2598.484803 2358492.186 877.1401 1.36 testCompareNEMaskNotInt ops/s 1670288.841 751.774826 2354158.125 835.720163 1.4 testCompareNEMaskNotLong ops/s 836327.6835 410.525466 1178178.825 308.757932 1.4 testCompareNEMaskNotShort ops/s 3327815.841 1511.978763 4711379.136 2336.505531 1.41 testCompareUGEMaskNotByte ops/s 7906699.024 3200.936474 10253843.74 15067.59401 1.29 testCompareUGEMaskNotInt ops/s 1674003.923 3287.191727 2353340.666 951.381021 1.4 testCompareUGEMaskNotLong ops/s 852424.5562 8920.408939 1177943.609 389.6621 1.38 testCompareUGEMaskNotShort ops/s 3327255.858 1584.885143 4711622.355 1247.215277 1.41 testCompareUGTMaskNotByte ops/s 7909249.189 4435.283667 10245541.34 10993.34739 1.29 testCompareUGTMaskNotInt ops/s 1693713.433 20650.00213 2353153.787 1055.343846 1.38 testCompareUGTMaskNotLong ops/s 851022.3395 7079.065268 1177910.677 538.604598 1.38 testCompareUGTMaskNotShort ops/s 3327236.988 1616.886789 4711209.865 3098.494145 1.41 testCompareULEMaskNotByte ops/s 7909350.825 3251.262342 10261449.03 7273.831341 1.29 testCompareULEMaskNotInt ops/s 1672350.925 1545.304304 2353231.755 914.231193 1.4 testCompareULEMaskNotLong ops/s 853349.4765 9804.906913 1177967.254 435.044367 1.38 testCompareULEMaskNotShort ops/s 3325757.891 1555.062257 4712873.187 1650.986905 1.41 testCompareULTMaskNotByte ops/s 7912218.621 2633.477744 10242095.98 21921.39902 1.29 testCompareULTMaskNotInt ops/s 1673994.849 2672.507666 2353449.22 946.105757 1.4 testCompareULTMaskNotLong ops/s 849032.5868 10406.06689 1177586.047 506.541456 1.38 testCompareULTMaskNotShort ops/s 3328062.026 1892.991844 4713247.216 1855.983724 1.41 ``` With option `-XX:UseSVE=0`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 7895961.919 72712.90804 7746493.731 71481.92938 0.98 testCompareEQMaskNotDouble ops/s 789811.0455 384.493088 766473.7994 2216.581793 0.97 testCompareEQMaskNotFloat ops/s 1806305.818 638.010451 1819616.613 3295.38958 1 testCompareEQMaskNotInt ops/s 1815820.144 1225.336135 1849538.401 766.29902 1.01 testCompareEQMaskNotLong ops/s 807336.492 335.451807 792732.9483 277.954432 0.98 testCompareEQMaskNotShort ops/s 4818266.38 1927.862665 4668903.001 1922.782715 0.96 testCompareGEMaskNotByte ops/s 7818439.678 75374.97739 16498003.98 41440.49653 2.11 testCompareGEMaskNotInt ops/s 1815159.05 1090.912209 2372095.779 1664.397112 1.3 testCompareGEMaskNotLong ops/s 804324.5575 2301.686878 927919.8507 371.766719 1.15 testCompareGEMaskNotShort ops/s 4818966.563 2443.643652 5385561.038 29558.37423 1.11 testCompareGTMaskNotByte ops/s 7893406.157 82687.74264 16470663.2 22165.55812 2.08 testCompareGTMaskNotInt ops/s 1815316.812 915.894106 2370447.198 655.016338 1.3 testCompareGTMaskNotLong ops/s 807019.456 526.525482 928079.0541 330.582693 1.15 testCompareGTMaskNotShort ops/s 4820552.881 1684.247747 5355902.93 5893.2915 1.11 testCompareLEMaskNotByte ops/s 7816263.323 79560.0015 16473621.19 56688.99585 2.1 testCompareLEMaskNotInt ops/s 1814915.724 926.998625 2368790.306 932.594778 1.3 testCompareLEMaskNotLong ops/s 806483.9 935.718082 928110.9074 407.096695 1.15 testCompareLEMaskNotShort ops/s 4813660.241 6817.870509 5357107.852 10061.47975 1.11 testCompareLTMaskNotByte ops/s 7838948.962 69136.4504 16424405.96 24464.75469 2.09 testCompareLTMaskNotInt ops/s 1815056.833 1187.6453 2369892.187 1103.819634 1.3 testCompareLTMaskNotLong ops/s 806602.1804 287.923365 928346.4118 617.682824 1.15 testCompareLTMaskNotShort ops/s 4817940.643 2767.1509 5372537.84 15397.47169 1.11 testCompareNEMaskNotByte ops/s 9078493.798 4630.339307 16484348.42 18925.88346 1.81 testCompareNEMaskNotDouble ops/s 661769.6272 398.712981 926763.5839 1808.843788 1.4 testCompareNEMaskNotFloat ops/s 1570527.252 563.642144 2312425.678 1815.844846 1.47 testCompareNEMaskNotInt ops/s 1619146.58 626.793854 2369711.543 942.330478 1.46 testCompareNEMaskNotLong ops/s 680201.5381 2252.836482 927808.6147 414.917863 1.36 testCompareNEMaskNotShort ops/s 3763508.054 3622.560798 5367808.015 8591.466599 1.42 testCompareUGEMaskNotByte ops/s 7886373.129 75917.74675 16480928.93 27524.31005 2.08 testCompareUGEMaskNotInt ops/s 1815636.832 750.036241 2369683.015 901.609404 1.3 testCompareUGEMaskNotLong ops/s 806862.5826 287.819616 928001.4394 361.063837 1.15 testCompareUGEMaskNotShort ops/s 4820581.361 2098.537435 5375854.248 25619.40165 1.11 testCompareUGTMaskNotByte ops/s 7891591.465 96614.93542 16410405.93 15012.37096 2.07 testCompareUGTMaskNotInt ops/s 1814871.179 662.825588 2371325.903 1170.491164 1.3 testCompareUGTMaskNotLong ops/s 804013.7658 2240.534209 928062.2169 531.306897 1.15 testCompareUGTMaskNotShort ops/s 4818150.337 3051.717685 5381449.337 21212.34187 1.11 testCompareULEMaskNotByte ops/s 7831540.628 81306.67253 16495250.78 38682.19675 2.1 testCompareULEMaskNotInt ops/s 1814484.14 687.860656 2369265.075 940.609586 1.3 testCompareULEMaskNotLong ops/s 807780.5749 769.876816 927538.0732 1278.267724 1.14 testCompareULEMaskNotShort ops/s 4817437.42 5141.336541 5356183.359 7015.608124 1.11 testCompareULTMaskNotByte ops/s 7849078.225 56753.59764 16395975.27 34043.67295 2.08 testCompareULTMaskNotInt ops/s 1814328.226 2697.219111 2370700.47 1991.841988 1.3 testCompareULTMaskNotLong ops/s 807166.8197 253.061506 927926.2803 252.933462 1.14 testCompareULTMaskNotShort ops/s 4821098.216 1625.959044 5348980.243 4100.768121 1.1 ``` Benchmarks on AMD EPYC 9124 16-Core Processor: With option `-XX:UseAVX=3`: ``` Benchmark Unit Before Score Error After Score Error Uplift testCompareEQMaskNotByte ops/s 16607323.35 1233692.631 18381557.66 1163201.522 1.1 testCompareEQMaskNotDouble ops/s 2114285.245 58782.2534 2959946.353 43016.0445 1.39 testCompareEQMaskNotFloat ops/s 4480874.437 89975.29074 6960151.436 64799.143 1.55 testCompareEQMaskNotInt ops/s 4370906.91 51784.80889 6856955.043 313858.5504 1.56 testCompareEQMaskNotLong ops/s 2080065.895 26762.06732 2939142.143 67179.05314 1.41 testCompareEQMaskNotShort ops/s 7968282.563 210437.2781 12701214.56 473152.6407 1.59 testCompareGEMaskNotByte ops/s 18419141.89 473408.9451 19880059.68 321638.0397 1.07 testCompareGEMaskNotInt ops/s 4419015.62 77352.98633 7037639.227 151066.0383 1.59 testCompareGEMaskNotLong ops/s 2147982.48 49227.42782 3000275.928 39298.75344 1.39 testCompareGEMaskNotShort ops/s 8469039.613 17833.19707 12288229.49 244317.8812 1.45 testCompareGTMaskNotByte ops/s 18728997.5 468328.8358 20544730.05 392264.6466 1.09 testCompareGTMaskNotInt ops/s 4510009.705 78812.57357 7364629.942 70970.78473 1.63 testCompareGTMaskNotLong ops/s 2124104.969 40917.89257 2953536.279 35199.19687 1.39 testCompareGTMaskNotShort ops/s 8690557.621 311534.1159 12344017.51 457931.8741 1.42 testCompareLEMaskNotByte ops/s 17758400.53 478383.4945 19209183.26 1143297.241 1.08 testCompareLEMaskNotInt ops/s 4363664.862 43443.18063 7054093.064 78141.11476 1.61 testCompareLEMaskNotLong ops/s 2068632.213 29844.78023 2954766.412 50667.22502 1.42 testCompareLEMaskNotShort ops/s 8637608.548 183538.5511 12719010.27 473568.8825 1.47 testCompareLTMaskNotByte ops/s 14406138.95 423105.0163 17292417.96 371386.9689 1.2 testCompareLTMaskNotInt ops/s 4546707.266 131977.3144 7040483.394 213590.4657 1.54 testCompareLTMaskNotLong ops/s 2123277.356 47243.21499 2848720.442 58896.97045 1.34 testCompareLTMaskNotShort ops/s 7570169.363 649873.6295 11945383.75 988276.5955 1.57 testCompareNEMaskNotByte ops/s 18274529.55 683396.7384 19081938.8 1118739.778 1.04 testCompareNEMaskNotDouble ops/s 2112533.61 43295.50012 2912115.441 78189.51083 1.37 testCompareNEMaskNotFloat ops/s 4628683.814 93817.07362 6967208.729 145135.8544 1.5 testCompareNEMaskNotInt ops/s 4470900.214 75974.50842 7286913.662 116328.5277 1.62 testCompareNEMaskNotLong ops/s 2134091.061 46377.94061 2934667.477 81675.46021 1.37 testCompareNEMaskNotShort ops/s 8790384.287 396161.8599 13076858.35 286272.1155 1.48 testCompareUGEMaskNotByte ops/s 18009150.9 660803.8886 17551258.33 1667014.843 0.97 testCompareUGEMaskNotInt ops/s 4442928.74 83190.81019 6854088.277 329008.8901 1.54 testCompareUGEMaskNotLong ops/s 2088357.736 71696.24791 2973202.26 63278.78974 1.42 testCompareUGEMaskNotShort ops/s 8348624.02 116562.7876 12832250.78 546869.3006 1.53 testCompareUGTMaskNotByte ops/s 17871101.25 800199.6321 19902619.81 214003.3262 1.11 testCompareUGTMaskNotInt ops/s 4088304.421 137797.9723 7135454.33 124553.651 1.74 testCompareUGTMaskNotLong ops/s 2070610.42 19881.82182 2991536.365 36260.60767 1.44 testCompareUGTMaskNotShort ops/s 8637099.341 155822.1608 12756579.77 186068.199 1.47 testCompareULEMaskNotByte ops/s 17940901.36 1258029.364 18932484.94 694554.6305 1.05 testCompareULEMaskNotInt ops/s 4369177.511 74982.31936 6392773.082 550171.2266 1.46 testCompareULEMaskNotLong ops/s 2135905.761 43693.63178 2877579.631 41651.56289 1.34 testCompareULEMaskNotShort ops/s 8607710.544 132655.1676 12446370.04 441718.3035 1.44 testCompareULTMaskNotByte ops/s 17409912.23 1033204.537 20607479.99 362000.5056 1.18 testCompareULTMaskNotInt ops/s 4386455.9 119192.1635 6920123.264 186158.2845 1.57 testCompareULTMaskNotLong ops/s 2064995.149 38622.2734 2988343.589 39037.90006 1.44 testCompareULTMaskNotShort ops/s 8642182.752 230919.2442 13029582.09 437101.4923 1.5 ``` The small amount of performance degradation is due to test fluctuations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24674/files - new: https://git.openjdk.org/jdk/pull/24674/files/001fac0f..f2f71e34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=04-05 Stats: 20102 lines in 755 files changed: 11515 ins; 4932 del; 3655 mod Patch: https://git.openjdk.org/jdk/pull/24674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674 PR: https://git.openjdk.org/jdk/pull/24674 From duke at openjdk.org Wed May 14 02:44:14 2025 From: duke at openjdk.org (erifan) Date: Wed, 14 May 2025 02:44:14 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 09:37:22 GMT, erifan wrote: >> Yes, converting `VectorMask.fromLong(SPECIES, -1L)` to `MaskAll()` would be better, and that will benefit AArch64 as well, since `MaskAll()` is much more cheaper than `fromLong()` on AArch64. We can add such a transformation with another PR. > > Ok, I'll extend the test to xor(maskAll(true) in the next commit, thanks! Done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2087927027 From duke at openjdk.org Wed May 14 02:44:16 2025 From: duke at openjdk.org (erifan) Date: Wed, 14 May 2025 02:44:16 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v5] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:13:23 GMT, Jatin Bhateja wrote: >> erifan 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: >> >> - Refactor code >> >> Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this >> optimization, making the code more modular. >> - Merge branch 'master' into JDK-8354242 >> - Update the jtreg test >> - Merge branch 'master' into JDK-8354242 >> - Addressed some review comments >> >> 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. >> 2. Improve code comments. >> - Merge branch 'master' into JDK-8354242 >> - Merge branch 'master' into JDK-8354242 >> - 8354242: VectorAPI: combine vector not operation with compare >> >> This patch optimizes the following patterns: >> For integer types: >> ``` >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> ``` >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the >> negative comparison of cond. >> >> For float and double types: >> ``` >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> ``` >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: >> With option `-XX:UseSVE=2`: >> ``` >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.156... > > test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 40: > >> 38: @Fork(jvmArgs = { "--add-modules=jdk.incubator.vector" }) >> 39: public class MaskCompareNotBenchmark { >> 40: private static final int ARRAYLEN = 4096; > > ARRAYLEN should be configurable @Param. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2087927310 From iklam at openjdk.org Wed May 14 06:16:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 06:16:15 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/3cc2cb3a..cd7a5a6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06-07 Stats: 748 lines in 9 files changed: 369 ins; 327 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From ihse at openjdk.org Wed May 14 06:35:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 06:35:56 GMT Subject: RFR: 8356644: Update encoding declaration to UTF-8 In-Reply-To: References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> Message-ID: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com> On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov wrote: >> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. >> >> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper. >> >> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8. > > src/demo/share/jfc/CodePointIM/README.html line 5: > >> 3: >> 4: README - CodePointIM >> 5: > > I believe this line is equivalent to simple `` which is widely used in java.desktop's docs. That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088152886 From ihse at openjdk.org Wed May 14 06:35:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 06:35:57 GMT Subject: Integrated: 8356644: Update encoding declaration to UTF-8 In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> Message-ID: <1uf8Qu09x2byR-S1kMvt4zMdBu_BKZHCvx13v-uaxYc=.9e974fe5-0125-4001-99f6-acbba3ea517d@github.com> On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper. > > I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8. This pull request has now been integrated. Changeset: dd251599 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/dd2515993bf76f424e4c56d529ae1541f55e3f8b Stats: 794 lines in 53 files changed: 2 ins; 9 del; 783 mod 8356644: Update encoding declaration to UTF-8 Reviewed-by: prr, naoto ------------- PR: https://git.openjdk.org/jdk/pull/25148 From ihse at openjdk.org Wed May 14 06:46:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 06:46:57 GMT Subject: Integrated: 8354968: Replace unicode sequences in comment text with UTF-8 characters In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 14:42:37 GMT, Magnus Ihse Bursie wrote: > As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them. > > 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? > > I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code. > > There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start. This pull request has now been integrated. Changeset: a3e094e1 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a3e094e1a0716adf52dad6407eb7877682beec92 Stats: 158 lines in 153 files changed: 0 ins; 2 del; 156 mod 8354968: Replace unicode sequences in comment text with UTF-8 characters Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/24727 From serb at openjdk.org Wed May 14 06:52:55 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 14 May 2025 06:52:55 GMT Subject: RFR: 8356644: Update encoding declaration to UTF-8 In-Reply-To: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com> References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com> <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com> Message-ID: On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie wrote: > That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this. FIled: https://bugs.openjdk.org/browse/JDK-8356937 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088181402 From jpai at openjdk.org Wed May 14 06:53:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 May 2025 06:53:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com> Message-ID: On Tue, 13 May 2025 16:37:12 GMT, Alan Bateman wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208: >> >>> 206: boolean shouldCreate = isTrue(env, "create"); >>> 207: if (shouldCreate && forceReadOnly) { >>> 208: throw new IllegalArgumentException( >> >> Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`. >> >> So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API. > > I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise. I'll file an issue for this today, shortly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2088183284 From alanb at openjdk.org Wed May 14 07:46:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 May 2025 07:46:50 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com> Message-ID: On Wed, 14 May 2025 06:51:14 GMT, Jaikiran Pai wrote: >> I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise. > > I'll file an issue for this today, shortly. I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2088288990 From rgiulietti at openjdk.org Wed May 14 08:04:00 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 08:04:00 GMT Subject: Integrated: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 15:04:12 GMT, Raffaello Giulietti wrote: > See the JBS bug for some details. This pull request has now been integrated. Changeset: d1032d71 Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/d1032d71bfd50ebc4b328ce9b0cc81cbb80554b0 Stats: 1041 lines in 1 file changed: 352 ins; 461 del; 228 mod 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/22737 From tpushkin at openjdk.org Wed May 14 08:18:39 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 14 May 2025 08:18:39 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Make supertype obstruction check easier to understand ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/915987b0..a3b7dd96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=10-11 Stats: 16 lines in 3 files changed: 3 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From shade at openjdk.org Wed May 14 09:08:59 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 May 2025 09:08:59 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v5] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote: >> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. >> >> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. >> >> I am very open to bike-shedding about the actual message :) >> >> Additional testing: >> - [x] Ad-hoc experiments with breaking jspawnhelper >> - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` > > 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 nine additional commits since the last revision: > > - Print error decoding > - Touch up formatting message > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Add bug ID > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Pull message into a field > - Test cases > - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions > - Initial fix > > Good spawnhelper failure message > > Trying tests > > Print helper message on all IOExceptions > > Final Testing is green, I am integrating. Thanks all! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2879409486 From shade at openjdk.org Wed May 14 09:09:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 May 2025 09:09:00 GMT Subject: Integrated: 8352533: Report useful IOExceptions when jspawnhelper fails In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 10:00:26 GMT, Aleksey Shipilev wrote: > When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong. > > It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. > > I am very open to bike-shedding about the actual message :) > > Additional testing: > - [x] Ad-hoc experiments with breaking jspawnhelper > - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder` This pull request has now been integrated. Changeset: 5c73dfc2 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/5c73dfc28cbd6801ac85c6685fb8c77aad3ab0b7 Stats: 100 lines in 3 files changed: 74 ins; 0 del; 26 mod 8352533: Report useful IOExceptions when jspawnhelper fails Reviewed-by: simonis, rriggs, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/24149 From schernyshev at openjdk.org Wed May 14 09:31:53 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 14 May 2025 09:31:53 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk wrote: > I wrote 2 comments. but cold not post them. They are in "pending" state. Not sure why. Should the comments be first reviewed by {Committers|Reviewers}? please go to `Files changed` panel and press Review Changes -> Submit review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2879489346 From schernyshev at openjdk.org Wed May 14 09:44:52 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 14 May 2025 09:44:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com> On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Refactor container runtime version code test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166: > 164: return null; > 165: } > 166: } Do you still need this method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2088524580 From tpushkin at openjdk.org Wed May 14 10:14:54 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 14 May 2025 10:14:54 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Sorry, had to pause working on this for some time because of other stuff. I believe I have addressed all the existing comments now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2879622953 From rgiulietti at openjdk.org Wed May 14 10:18:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 10:18:54 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v2] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:03:42 GMT, Johannes Graham wrote: >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. > > Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: > > fix code tag in javadoc src/java.base/share/classes/java/math/BigDecimal.java line 1408: > 1406: } > 1407: > 1408: return valueOf(s, fmt.getScale(), fmt.getPrecision()); I'd prefer to have a `getExp()` rather than `getScale()` in `FormattedFPDecimal`. src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 100: > 98: // Keep digits to left of decimal, plus leave a > 99: // trailing zero > 100: (expR + 1) + 1; I think that the comment is sufficiently clear to be able to replace `(expR + 1) + 1` with `expR + 2` src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 106: > 104: // there is a single digit > 105: 2; > 106: }; Can we have a chain of `if`s or conditional expressions (`? :`)? src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 129: > 127: > 128: return fd; > 129: } Please be consistent with the usage of `final` for local vars in the context of a single method. src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 147: > 145: public int getScale() { > 146: return -e; > 147: } I'd prefer to have a `getExp()` rather than `getScale()` here, as everything here uses an exponent rather than a scale. Then there's no need for the JavaDoc comment. test/jdk/java/math/BigDecimal/ValueOfDouble.java line 41: > 39: > 40: public class ValueOfDouble { > 41: private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long Suggestion: private static final String DIGITS = "1234567000003456789"; // Enough digits to fill a long ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088553632 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088558336 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088561193 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088593281 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088563587 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088576102 From aph at openjdk.org Wed May 14 10:47:40 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 May 2025 10:47:40 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6] In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Andrew Haley has updated the pull request incrementally with three additional commits since the last revision: - AvoidUnalignedAccesses - Temp - The cherry on the cake ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25147/files - new: https://git.openjdk.org/jdk/pull/25147/files/87eadb40..e5771988 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=04-05 Stats: 20 lines in 1 file changed: 17 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From markus at headcrashing.eu Wed May 14 10:48:30 2025 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 14 May 2025 12:48:30 +0200 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> Message-ID: Many of the modified classes derive from a common super class and share one needed common change (which is one of the points which are easy to see once you see all of those classes in a single PR, but hard to explain in plaint-text pre-PR mailing list threads), so at least those need to be discussed *together*. But to spare JBS and PRs, I can open the PR with just the first set of changes, and once we agree that this set is fine, I can push the next commit *in the same PR*. Otherwise we would need endless JBS, mailing list threads, and PRs, just to fixe a dozen internal code lines. Having said that, does the current state of this thread count as "reached common agreement to file a PR" or do I still have to wait until more people chime in? -Markus Am 13.05.2025 um 15:10 schrieb Roger Riggs: > Hi Markus, > > A main point was to avoid trying to do everything at once. > The PR comments become hard to follow and intermingled and it takes > longer to get agreement because of the thrash in the PR. > > Roger > > On 5/13/25 5:05 AM, Markus KARG wrote: >> Thank you, Roger. >> >> Actually the method helps in the "toString()" variants, too, as in >> some places we could *get rid* of "toString()" (which is more work >> than "just" a buffer due to the added compression complexity). >> >> In fact, I already took the time to rewrite *all* of them while >> waiting for the approval of this list posting. In *all* cases *less* >> buffering / copying is needed, and *less* "toString()" conversion >> (which is a copy under the hood) is needed. So if I would be allowed >> to show the code as a PR, it would be much easier to explain and >> discuss. >> >> A PR is the best place to discuss "how to code would change". In the >> worst case, let's drop it if we see that it is actually a bad thing. >> >> -Markus >> >> >> Am 12.05.2025 um 20:18 schrieb Roger Riggs: >>> Hi Markus, >>> >>> On the surface, its looks constructive. >>> I suspect that many of these cases will turn into discussions about >>> the right/best/better way to buffer the characters. >>> The getChars method only helps when extracting to a char array, many >>> of the current implementations create strings as the intermediary. >>> The advantage of the 1 character at a time technique is not needing >>> a (separated allocated) buffer. >>> Consider taking a few at a time before launching into the whole set. >>> >>> $.02, Roger >>> >>> On 5/11/25 2:45 AM, Markus KARG wrote: >>>> Dear Core Libs Team, >>>> >>>> I am hereby requesting comments on JDK-8356679. >>>> >>>> I would like to invest some time and set up a PR implementing Chen >>>> Liangs's proposal laid out in >>>> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, >>>> the text of that JBS is copied below. According to the Developer's >>>> Guide I do need to get broad agreement BEFORE filing a PR. >>>> Therefore, I kindly ask everybody to briefly show consent, so I may >>>> file a PR. >>>> >>>> Thanks >>>> -Markus >>>> >>>> >>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >>>> >>>> Recently OpenJDK adopted the new method CharSequence::getChars(int, >>>> int, char[], int) for inclusion in Java 25. As a bulk reader >>>> method, it allows potentially improved efficiency over the >>>> previously available char-by-char reader method >>>> CharSequence::charAt(int). >>>> >>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing list >>>> to use the new method within the internal source code of OpenJDK >>>> for the implementation of Appendables (see >>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >>>> The idea behind this is that the implementations might be more >>>> efficient then. >>>> >>>> A quick analysis of the OpenJDK source code identified (at least) >>>> the following classes which could potentially run more efficient >>>> when using CharSequence::getChars internally, thanks to bulk >>>> reading and / or prevention of internal copies / toString() >>>> conversions: >>>> * java.io.Writer >>>> * java.io.StringWriter >>>> * java.io.PrintWriter >>>> * java.io.BufferedWriter >>>> * java.io.CharArrayWriter >>>> * java.io.FileWriter >>>> * java.io.OutputStreamWriter >>>> * sun.nio.cs.StreamEncoder >>>> * java.io.PrintStream >>>> * java.nio.CharBuffer >>>> >>>> In the sense of "eat your own dog food", it makes sense to >>>> implement Chen's idea in (at least) those classes. Possibly more >>>> classes could get identified when taking a deeper look. Besides the >>>> potential efficiency improvements, it would be a good show case for >>>> the usage of the new API. >>>> >>>> The risk of this change should be low, as test coverage exists, and >>>> as the intended changes are solely internal to the implementation. >>>> No API will get changed. In some cases the JavaDocs will get >>>> slightly adapted where it currently exposes the actual >>>> implementation (to not lie in future). >>>> >>> > From jwaters at openjdk.org Wed May 14 11:31:59 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 14 May 2025 11:31:59 GMT Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > build.log on release configuration: > > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=] > 3560 | static const UINT _VKS_ALT_MASK = 0x04; > | ^~~~~~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs] > 1361 | } SUBTABLE, *PSUBTABLE; > | ^~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs] > 1588 | } HEAD, *PHEAD; > | ^~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs] > 1595 | } ENTRY, *PENTRY; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/... Keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2879835298 From jpai at openjdk.org Wed May 14 13:08:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 May 2025 13:08:58 GMT Subject: RFR: 8341184: Clean up the interaction between the launcher native code and the LauncherHelper [v16] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 09:46:29 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. >> >> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code. >> >> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - ... and 6 more: https://git.openjdk.org/jdk/compare/e410af00...d1ac5174 I will move this to draft for now and will come back to this in the next release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21256#issuecomment-2880182423 From syan at openjdk.org Wed May 14 13:24:54 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 14 May 2025 13:24:54 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk In-Reply-To: References: Message-ID: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com> On Tue, 13 May 2025 21:28:00 GMT, Jiangli Zhou wrote: > Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description: > > jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. Changes requested by syan (Committer). test/lib-test/TEST.ROOT line 31: > 29: keys=randomness > 30: > 31: # Minimum jtreg version Shoule we update the copyright year for file TestNativeProcessBuilder.java ------------- PR Review: https://git.openjdk.org/jdk/pull/25220#pullrequestreview-2840171571 PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2088931079 From duke at openjdk.org Wed May 14 13:35:54 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 14 May 2025 13:35:54 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 09:55:35 GMT, Raffaello Giulietti wrote: >> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: >> >> fix code tag in javadoc > > src/java.base/share/classes/java/math/BigDecimal.java line 1408: > >> 1406: } >> 1407: >> 1408: return valueOf(s, fmt.getScale(), fmt.getPrecision()); > > I'd prefer to have a `getExp()` rather than `getScale()` in `FormattedFPDecimal`. I was looking for a way clearly distinguish?it from getExponentRounded. Will go with getExp, since it makes more sense in the scope of that class. > test/jdk/java/math/BigDecimal/ValueOfDouble.java line 41: > >> 39: >> 40: public class ValueOfDouble { >> 41: private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long > > Suggestion: > > private static final String DIGITS = "1234567000003456789"; // Enough digits to fill a long What is the significance of the positioning of the zeros? I wasn't really attaching any significance to the digit values other than making it easy to count how many there were. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088959379 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088963691 From duke at openjdk.org Wed May 14 13:47:11 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 14 May 2025 13:47:11 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v3] In-Reply-To: References: Message-ID: > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: address review suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25173/files - new: https://git.openjdk.org/jdk/pull/25173/files/ba8d3933..e7d2d14b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=01-02 Stats: 26 lines in 3 files changed: 2 ins; 12 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173 PR: https://git.openjdk.org/jdk/pull/25173 From pminborg at openjdk.org Wed May 14 13:48:54 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 14 May 2025 13:48:54 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Wed, 14 May 2025 10:47:40 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with three additional commits since the last revision: > > - AvoidUnalignedAccesses > - Temp > - The cherry on the cake The changes in `SegmentBulkOperations` look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2880312073 From roger.riggs at oracle.com Wed May 14 13:57:29 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 14 May 2025 09:57:29 -0400 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> Message-ID: <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> Hi Markus, Starting out with the common case is a good idea for the first PR. I much prefer a PR with a single goal and that comes to a conclusion and does not add new features or changes after the PR is submitted. I tend to lose interest in PRs with lots of churn, it means I have to re-review the bulk of it when there is a change and may wait days to let it settle down before coming back to it. I tend to think the PR was not really ready to be reviewed if simple issues and corrections have to be made frequently. Do your own checking for typos and copyrights and simple refactoring before opening the PR. Quality before quantity or speed. I'm fine with separate Jira issues that clearly delineate a specific scope and goal. The title of this issue (8356679) doesn't identify the real goal. It seems to be to improve performance or memory usage, not just to use a new API. These are my personal opinions about contributions and process. Regards, Roger On 5/14/25 6:48 AM, Markus KARG wrote: > Many of the modified classes derive from a common super class and > share one needed common change (which is one of the points which are > easy to see once you see all of those classes in a single PR, but hard > to explain in plaint-text pre-PR mailing list threads), so at least > those need to be discussed *together*. But to spare JBS and PRs, I can > open the PR with just the first set of changes, and once we agree that > this set is fine, I can push the next commit *in the same PR*. > Otherwise we would need endless JBS, mailing list threads, and PRs, > just to fixe a dozen internal code lines. > > Having said that, does the current state of this thread count as > "reached common agreement to file a PR" or do I still have to wait > until more people chime in? > > -Markus > > > Am 13.05.2025 um 15:10 schrieb Roger Riggs: >> Hi Markus, >> >> A main point was to avoid trying to do everything at once. >> The PR comments become hard to follow and intermingled and it takes >> longer to get agreement because of the thrash in the PR. >> >> Roger >> >> On 5/13/25 5:05 AM, Markus KARG wrote: >>> Thank you, Roger. >>> >>> Actually the method helps in the "toString()" variants, too, as in >>> some places we could *get rid* of "toString()" (which is more work >>> than "just" a buffer due to the added compression complexity). >>> >>> In fact, I already took the time to rewrite *all* of them while >>> waiting for the approval of this list posting. In *all* cases *less* >>> buffering / copying is needed, and *less* "toString()" conversion >>> (which is a copy under the hood) is needed. So if I would be allowed >>> to show the code as a PR, it would be much easier to explain and >>> discuss. >>> >>> A PR is the best place to discuss "how to code would change". In the >>> worst case, let's drop it if we see that it is actually a bad thing. >>> >>> -Markus >>> >>> >>> Am 12.05.2025 um 20:18 schrieb Roger Riggs: >>>> Hi Markus, >>>> >>>> On the surface, its looks constructive. >>>> I suspect that many of these cases will turn into discussions about >>>> the right/best/better way to buffer the characters. >>>> The getChars method only helps when extracting to a char array, >>>> many of the current implementations create strings as the >>>> intermediary. The advantage of the 1 character at a time technique >>>> is not needing a (separated allocated) buffer. >>>> Consider taking a few at a time before launching into the whole set. >>>> >>>> $.02, Roger >>>> >>>> On 5/11/25 2:45 AM, Markus KARG wrote: >>>>> Dear Core Libs Team, >>>>> >>>>> I am hereby requesting comments on JDK-8356679. >>>>> >>>>> I would like to invest some time and set up a PR implementing Chen >>>>> Liangs's proposal laid out in >>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, >>>>> the text of that JBS is copied below. According to the Developer's >>>>> Guide I do need to get broad agreement BEFORE filing a PR. >>>>> Therefore, I kindly ask everybody to briefly show consent, so I >>>>> may file a PR. >>>>> >>>>> Thanks >>>>> -Markus >>>>> >>>>> >>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >>>>> >>>>> Recently OpenJDK adopted the new method >>>>> CharSequence::getChars(int, int, char[], int) for inclusion in >>>>> Java 25. As a bulk reader method, it allows potentially improved >>>>> efficiency over the previously available char-by-char reader >>>>> method CharSequence::charAt(int). >>>>> >>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing >>>>> list to use the new method within the internal source code of >>>>> OpenJDK for the implementation of Appendables (see >>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >>>>> The idea behind this is that the implementations might be more >>>>> efficient then. >>>>> >>>>> A quick analysis of the OpenJDK source code identified (at least) >>>>> the following classes which could potentially run more efficient >>>>> when using CharSequence::getChars internally, thanks to bulk >>>>> reading and / or prevention of internal copies / toString() >>>>> conversions: >>>>> * java.io.Writer >>>>> * java.io.StringWriter >>>>> * java.io.PrintWriter >>>>> * java.io.BufferedWriter >>>>> * java.io.CharArrayWriter >>>>> * java.io.FileWriter >>>>> * java.io.OutputStreamWriter >>>>> * sun.nio.cs.StreamEncoder >>>>> * java.io.PrintStream >>>>> * java.nio.CharBuffer >>>>> >>>>> In the sense of "eat your own dog food", it makes sense to >>>>> implement Chen's idea in (at least) those classes. Possibly more >>>>> classes could get identified when taking a deeper look. Besides >>>>> the potential efficiency improvements, it would be a good show >>>>> case for the usage of the new API. >>>>> >>>>> The risk of this change should be low, as test coverage exists, >>>>> and as the intended changes are solely internal to the >>>>> implementation. No API will get changed. In some cases the >>>>> JavaDocs will get slightly adapted where it currently exposes the >>>>> actual implementation (to not lie in future). >>>>> >>>> >> From ihse at openjdk.org Wed May 14 14:28:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 14:28:10 GMT Subject: RFR: 8356977: UTF-8 cleanups Message-ID: I found a few other places in the code that can be cleaned up after the conversion to UTF-8. ------------- Commit messages: - Replace uncessary unicode characters with ASCII in instructions, and fix typo - Seems like typos in the comments - Fix unicode sequences in comments (previously missed) Changes: https://git.openjdk.org/jdk/pull/25228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356977 Stats: 21 lines in 16 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/25228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228 PR: https://git.openjdk.org/jdk/pull/25228 From ihse at openjdk.org Wed May 14 14:34:37 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 14:34:37 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 Message-ID: After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. ------------- Commit messages: - 8356978: Convert unicode sequences in Java source code to UTF-8 Changes: https://git.openjdk.org/jdk/pull/25229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356978 Stats: 9616 lines in 90 files changed: 0 ins; 0 del; 9616 mod Patch: https://git.openjdk.org/jdk/pull/25229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229 PR: https://git.openjdk.org/jdk/pull/25229 From duke at openjdk.org Wed May 14 14:39:37 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 14 May 2025 14:39:37 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v4] In-Reply-To: References: Message-ID: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com> > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. Johannes Graham has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java Align better with spec Co-authored-by: Raffaello Giulietti - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java Better alignment with spec Co-authored-by: Raffaello Giulietti - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java Add another final Co-authored-by: Raffaello Giulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25173/files - new: https://git.openjdk.org/jdk/pull/25173/files/e7d2d14b..0cc32fc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173 PR: https://git.openjdk.org/jdk/pull/25173 From rgiulietti at openjdk.org Wed May 14 14:39:37 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 14:39:37 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v3] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 13:47:11 GMT, Johannes Graham wrote: >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. > > Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: > > address review suggestions src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 94: > 92: final int targetPrec = > 93: // No extra trailing digit needed > 94: (-3 <= expR && expR <= -1) ? 1 Suggestion: (-3 <= expR && expR < 0) ? 1 Fully equivalent, but matches the `Double.toString(double)` spec more closely. src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 97: > 95: > 96: // Keep digits to left of decimal, plus leave a trailing zero > 97: : (0 <= expR && expR <= 6) ? expR + 2 : Suggestion: : (0 <= expR && expR < 7) ? expR + 2 : Fully equivalent, but matches the `Double.toString(double)` spec more closely. src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 109: > 107: if (prec < targetPrec) { > 108: // Add zeros needed to reach target precision > 109: int addZeros = targetPrec - prec; Suggestion: final int addZeros = targetPrec - prec; Just to be consistent with the usage of `final` in this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089090546 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089090644 PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089092505 From rgiulietti at openjdk.org Wed May 14 14:39:38 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 14:39:38 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 13:33:32 GMT, Johannes Graham wrote: >> test/jdk/java/math/BigDecimal/ValueOfDouble.java line 41: >> >>> 39: >>> 40: public class ValueOfDouble { >>> 41: private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long >> >> Suggestion: >> >> private static final String DIGITS = "1234567000003456789"; // Enough digits to fill a long > > What is the significance of the positioning of the zeros? I wasn't really attaching any significance to the digit values other than making it easy to count how many there were. The zeros would combine with the exponent to miss some values for precision. I had also experimented with using 100...001, but it made for messier code. Going with your suggestion to start with. The test copies a prefix, so we want to make sure that trailing zeros are processed correctly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089099807 From rgiulietti at openjdk.org Wed May 14 14:43:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 14:43:54 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) In-Reply-To: <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com> References: <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com> Message-ID: On Sun, 11 May 2025 16:32:02 GMT, Johannes Graham wrote: >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. > > On Aarch64 M4: > > Benchmark Mode Cnt Score Error Units > + BigDecimals.testValueOfWithDouble avgt 15 9.913 ? 0.080 ns/op > - BigDecimals.testValueOfWithDoubleString avgt 15 65.846 ? 0.801 ns/op Thanks @j3graham for this nice enhancement! Before approval, let's give another 24 hours for people around the globe to have a chance for further comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2880505868 From mhaessig at openjdk.org Wed May 14 14:45:04 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 14 May 2025 14:45:04 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" Message-ID: When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. ------------- Commit messages: - Add output to ease debugging, if the test fails - Fix test by searching for the beginning of a word Changes: https://git.openjdk.org/jdk/pull/25230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356974 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25230/head:pull/25230 PR: https://git.openjdk.org/jdk/pull/25230 From ihse at openjdk.org Wed May 14 15:16:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 15:16:18 GMT Subject: RFR: 8356980: Better handling of non-breaking space Message-ID: Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. I have checked: * U+00A0 NO-BREAK SPACE (NBSP) * U+202F NARROW NO-BREAK SPACE (NNBSP) * U+2007 FIGURE SPACE * U+2060 WORD JOINER In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. ------------- Commit messages: - Use sequences for valid nbsp usage - Remove mistaken nbsp Changes: https://git.openjdk.org/jdk/pull/25234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356980 Stats: 36 lines in 8 files changed: 0 ins; 2 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/25234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25234/head:pull/25234 PR: https://git.openjdk.org/jdk/pull/25234 From adinn at openjdk.org Wed May 14 15:38:58 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 14 May 2025 15:38:58 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Wed, 14 May 2025 10:47:40 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with three additional commits since the last revision: > > - AvoidUnalignedAccesses > - Temp > - The cherry on the cake Looks good to me. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25147#pullrequestreview-2840674777 From jiangli at openjdk.org Wed May 14 15:44:08 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 15:44:08 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: References: Message-ID: > Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description: > > jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25220/files - new: https://git.openjdk.org/jdk/pull/25220/files/838a20d5..6037babe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25220&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25220&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25220/head:pull/25220 PR: https://git.openjdk.org/jdk/pull/25220 From jiangli at openjdk.org Wed May 14 15:44:08 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 15:44:08 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com> References: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com> Message-ID: On Wed, 14 May 2025 13:21:37 GMT, SendaoYan wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. > > test/lib-test/TEST.ROOT line 31: > >> 29: keys=randomness >> 30: >> 31: # Minimum jtreg version > > Shoule we update the copyright year for file TestNativeProcessBuilder.java Done. Thanks for reminding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2089240624 From kvn at openjdk.org Wed May 14 16:08:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 May 2025 16:08:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: Message-ID: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> On Wed, 14 May 2025 06:16:15 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 Few comments. src/hotspot/share/cds/cds_globals.hpp line 123: > 121: product(ccstr, AOTCacheOutput, nullptr, \ > 122: "Write AOT cache into this file (overrides AOTCache when " \ > 123: "writing)") \ This looks not complete description. And "override AOTCache .." is confusing. src/hotspot/share/cds/metaspaceShared.cpp line 1150: > 1148: print_java_launcher(&ss); > 1149: const char* cmd = ss.freeze(); > 1150: tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration); I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think. Was this discussed? src/hotspot/share/runtime/arguments.cpp line 3060: > 3058: } > 3059: > 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { I don't like that we pollute `Arguments` code with AOT specific flags processing. Can we move this into `CDSConfig`? Both these 2 new methods. But I will agree if you want to keep it here. It is not critical. src/java.base/share/man/java.md line 4141: > 4139: mode should be used only as a "fail-fast" debugging aid to check if your command-line > 4140: options are compatible with the AOT cache. An alternative is to run your application with > 4141: `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not. `-Xlog:aot` test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166: > 164: "-XX:-AOTClassLinking", > 165: "-XX:AOTConfiguration=" + aotConfigFile, > 166: "-Xlog:cds=debug", `-Xlog:aot` I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2840679467 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089234532 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089261456 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089267274 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089274796 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089279429 From acobbs at openjdk.org Wed May 14 16:18:58 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 14 May 2025 16:18:58 GMT Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque In-Reply-To: References: Message-ID: <63QyI-7zKduRVpGwW8IODYko4U9EzuTtFOYeeJEAo5E=.1c242db8-e2af-4e6a-9793-168ece2f7c4a@github.com> On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote: > Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API. > > Please review this PR which adds the following two new methods to `ArrayDeque`: > * `public E get(int index)` > * `public E set(int index, E element)` Closing this PR for now while we decide what is the best approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25189#issuecomment-2880816417 From acobbs at openjdk.org Wed May 14 16:18:58 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 14 May 2025 16:18:58 GMT Subject: Withdrawn: 8143850: Add indexed get() and set() methods to ArrayDeque In-Reply-To: References: Message-ID: On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote: > Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API. > > Please review this PR which adds the following two new methods to `ArrayDeque`: > * `public E get(int index)` > * `public E set(int index, E element)` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25189 From henryjen at openjdk.org Wed May 14 16:42:56 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 14 May 2025 16:42:56 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v6] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:41:07 GMT, Lance Andersen wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore Validator access level > > test/jdk/tools/jar/ValidatorTest.java line 145: > >> 143: var template = out.toByteArray(); >> 144: // ISO_8859_1 to keep the 8-bit value >> 145: var s = new String(template, StandardCharsets.ISO_8859_1); > > Ok, but the zip is being created using UTF_8.... UTF-8 messed up the index, we don't want any conversion to happen. Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2089340789 From lancea at openjdk.org Wed May 14 16:46:00 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 14 May 2025 16:46:00 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. Thank. you David for your work here A few comments on a quick pass in addition to those from Alan & Jai The copyright will also need to be updated src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 95: > 93: > 94: private static final Set DEFAULT_PERMISSIONS = > 95: PosixFilePermissions.fromString("rwxrwxrwx"); I am not convinced this needs to be changed as it becomes a personal style preference src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 113: > 111: final ZipCoder zc; > 112: private final ZipPath rootdir; > 113: // Start readOnly (safe mode) and maybe reset at end of initialization. maybe -> may be test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 219: > 217: assertFalse(fs.isReadOnly()); > 218: if (!"Default version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) { > 219: throw new RuntimeException("unexpected file content"); could also consider fail("unexpected file content"); test/jdk/jdk/nio/zipfs/TestPosix.java line 434: > 432: createTestZipFile(ZIP_FILE, ENV_DEFAULT).close(); > 433: // check entries on zipfs with default options > 434: try (FileSystem zip = FileSystems.newFileSystem(ZIP_FILE, ENV_DEFAULT)) { This tests an empty Map and should still be a test as it is different from ENV_READ_ONLY ------------- PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2840686940 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089239326 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089240538 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089339910 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089344316 From prr at openjdk.org Wed May 14 17:01:55 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 14 May 2025 17:01:55 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie wrote: > Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. > > I have checked: > * U+00A0 NO-BREAK SPACE (NBSP) > * U+202F NARROW NO-BREAK SPACE (NNBSP) > * U+2007 FIGURE SPACE > * U+2060 WORD JOINER > > In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39: > 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte : > 38: > 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0: So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991 But I think you know that .. since you commented on the PR The fix was done by @justin-curtis-lu and reviewed by @naotoj so I think I'd like to get their opinion on this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089371921 From smarks at openjdk.org Wed May 14 17:03:56 2025 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 14 May 2025 17:03:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> Message-ID: <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> On Tue, 13 May 2025 15:33:39 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: "stream" -> "reader" src/java.base/share/classes/java/io/Reader.java line 403: > 401: char[] str = new char[TRANSFER_BUFFER_SIZE]; > 402: int n; > 403: while ((n = read(str)) != -1) { I'd suggest changing this call to `this.read(str, 0, str.length)` so that all concrete implementations in this class call only the abstract three-arg read() method. Using `this` is optional but it emphasizes that this is a self-call. (It's done in only one other place in this file already.) Also, the variable name `str` is confusing since this isn't a String. I'd suggest `cbuf` instead as that name is used for char arrays elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089375168 From lancea at openjdk.org Wed May 14 17:06:55 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 14 May 2025 17:06:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 10:16:33 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment based on current behaviour. test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 207: > 205: Map.of("create", true, "accessMode", "badValue"))); > 206: } > 207: You could simplify the above tests using a DataProvider similar to @DataProvider(name = "zipfsMap") protected Object[][] zipfsMap() { return new Object[][]{ {Map.of(), NoSuchFileException.class}, {Map.of("accessMode", "readOnly"), NoSuchFileException.class}, {Map.of("accessMode", "readWrite"), NoSuchFileException.class}, {Map.of("create", true, "accessMode", "readOnly"), IllegalArgumentException.class}, {Map.of("create", true, "accessMode", "badValue"), IllegalArgumentException.class}, }; @Test(dataProvider = "zipfsMap?) public void testZipFSCreationException(Map env, Class exception) throws Exception { assertThrows(exception, () -> FileSystems.newFileSystem(noSuchZip, env)); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089378491 From jlu at openjdk.org Wed May 14 17:21:54 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 14 May 2025 17:21:54 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: Message-ID: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> On Wed, 14 May 2025 16:59:23 GMT, Phil Race wrote: >> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. >> >> I have checked: >> * U+00A0 NO-BREAK SPACE (NBSP) >> * U+202F NARROW NO-BREAK SPACE (NNBSP) >> * U+2007 FIGURE SPACE >> * U+2060 WORD JOINER >> >> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39: > >> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte : >> 38: >> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0: > > So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991 > But I think you know that .. since you commented on the PR > > The fix was done by @justin-curtis-lu and reviewed by > @naotoj so I think I'd like to get their opinion on this For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089399946 From duke at openjdk.org Wed May 14 17:27:57 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 17:27:57 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> Message-ID: <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> On Wed, 14 May 2025 17:01:30 GMT, Stuart Marks wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: "stream" -> "reader" > > src/java.base/share/classes/java/io/Reader.java line 403: > >> 401: char[] str = new char[TRANSFER_BUFFER_SIZE]; >> 402: int n; >> 403: while ((n = read(str)) != -1) { > > I'd suggest changing this call to `this.read(str, 0, str.length)` so that all concrete implementations in this class call only the abstract three-arg read() method. Using `this` is optional but it emphasizes that this is a self-call. (It's done in only one other place in this file already.) > > Also, the variable name `str` is confusing since this isn't a String. I'd suggest `cbuf` instead as that name is used for char arrays elsewhere. I think `read(str)` is to be preferred over `read(str, 0, str.length()` as it allows implementations to provide optimized implementations. What the caller of the new methods wants to achieve is getting everything in the best possible way, which is, in the most optimized way. If we go around high-level methods, we should have a good reason for! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089409620 From lancea at openjdk.org Wed May 14 17:29:52 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 14 May 2025 17:29:52 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v6] In-Reply-To: References: Message-ID: <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com> On Wed, 14 May 2025 16:39:54 GMT, Henry Jen wrote: > UTF-8 messed up the index, we don't want any conversion to happen. Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header Without looking into this in finer detail I am not sure what the issue is and is why the other tests typically use the actual offset to modify. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2089413418 From naoto at openjdk.org Wed May 14 17:36:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 May 2025 17:36:51 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Wed, 14 May 2025 17:18:35 GMT, Justin Lu wrote: >> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39: >> >>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte : >>> 38: >>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0: >> >> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991 >> But I think you know that .. since you commented on the PR >> >> The fix was done by @justin-curtis-lu and reviewed by >> @naotoj so I think I'd like to get their opinion on this > > For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.) I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089424644 From naoto at openjdk.org Wed May 14 17:45:02 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 May 2025 17:45:02 GMT Subject: RFR: 8356420: Provide examples on wrapping System.in [v6] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed an erroneous curly brace Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2881038072 From naoto at openjdk.org Wed May 14 17:45:03 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 May 2025 17:45:03 GMT Subject: Integrated: 8356420: Provide examples on wrapping System.in In-Reply-To: References: Message-ID: <7aaSHikGxSrfTrOoJIKavSuV-UgqpfKvrmlKUQSmuVU=.2d692e84-3434-449a-90c6-3287ba343351@github.com> On Fri, 9 May 2025 19:53:24 GMT, Naoto Sato wrote: > With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help. This pull request has now been integrated. Changeset: 7c8e273f Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/7c8e273fde644bbc2def4a1134a82b8eb8d33d53 Stats: 41 lines in 4 files changed: 32 ins; 0 del; 9 mod 8356420: Provide examples on wrapping System.in Reviewed-by: liach, smarks, alanb, bpb, iris ------------- PR: https://git.openjdk.org/jdk/pull/25155 From bpb at openjdk.org Wed May 14 17:45:41 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 May 2025 17:45:41 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v20] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Change readAllCharsAsString as suggested; move test to proper location ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/98387b0d..3cbaede9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=18-19 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From duke at openjdk.org Wed May 14 17:45:41 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 17:45:41 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> Message-ID: <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> On Tue, 13 May 2025 15:33:39 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: "stream" -> "reader" src/java.base/share/classes/java/io/Reader.java line 205: > 203: public String readAllAsString() throws IOException { > 204: ensureOpen(); > 205: String result = cs.toString().substring(next); For sake of efficiency can we please *first* limit and copy *last*? If `cs` refers to a huge object and `next` is just few bytes before `length()`, it makes no sense to copy the huge memory block just to return one or two characters finally. ? `result = cs.subSequence(next, cs.length()).toString()`? src/java.base/share/classes/java/io/Reader.java line 500: > 498: * @since 25 > 499: */ > 500: public String readAllAsString() throws IOException { Still thinking that declaring `CharSequence` instead of `String` would be beneficial. In case a `Reader` implementation reads from I/O, the implementation could so return a block of native memory without turning it into a Java `String` just for sake of fulfilling the API. In case of servers for example, the information often is passed-through from one I/O source to another I/O sink *unmodified*, which means, the `String` then is turned into *a new* native memory block again; double native memory used *plus* on-heap memory used, without any benefit. Can we please provide I/O APIs which do *not* enforce duplicate copying to and from `String` in such scenarios? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089421861 PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089436642 From bpb at openjdk.org Wed May 14 17:45:41 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 May 2025 17:45:41 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> Message-ID: <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com> On Wed, 14 May 2025 17:25:00 GMT, Markus KARG wrote: >> src/java.base/share/classes/java/io/Reader.java line 403: >> >>> 401: char[] str = new char[TRANSFER_BUFFER_SIZE]; >>> 402: int n; >>> 403: while ((n = read(str)) != -1) { >> >> I'd suggest changing this call to `this.read(str, 0, str.length)` so that all concrete implementations in this class call only the abstract three-arg read() method. Using `this` is optional but it emphasizes that this is a self-call. (It's done in only one other place in this file already.) >> >> Also, the variable name `str` is confusing since this isn't a String. I'd suggest `cbuf` instead as that name is used for char arrays elsewhere. > > I think `read(str)` is to be preferred over `read(str, 0, str.length()` as it allows implementations to provide optimized implementations. What the caller of the new methods wants to achieve is getting everything in the best possible way, which is, in the most optimized way. If we go around high-level methods, we should have a good reason for! All other self-calls to a `read` method are to the three-arg abstract method: $ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v public | grep -v * nread = this.read(cbuf, off, rem); nread = read(cbuf, 0, len); if (read(cb, 0, 1) == -1) return read(cbuf, 0, cbuf.length); while ((nread = read(cbuf, 0, cbuf.length)) != -1) { int nc = read(skipBuffer, 0, (int)Math.min(r, nn)); while ((nRead = read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089432945 From bpb at openjdk.org Wed May 14 17:45:41 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 May 2025 17:45:41 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com> Message-ID: <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com> On Wed, 14 May 2025 17:39:05 GMT, Brian Burkhalter wrote: >> I think `read(str)` is to be preferred over `read(str, 0, str.length()` as it allows implementations to provide optimized implementations. What the caller of the new methods wants to achieve is getting everything in the best possible way, which is, in the most optimized way. If we go around high-level methods, we should have a good reason for! > > All other self-calls to a `read` method are to the three-arg abstract method: > > $ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v public | grep -v * > nread = this.read(cbuf, off, rem); > nread = read(cbuf, 0, len); > if (read(cb, 0, 1) == -1) > return read(cbuf, 0, cbuf.length); > while ((nread = read(cbuf, 0, cbuf.length)) != -1) { > int nc = read(skipBuffer, 0, (int)Math.min(r, nn)); > while ((nRead = read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0) { > so that all concrete implementations in this class call only the abstract three-arg read() method Done in 3cbaede and also `str` -> `cbuf`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089436030 From smarks at openjdk.org Wed May 14 17:45:41 2025 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 14 May 2025 17:45:41 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com> <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com> Message-ID: On Wed, 14 May 2025 17:40:53 GMT, Brian Burkhalter wrote: >> All other self-calls to a `read` method are to the three-arg abstract method: >> >> $ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v public | grep -v * >> nread = this.read(cbuf, off, rem); >> nread = read(cbuf, 0, len); >> if (read(cb, 0, 1) == -1) >> return read(cbuf, 0, cbuf.length); >> while ((nread = read(cbuf, 0, cbuf.length)) != -1) { >> int nc = read(skipBuffer, 0, (int)Math.min(r, nn)); >> while ((nRead = read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0) { > >> so that all concrete implementations in this class call only the abstract three-arg read() method > > Done in 3cbaede and also `str` -> `cbuf`. The code should use the three-arg read() call in order to limit self-calls, in order to avoid the fragile base class problem. At some point we might want to add implSpec tags to specify this. See my previous comments relate to this topic: https://github.com/openjdk/jdk/pull/24728#issuecomment-2848332415 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089439008 From duke at openjdk.org Wed May 14 17:47:36 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 14 May 2025 17:47:36 GMT Subject: RFR: 8077587: BigInteger Roots [v14] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Use type long for bitLength instead of int ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/32a5e5ec..c8e1b815 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=12-13 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From duke at openjdk.org Wed May 14 17:59:55 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 17:59:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com> <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com> Message-ID: On Wed, 14 May 2025 17:42:33 GMT, Stuart Marks wrote: >>> so that all concrete implementations in this class call only the abstract three-arg read() method >> >> Done in 3cbaede and also `str` -> `cbuf`. > > The code should use the three-arg read() call in order to limit self-calls, in order to avoid the fragile base class problem. At some point we might want to add implSpec tags to specify this. See my previous comments relate to this topic: > > https://github.com/openjdk/jdk/pull/24728#issuecomment-2848332415 I know that comment already, but IMHO we can simply use `@implSpec` to unambiguously make clear that this method invokes `read(char[])` to allow optimized implementations, and it *might* in turn invoke `read(char[],int,int)`, but this is *not guaranteed*. A class is only fragile as long as we do not *document* what it will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089456975 From liach at openjdk.org Wed May 14 17:59:57 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 14 May 2025 17:59:57 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 17:41:12 GMT, Markus KARG wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: "stream" -> "reader" > > src/java.base/share/classes/java/io/Reader.java line 500: > >> 498: * @since 25 >> 499: */ >> 500: public String readAllAsString() throws IOException { > > Still thinking that declaring `CharSequence` instead of `String` would be beneficial. In case a `Reader` implementation reads from I/O, the implementation could so return a block of native memory without turning it into a Java `String` just for sake of fulfilling the API. In case of servers for example, the information often is passed-through from one I/O source to another I/O sink *unmodified*, which means, the `String` then is turned into *a new* native memory block again; double native memory used *plus* on-heap memory used, without any benefit. Can we please provide I/O APIs which do *not* enforce duplicate copying to and from `String` in such scenarios? ? I think this is just a convenience API. A CharSequence-returning API would suit better if it supports arbitrarily long lengths (assuming such a length is in the range of int), while String has implementation limits on lengths and is allowed to fail for this API with OOME. If we make this a CharSequence-returning API that fails with OOME for String implementation limits, I don't think this will please anybody. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089454629 From duke at openjdk.org Wed May 14 17:59:57 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 17:59:57 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 17:56:04 GMT, Markus KARG wrote: >> I think this is just a convenience API. A CharSequence-returning API would suit better if it supports arbitrarily long lengths (assuming such a length is in the range of int), while String has implementation limits on lengths and is allowed to fail for this API with OOME. If we make this a CharSequence-returning API that fails with OOME for String implementation limits, I don't think this will please anybody. > > As being a server developer for decades I need to say that I would love to have this not for convenience but for the performance reasons explained above, and that `int` length is perfect to speed up 99,9% of all cases. So we should not forget about `CharSequence` hastily. BTW, it will not fail with OOME, but it should throw IOE in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089464567 From duke at openjdk.org Wed May 14 17:59:57 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 17:59:57 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 17:52:37 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/io/Reader.java line 500: >> >>> 498: * @since 25 >>> 499: */ >>> 500: public String readAllAsString() throws IOException { >> >> Still thinking that declaring `CharSequence` instead of `String` would be beneficial. In case a `Reader` implementation reads from I/O, the implementation could so return a block of native memory without turning it into a Java `String` just for sake of fulfilling the API. In case of servers for example, the information often is passed-through from one I/O source to another I/O sink *unmodified*, which means, the `String` then is turned into *a new* native memory block again; double native memory used *plus* on-heap memory used, without any benefit. Can we please provide I/O APIs which do *not* enforce duplicate copying to and from `String` in such scenarios? ? > > I think this is just a convenience API. A CharSequence-returning API would suit better if it supports arbitrarily long lengths (assuming such a length is in the range of int), while String has implementation limits on lengths and is allowed to fail for this API with OOME. If we make this a CharSequence-returning API that fails with OOME for String implementation limits, I don't think this will please anybody. As being a server developer for decades I need to say that I would love to have this not for convenience but for the performance reasons explained above, and that `int` length is perfect to speed up 99,9% of all cases. So we should not forget about `CharSequence` hastily. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089463475 From duke at openjdk.org Wed May 14 17:59:58 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 17:59:58 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 17:56:44 GMT, Markus KARG wrote: >> As being a server developer for decades I need to say that I would love to have this not for convenience but for the performance reasons explained above, and that `int` length is perfect to speed up 99,9% of all cases. So we should not forget about `CharSequence` hastily. > > BTW, it will not fail with OOME, but it should throw IOE in that case. BTW, it will *already* throw OOME as-is, *because* it returns a `String` even if the Reader is attached to an infinite source. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089465925 From rgiulietti at openjdk.org Wed May 14 18:02:55 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 18:02:55 GMT Subject: RFR: 8077587: BigInteger Roots [v6] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:23:16 GMT, fabioromano1 wrote: >> @fabioromano1 Is [this proof](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf) still relevant? > > @rgiulietti No, the proof of the recurrence used is the one by Zimmermann linked in the code. @fabioromano1 I guess this work will be the basis for a future work on `BigDecimal` _n_-th root? Otherwise, there needs to be some evidence for useful use cases of _general interest_ to justify adding _n_-th root to `BigInteger`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881083945 From jlahoda at openjdk.org Wed May 14 18:04:59 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 May 2025 18:04:59 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 19:36:11 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' into JDK-8354556 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang > - additional changes from Archie > - removing dead code > - integrating code from Archie > - fixing bugs, removing dead code > - additional documentation changes and bug fixes > - documentation and adding alias to lint categories > - Merge branch 'master' into JDK-8354556 > - addressing review comment > - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5673: > 5671: void checkRequiresIdentity(JCTree tree, Lint lint) { > 5672: switch (tree) { > 5673: case JCClassDecl classDecl : { Nit - unless fall-through is needed (it does not seem to be, on the first sight), I would suggest to use `->` instead of `:`, esp. given the cases use blocks anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089472496 From duke at openjdk.org Wed May 14 18:07:08 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 14 May 2025 18:07:08 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Revert "Use type long for bitLength instead of int" This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/c8e1b815..aeef24cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=13-14 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From bpb at openjdk.org Wed May 14 18:12:09 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 May 2025 18:12:09 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v21] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <0fljO6e1_nDkzQ1pvry3e3BFquvkZZoSCbiPwmA9Mb0=.8b4a100e-4e8e-486a-8d81-9bd5c37909bd@github.com> > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Improve readAllAsString method of Reader returned by Reader.of ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/3cbaede9..04d89963 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=19-20 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From bpb at openjdk.org Wed May 14 18:12:10 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 May 2025 18:12:10 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: <3Lc4lOREDpDdcpbi31DimAW5jVTbTrT5SGst7I9ghOE=.800191fe-0613-4109-99e9-a8df32773534@github.com> On Wed, 14 May 2025 17:32:50 GMT, Markus KARG wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: "stream" -> "reader" > > src/java.base/share/classes/java/io/Reader.java line 205: > >> 203: public String readAllAsString() throws IOException { >> 204: ensureOpen(); >> 205: String result = cs.toString().substring(next); > > For sake of efficiency can we please *first* limit and copy *last*? If `cs` refers to a huge object and `next` is just few bytes before `length()`, it makes no sense to copy the huge memory block just to return one or two characters finally. ? > > `result = cs.subSequence(next, cs.length()).toString()`? Improved in [04d8996](https://github.com/openjdk/jdk/pull/24728/commits/04d899631eb87dc475c7daf08f0ae7af47bcdac1). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089483768 From duke at openjdk.org Wed May 14 18:12:10 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Wed, 14 May 2025 18:12:10 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 17:57:36 GMT, Markus KARG wrote: >> BTW, it will not fail with OOME, but it should throw IOE in that case. > > BTW, it will *already* throw OOME as-is, *because* it returns a `String` even if the Reader is attached to an infinite source. Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089484458 From abarashev at openjdk.org Wed May 14 18:16:13 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 14 May 2025 18:16:13 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v4] In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> Message-ID: > When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3 > > X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Make the test run on TLSv1.3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25016/files - new: https://git.openjdk.org/jdk/pull/25016/files/5c137c14..451e1efd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=02-03 Stats: 25 lines in 2 files changed: 5 ins; 7 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016 PR: https://git.openjdk.org/jdk/pull/25016 From bpb at openjdk.org Wed May 14 18:16:22 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 May 2025 18:16:22 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Replace getChars in previous commit with subSequence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/04d89963..1afba6e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=20-21 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From duke at openjdk.org Wed May 14 18:16:58 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 14 May 2025 18:16:58 GMT Subject: RFR: 8077587: BigInteger Roots [v6] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 17:59:59 GMT, Raffaello Giulietti wrote: > I guess this work will be the basis for a future work on `BigDecimal` _n_-th root? @rgiulietti Yes, it is. Some use cases could be primality testing, like AKS, where part of the algorithm detect composite numbers by checking whether an integer is an exact power or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881114961 From rriggs at openjdk.org Wed May 14 18:18:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 May 2025 18:18:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 18:09:26 GMT, Johannes D?bler wrote: >> BTW, it will *already* throw OOME as-is, *because* it returns a `String` even if the Reader is attached to an infinite source. > > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... The result should be immutable and CharSequence does not provide that. The contents should not be modifiable after the method returns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089494174 From rgiulietti at openjdk.org Wed May 14 18:29:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 18:29:54 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: References: Message-ID: <7dIq2RDp9DpQMkuQAGKFJAFt9DFQbhsoCuMyoZVA_eI=.24fb96f4-54d4-4493-9078-75ffebf88cc4@github.com> On Wed, 14 May 2025 18:07:08 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Use type long for bitLength instead of int" > > This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c. I doubt that the AKS primality test is of any practical relevance, although it's a _great_ theoretical achievement. So if you plan to add a _n_-th root to `BigDecimal` in a followup PR, then please keep going on this one. Otherwise, I can't see a strong need for a `BigInteger` _n_-th root in the platform, although I might be wrong. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881151030 From duke at openjdk.org Wed May 14 18:34:58 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 14 May 2025 18:34:58 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: <7dIq2RDp9DpQMkuQAGKFJAFt9DFQbhsoCuMyoZVA_eI=.24fb96f4-54d4-4493-9078-75ffebf88cc4@github.com> References: <7dIq2RDp9DpQMkuQAGKFJAFt9DFQbhsoCuMyoZVA_eI=.24fb96f4-54d4-4493-9078-75ffebf88cc4@github.com> Message-ID: On Wed, 14 May 2025 18:27:28 GMT, Raffaello Giulietti wrote: > I doubt that the AKS primality test is of any practical relevance, although it's a _great_ theoretical achievement. Yes, indeed it was just an example, but the exact power detection can be used also as a test apart from the entire AKS algorithm. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881163762 From rgiulietti at openjdk.org Wed May 14 18:51:53 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 May 2025 18:51:53 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:07:08 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Use type long for bitLength instead of int" > > This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c. The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now. I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26. In other words, take your time ;-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881206033 From duke at openjdk.org Wed May 14 18:54:52 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 14 May 2025 18:54:52 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:48:50 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Use type long for bitLength instead of int" >> >> This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c. > > The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now. > > I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26. > > In other words, take your time ;-) @rgiulietti Anyway, I think the code has reached a stable version, so it is ready for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881215213 From jlahoda at openjdk.org Wed May 14 19:18:03 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 May 2025 19:18:03 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 19:36:11 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge branch 'master' into JDK-8354556 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang > - additional changes from Archie > - removing dead code > - integrating code from Archie > - fixing bugs, removing dead code > - additional documentation changes and bug fixes > - documentation and adding alias to lint categories > - Merge branch 'master' into JDK-8354556 > - addressing review comment > - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29 javac changes look overall good to me. One question and some comments for consideration inline. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2673: > 2671: result = check(tree, capturedRes, KindSelector.VAL, resultInfo); > 2672: } > 2673: if (env.info.lint.isEnabled(LintCategory.IDENTITY)) { This is the only place where there's a check whether the lint is enabled before the call to `checkRequiresIdentity`. Is there a reason for that? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5671: > 5669: } > 5670: > 5671: void checkRequiresIdentity(JCTree tree, Lint lint) { For consideration: as far as I can see, we have a sharp(er) type when we call `checkRequiresIdentity`, but we give up the type, and re-instante it here using the pattern matching switch. I wonder if it would be more elegant (and hopefully not really too much longer) if the `checkRequiresIdentity` method would have multiple overloads, with the sharp(er) types, like `JCClassDecl`/`JCVariableDecl`, etc. Or is there a reason to given up the sharp(er) type and re-create it using the switch? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5823: > 5821: SymbolMetadata sm = t.tsym.getMetadata(); > 5822: if (sm != null && !t.getTypeArguments().isEmpty()) { > 5823: for (Attribute.TypeCompound ta: sm.getTypeAttributes().stream() The code here, and the code in `checkIfTypeParamsRequiresIdentity` look similar a lot (although they manipulate `List` and `List`, of course. I wonder if there's a chance to share the code, at least partially. ------------- PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2841121286 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089504249 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089507277 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089509893 From duke at openjdk.org Wed May 14 19:40:56 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 19:40:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 18:16:08 GMT, Roger Riggs wrote: >> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... > > The result should be immutable and CharSequence does not provide that. > The contents should not be modifiable after the method returns. A "pure" `CharSequence` *is* immutable, as it does not have mutation methods. Also, why *should* the result be immutable? If someone wants to return a `StringBuilder` for example (for whatever intent), why shouldn't he allowed to do that? In fact, it would be beneficial to return a `StringBuilder` in some cases, as it is more efficient to modify (*iff* wanted) than a `String`. It should be up to the caller and the provider of the implementation to decide about immutability; this is not the API's discretion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089617093 From acobbs at openjdk.org Wed May 14 19:43:20 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 14 May 2025 19:43:20 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops Message-ID: Please review this small performance tweak `ArrayDeque`. `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. ------------- Commit messages: - Use Arrays.fill() instead of for() loops to null out array elements. Changes: https://git.openjdk.org/jdk/pull/25237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356993 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25237/head:pull/25237 PR: https://git.openjdk.org/jdk/pull/25237 From duke at openjdk.org Wed May 14 19:44:00 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 19:44:00 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 19:37:57 GMT, Markus KARG wrote: >> The result should be immutable and CharSequence does not provide that. >> The contents should not be modifiable after the method returns. > > A "pure" `CharSequence` *is* immutable, as it does not have mutation methods. Also, why *should* the result be immutable? If someone wants to return a `StringBuilder` for example (for whatever intent), why shouldn't he allowed to do that? In fact, it would be beneficial to return a `StringBuilder` in some cases, as it is more efficient to modify (*iff* wanted) than a `String`. It should be up to the caller and the provider of the implementation to decide about immutability; this is not the API's discretion. > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is *inefficient* to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089622286 From duke at openjdk.org Wed May 14 19:47:56 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 19:47:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Replace getChars in previous commit with subSequence src/java.base/share/classes/java/io/Reader.java line 206: > 204: ensureOpen(); > 205: int len = cs.length(); > 206: String result = cs.subSequence(next, len).toString(); Are you sure that `subSequence` is more efficient that `getChars`? Otherwise I do not see why replacing it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089627037 From liach at openjdk.org Wed May 14 20:03:55 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 14 May 2025 20:03:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 14 May 2025 19:44:56 GMT, Markus KARG wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354724: Replace getChars in previous commit with subSequence > > src/java.base/share/classes/java/io/Reader.java line 206: > >> 204: ensureOpen(); >> 205: int len = cs.length(); >> 206: String result = cs.subSequence(next, len).toString(); > > Are you sure that `subSequence` is more efficient that `getChars`? Otherwise I do not see why replacing it. I think this may be a good way to reduce redundant allocation if the CharSequence's subsequence is a simple view (frequently the case for user ones) or a String (for StringBuilder, String) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089650320 From amaembo at gmail.com Wed May 14 20:15:00 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 14 May 2025 22:15:00 +0200 Subject: Finding max or min of exactly two objects In-Reply-To: <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com> References: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com> Message-ID: Hello! On Tue, May 13, 2025 at 5:53?PM Brian Goetz wrote: > Let's separate these. I think the first two have a good claim to be in > Comparator; I think the latter two probably live better in Comparable, > which feels like a separate conversation (and maybe less important?) > (And also, there's some overlap with some yet-uncollapsed stuff going on > in Valhalla that I'd like to steer clear of.) Agreed, let's concentrate on default methods first and see how it goes. I've created https://bugs.openjdk.org/browse/JDK-8356995 I've also found an older (declined) feature request https://bugs.openjdk.org/browse/JDK-4254492 With best regards, Tagir Valeev From bpb at openjdk.org Wed May 14 20:16:56 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 May 2025 20:16:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 14 May 2025 20:00:50 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/io/Reader.java line 206: >> >>> 204: ensureOpen(); >>> 205: int len = cs.length(); >>> 206: String result = cs.subSequence(next, len).toString(); >> >> Are you sure that `subSequence` is more efficient that `getChars`? Otherwise I do not see why replacing it. > > I think this may be a good way to reduce redundant allocation if the CharSequence's subsequence is a simple view (frequently the case for user ones) or a String (for StringBuilder, String) I have no idea whether `subSequence` is more performant than `getChars` but it seems cleaner. In any case, at this point we are concerned primarily with the APIs getting into JDK 25. We can improve performance after that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089672134 From rriggs at openjdk.org Wed May 14 20:24:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 May 2025 20:24:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 19:41:30 GMT, Markus KARG wrote: >> A "pure" `CharSequence` *is* immutable, as it does not have mutation methods. Also, why *should* the result be immutable? If someone wants to return a `StringBuilder` for example (for whatever intent), why shouldn't he allowed to do that? In fact, it would be beneficial to return a `StringBuilder` in some cases, as it is more efficient to modify (*iff* wanted) than a `String`. It should be up to the caller and the provider of the implementation to decide about immutability; this is not the API's discretion. > >> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... > > The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is *inefficient* to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing. There's nothing in the CharSequence interface that requires or indicates that the implementation is or is not immutable. Interfaces only have loosely defined contracts, only the signature of the methods, the caller can not hold any more expectations about the semantics of the implementation. Immutable objects are among the best tools we have for making reliable software. The caller does not have to have a deep knowledge of the implementation to get predictable results. For most OpenJDK public APIs, the objective is to have well defined semantics with no implementation surprises. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089682813 From duke at openjdk.org Wed May 14 20:34:58 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 20:34:58 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> On Wed, 14 May 2025 20:14:21 GMT, Brian Burkhalter wrote: >> I think this may be a good way to reduce redundant allocation if the CharSequence's subsequence is a simple view (frequently the case for user ones) or a String (for StringBuilder, String) > > I have no idea whether `subSequence` is more performant than `getChars` but it seems cleaner. In any case, at this point we are concerned primarily with the APIs getting into JDK 25. We can improve performance after that. Actually I am working on exact these optimizations right now and do not like the idea that I have to file another JBS and PR just for a single code line. As `subSequence` typically *does* a copy (to not hold the original full text in-memory for the lifetime of a possibly single-character sub sequence), unless otherwise proven, `getChars` will always be faster. Having said that, I need to say, that I do not second what Chen said. In reality I have never seen "simple views", in particular not "frequently". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089697023 From duke at openjdk.org Wed May 14 20:39:55 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 20:39:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> Message-ID: On Wed, 14 May 2025 20:32:38 GMT, Markus KARG wrote: >> I have no idea whether `subSequence` is more performant than `getChars` but it seems cleaner. In any case, at this point we are concerned primarily with the APIs getting into JDK 25. We can improve performance after that. > > Actually I am working on exact these optimizations right now and do not like the idea that I have to file another JBS and PR just for a single code line. As `subSequence` typically *does* a copy (to not hold the original full text in-memory for the lifetime of a possibly single-character sub sequence), unless otherwise proven, `getChars` will always be faster. Having said that, I need to say, that I do not second what Chen said. In reality I have never seen "simple views", in particular not "frequently". BTW, paraphrasing Stuart here: "We want to reduce self-calls". `subSequence` is a self-call, *as we do not know* how it behaves in the actual implementation. For `getChars` we can be sure that it has no overridable side effects. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089706589 From duke at openjdk.org Wed May 14 20:54:57 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 20:54:57 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 20:22:02 GMT, Roger Riggs wrote: >>> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... >> >> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is *inefficient* to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing. > > There's nothing in the CharSequence interface that requires or indicates that the implementation is or is not immutable. Interfaces only have loosely defined contracts, only the signature of the methods, the caller can not hold any more expectations about the semantics of the implementation. > Immutable objects are among the best tools we have for making reliable software. > The caller does not have to have a deep knowledge of the implementation to get predictable results. > For most OpenJDK public APIs, the objective is to have well defined semantics with no implementation surprises. Granted in general, but again, it is not the job of *this particular API* to forbid mutation *iff* the caller and / or producer of the object see a good reason for that. This completely overdesigns the target of *this* API. Callers are no dummies, they can read JavaDocs, and they can `.toString()` on their own *iff* needed. Actually, in 30 years I never heard a Java Programmer say "oops, I did not expect `CharSequence` to mutate". With that attitude we could simply deprecate `CharSequence` for removal...! BTW, how will you mutate a `CharSequence` if you don't know its actual implementation? Try-and-error? ? Or with "immutable" do you mean *constant* objects (i. e. *the producer* will not modify it after creation)? It is a *good* thing not to know what you have in your hands, as you *do not start* making assumptions (like "it is immutable"). I am fond of getting *away* from those restricted semantics, towards a cleaner "do not assume, do not trust" policy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089733821 From rriggs at openjdk.org Wed May 14 21:01:05 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 May 2025 21:01:05 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> Message-ID: <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> On Wed, 14 May 2025 20:36:47 GMT, Markus KARG wrote: >> Actually I am working on exact these optimizations right now and do not like the idea that I have to file another JBS and PR just for a single code line. As `subSequence` typically *does* a copy (to not hold the original full text in-memory for the lifetime of a possibly single-character sub sequence), unless otherwise proven, `getChars` will always be faster. Having said that, I need to say, that I do not second what Chen said. In reality I have never seen "simple views", in particular not "frequently". > > BTW, paraphrasing Stuart here: "We want to reduce self-calls". `subSequence` is a self-call, *as we do not know* how it behaves in the actual implementation. For `getChars` we can be sure that it has no overridable side effects. Both `subSequence` and `getChars` are implemented by the CharSequence. They have the same level of trustworthiness about their implementation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089744639 From duke at openjdk.org Wed May 14 21:05:06 2025 From: duke at openjdk.org (Markus KARG) Date: Wed, 14 May 2025 21:05:06 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> Message-ID: <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com> On Wed, 14 May 2025 20:58:47 GMT, Roger Riggs wrote: >> BTW, paraphrasing Stuart here: "We want to reduce self-calls". `subSequence` is a self-call, *as we do not know* how it behaves in the actual implementation. For `getChars` we can be sure that it has no overridable side effects. > > Both `subSequence` and `getChars` are implemented by the CharSequence. > They have the same level of trustworthiness about their implementation. I meant that the implementation of `subSequence` *might or might not* perform copy (so we need to tell the javaDoc reader), while `getChar` *clearly* performs a copy as part of it design. So `subSequence` can be surprising as this discussion proofs, while `getChars` will not. That was Stuart's point with `read`, and that was your point with `CharSequence`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089749078 From peter.levart at gmail.com Wed May 14 21:07:16 2025 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 14 May 2025 23:07:16 +0200 Subject: Finding max or min of exactly two objects In-Reply-To: References: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com> <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com> Message-ID: <61697f55-1e38-487a-aa75-395acc36f6bd@gmail.com> Hi, I don't know if anyone still uses this, but some ideas are worth considering: https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/Ordering.java This is a Comparator implementation that also defines min and max. As generic methods. So if I have: Comparator cmp = ... var greatest = cmp.max("foo", "bar"); ...what type will greatest be? Regards, Peter On 5/14/25 10:15 PM, Tagir Valeev wrote: > Hello! > > On Tue, May 13, 2025 at 5:53?PM Brian Goetz wrote: >> Let's separate these. I think the first two have a good claim to be in >> Comparator; I think the latter two probably live better in Comparable, >> which feels like a separate conversation (and maybe less important?) >> (And also, there's some overlap with some yet-uncollapsed stuff going on >> in Valhalla that I'd like to steer clear of.) > Agreed, let's concentrate on default methods first and see how it > goes. I've created > https://bugs.openjdk.org/browse/JDK-8356995 > I've also found an older (declined) feature request > https://bugs.openjdk.org/browse/JDK-4254492 > > With best regards, > Tagir Valeev From iklam at openjdk.org Wed May 14 21:38:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 21:38:01 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: <13z4Kl2z8Qz0d0NKNyx7gqZiQmfzBFcM6duqVyy2v5A=.877f712a-ad71-4d85-92f6-28c678425d22@github.com> On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2841568752 From iklam at openjdk.org Wed May 14 21:38:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 21:38:02 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 10:12:11 GMT, Timofei Pushkin wrote: > Sorry, had to pause working on this for some time because of other stuff. > > I believe I have addressed all the existing comments now. Thanks for making the changes. Once this PR has 2 reviews and is final, I will run some tests in our test pipeline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2881638567 From smarks at openjdk.org Wed May 14 22:21:54 2025 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 14 May 2025 22:21:54 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com> Message-ID: On Wed, 14 May 2025 21:02:20 GMT, Markus KARG wrote: >> Both `subSequence` and `getChars` are implemented by the CharSequence. >> They have the same level of trustworthiness about their implementation. > > I meant that the implementation of `subSequence` *might or might not* perform copy (so we need to tell the javaDoc reader), while `getChar` *clearly* performs a copy as part of it design. So `subSequence` can be surprising as this discussion proofs, while `getChars` will not. That was Stuart's point with `read`, and that was your point with `CharSequence`. @mkarg Please don't invoke my name to try to buttress your arguments. The calls the Reader.of() instance makes on its backing CharSequence is a different kind of issue from what promises or guarantees the concrete methods of the Reader class makes to its subclasses. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089846252 From mseledtsov at openjdk.org Wed May 14 22:25:52 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 14 May 2025 22:25:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Refactor container runtime version code Overall change looks good to me. Looks like this method is not in use anymore (as also noted by [sercher]), consider deleting it: private static String getDockerVersionStr() { ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2881725481 From smarks at openjdk.org Wed May 14 22:34:53 2025 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 14 May 2025 22:34:53 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com> <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com> Message-ID: On Wed, 14 May 2025 17:53:48 GMT, Markus KARG wrote: >> The code should use the three-arg read() call in order to limit self-calls, in order to avoid the fragile base class problem. At some point we might want to add implSpec tags to specify this. See my previous comments relate to this topic: >> >> https://github.com/openjdk/jdk/pull/24728#issuecomment-2848332415 > > I know that comment already, but IMHO we can simply use `@implSpec` to unambiguously make clear that this method invokes `read(char[])` to allow optimized implementations, and it *might* in turn invoke `read(char[],int,int)`, but this is *not guaranteed*. A class is only fragile as long as we do not *document* what it will do. I doubt a subclass could make an optimization to the one-arg read() that it couldn't also make with the three-arg read(). Since the subclass is required to implement the three-arg read(), there's no benefit in specifying that this method call the one-arg read() instead of the three-arg read(). However, requiring this implementation to call the one-arg read() method is detrimental, because it precludes future optimizations that we might want to make to this method, which might want to use the more flexible three-arg read() method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089856314 From mseledtsov at openjdk.org Wed May 14 22:44:51 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 14 May 2025 22:44:51 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v2] In-Reply-To: References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY wrote: >> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Update TestDockerMemoryMetricsSubgroup.java > > remove extra space Change looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24930#issuecomment-2881756560 From ccheung at openjdk.org Wed May 14 23:29:58 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 14 May 2025 23:29:58 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Looks good. Thanks! ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2841729544 From mseledtsov at openjdk.org Wed May 14 23:49:50 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 14 May 2025 23:49:50 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v2] In-Reply-To: References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY wrote: >> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Update TestDockerMemoryMetricsSubgroup.java > > remove extra space Marked as reviewed by mseledtsov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24930#pullrequestreview-2841749929 From bchristi at openjdk.org Wed May 14 23:56:05 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 14 May 2025 23:56:05 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner Message-ID: Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner. (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.) In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical. Details of note: 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update). 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state. The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same. Thanks. ------------- Commit messages: - small comment update - simplify test - update test to use WhiteBox, and use volatile read for enumCount - improve test to give cleaning action a chance to run - remove unneeded fullFence()s, fix copyright years, update some comments - more hasMoreReferrals() merge error fixing - fix hasMoreReferrals() merge error - update EnumCtx comment - remove fullFence() calls, fix reachabilityFence() arguments, remove some unneeded comments - simplify some comments - ... and 19 more: https://git.openjdk.org/jdk/compare/b6b5ac1e...e36cf5db Changes: https://git.openjdk.org/jdk/pull/25242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283660 Stats: 718 lines in 7 files changed: 391 ins; 90 del; 237 mod Patch: https://git.openjdk.org/jdk/pull/25242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25242/head:pull/25242 PR: https://git.openjdk.org/jdk/pull/25242 From ccheung at openjdk.org Thu May 15 00:16:32 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 00:16:32 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: References: Message-ID: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> > This fix adds the `--add-reads` support for CDS and AOTClassLinking. > Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: > `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` > During runtime, the archived full module graph will be disabled: > `[0.021s][info][cds ] full module graph: disabled` > > With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. > > Testing: tiers 1 - 4. Calvin Cheung 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: - @iklam comment - Merge branch 'master' into 8354083-add-reads - fix trailing whitespace - 8354083: Support --add-reads with -XX:+AOTClassLinking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25109/files - new: https://git.openjdk.org/jdk/pull/25109/files/562fc591..327dc2d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=00-01 Stats: 18384 lines in 682 files changed: 11198 ins; 4135 del; 3051 mod Patch: https://git.openjdk.org/jdk/pull/25109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25109/head:pull/25109 PR: https://git.openjdk.org/jdk/pull/25109 From ccheung at openjdk.org Thu May 15 00:21:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 00:21:52 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking I have moved the three tests (AddExports.java, AddOpens.java, AddReads.java) to the `runtime/cds/appcds/aotClassLinking` directory. The AddOpens.java and AddReads.java were rewritten to make use of the `SimpleCDSAppTester` and `CDSAppTester` classes. The `TEST.groups` needs some adjustments as a result of the tests relocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2881879075 From serb at openjdk.org Thu May 15 02:27:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 15 May 2025 02:27:50 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Wed, 14 May 2025 17:34:45 GMT, Naoto Sato wrote: >> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.) > > I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them. maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090083320 From naoto at openjdk.org Thu May 15 03:20:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 May 2025 03:20:51 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Thu, 15 May 2025 02:25:30 GMT, Sergey Bylokhov wrote: >> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them. > > maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090140891 From iklam at openjdk.org Thu May 15 03:23:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 03:23:40 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 - Added param to makefile function SetupAOT for choosing onestep vs twostep - Allow one-step training even when -XX:AOTMode=auto is specified - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - Update java man page - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=08 Stats: 2082 lines in 24 files changed: 1558 ins; 459 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Thu May 15 03:23:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 03:23:40 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> References: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> Message-ID: On Wed, 14 May 2025 15:38:06 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - java.md updates from @rose00 >> - Resolved differences with CSR JDK-8356010 > > src/hotspot/share/cds/cds_globals.hpp line 123: > >> 121: product(ccstr, AOTCacheOutput, nullptr, \ >> 122: "Write AOT cache into this file (overrides AOTCache when " \ >> 123: "writing)") \ > > This looks not complete description. And "override AOTCache .." is confusing. I changed it to "Specifies the file name for writing the AOT cache". Since the behavior is complex, I don't know how much detail I should put here. > src/hotspot/share/cds/metaspaceShared.cpp line 1150: > >> 1148: print_java_launcher(&ss); >> 1149: const char* cmd = ss.freeze(); >> 1150: tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration); > > I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think. > Was this discussed? Currently we print things that are important to the user. The other examples are: $ java -XX:AOTMode=record .... AOTConfiguration recorded: hw.aotconfig $ java -XX:AOTMode=create .... Reading AOTConfiguration hw.aotconfig and writing AOTCache hw.aot AOTCache creation is complete: hw.aot 10498048 bytes I think AOT is still a new feature so a small number of TTY prints would be helpful. If people complain about the verbosity we can change them to UL logs. > src/hotspot/share/runtime/arguments.cpp line 3060: > >> 3058: } >> 3059: >> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { > > I don't like that we pollute `Arguments` code with AOT specific flags processing. > Can we move this into `CDSConfig`? Both these 2 new methods. > > But I will agree if you want to keep it here. It is not critical. These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp. > src/java.base/share/man/java.md line 4141: > >> 4139: mode should be used only as a "fail-fast" debugging aid to check if your command-line >> 4140: options are compatible with the AOT cache. An alternative is to run your application with >> 4141: `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not. > > `-Xlog:aot` `-Xlog:cds,aot` is correct for the current state of this PR. I'll change it after JDK-8356595 is integrated into the mainline. > test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166: > >> 164: "-XX:-AOTClassLinking", >> 165: "-XX:AOTConfiguration=" + aotConfigFile, >> 166: "-Xlog:cds=debug", > > `-Xlog:aot` > I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first. `-Xlog:cds=debug` is correct for the current state of this PR (otherwise the test will fail). I'll change it after JDK-8356595 is integrated into the mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133925 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133649 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133612 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133585 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133557 From kvn at openjdk.org Thu May 15 03:36:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 May 2025 03:36:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> Message-ID: On Thu, 15 May 2025 03:15:23 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/arguments.cpp line 3060: >> >>> 3058: } >>> 3059: >>> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { >> >> I don't like that we pollute `Arguments` code with AOT specific flags processing. >> Can we move this into `CDSConfig`? Both these 2 new methods. >> >> But I will agree if you want to keep it here. It is not critical. > > These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp. okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090168858 From kvn at openjdk.org Thu May 15 03:40:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 May 2025 03:40:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 > - Added param to makefile function SetupAOT for choosing onestep vs twostep > - Allow one-step training even when -XX:AOTMode=auto is specified > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2842120535 From iklam at openjdk.org Thu May 15 04:20:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 04:20:51 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25109#pullrequestreview-2842162246 From duke at openjdk.org Thu May 15 05:55:54 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 15 May 2025 05:55:54 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com> Message-ID: On Wed, 14 May 2025 22:19:39 GMT, Stuart Marks wrote: >> I meant that the implementation of `subSequence` *might or might not* perform copy (so we need to tell the javaDoc reader), while `getChar` *clearly* performs a copy as part of it design. So `subSequence` can be surprising as this discussion proofs, while `getChars` will not. That was Stuart's point with `read`, and that was your point with `CharSequence`. > > @mkarg Please don't invoke my name to try to buttress your arguments. The calls the Reader.of() instance makes on its backing CharSequence is a different kind of issue from what promises or guarantees the concrete methods of the Reader class makes to its subclasses. @stuart-marks Sorry, didn't want to pull you in here, that's why I said, I am just *paraphrasing*. That is correct, it is a different case, but the *final effect* for the caller is the same: If he needs to now whether a copy is made *or not*, he needs to have JavaDocs telling him *how* the new method works inside (whether it calls `subSequence` or whether it calls `getChars`). Otherwise he might make false assumptions about the result. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090314165 From duke at openjdk.org Thu May 15 06:07:55 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 15 May 2025 06:07:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com> <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com> <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com> <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com> Message-ID: On Wed, 14 May 2025 22:31:46 GMT, Stuart Marks wrote: >> I know that comment already, but IMHO we can simply use `@implSpec` to unambiguously make clear that this method invokes `read(char[])` to allow optimized implementations, and it *might* in turn invoke `read(char[],int,int)`, but this is *not guaranteed*. A class is only fragile as long as we do not *document* what it will do. > > I doubt a subclass could make an optimization to the one-arg read() that it couldn't also make with the three-arg read(). Since the subclass is required to implement the three-arg read(), there's no benefit in specifying that this method call the one-arg read() instead of the three-arg read(). > > However, requiring this implementation to call the one-arg read() method is detrimental, because it precludes future optimizations that we might want to make to this method, which might want to use the more flexible three-arg read() method. Well, I did not say that the specific `CharSequence` *could not* have optimized both methods, I just said *it might be* like that (for whatever reason). ? I do not see a difference in the positive or negative outcomes whatever method we choose. The one method we call will benefit from its optimization, the one that we do not pick will miss the support for its optimization. I can't see what you like to optimize in future that is only possible with the three-arg parameters but would not be possible with the one-arg parameter. Do you have an example for this future optimization (note that the outcome shall and will ever be the *full* result due to the nature of this particular new method)? ? If there is broad agreement that `Reader` implementation should *not* put optimizations *only* in the single-arg method but always should optimize the three-arg method too, we should definitively mention this decision in `Reader`'s Javadocs so implementors do know. Currently we only say that it would be *enough* to implement the three-arg method, which has a different semantic and urgence for the reader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090346089 From alanb at openjdk.org Thu May 15 06:09:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 May 2025 06:09:51 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops In-Reply-To: References: Message-ID: On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs wrote: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. Are you planning to add some JMH benchmarks to go with this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2882668954 From duke at openjdk.org Thu May 15 06:29:54 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 15 May 2025 06:29:54 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: On Wed, 14 May 2025 20:52:00 GMT, Markus KARG wrote: >> There's nothing in the CharSequence interface that requires or indicates that the implementation is or is not immutable. Interfaces only have loosely defined contracts, only the signature of the methods, the caller can not hold any more expectations about the semantics of the implementation. >> Immutable objects are among the best tools we have for making reliable software. >> The caller does not have to have a deep knowledge of the implementation to get predictable results. >> For most OpenJDK public APIs, the objective is to have well defined semantics with no implementation surprises. > > Granted in general, but again, it is not the job of *this particular API* to forbid mutation *iff* the caller and / or producer of the object see a good reason for that. This completely overdesigns the target of *this* API. Callers are no dummies, they can read JavaDocs, and they can `.toString()` on their own *iff* needed. Actually, in 30 years I never heard a Java Programmer say "oops, I did not expect `CharSequence` to mutate". With that attitude we could simply deprecate `CharSequence` for removal...! > > BTW, how will you mutate a `CharSequence` if you don't know its actual implementation? Try-and-error? ? Or with "immutable" do you mean *constant* objects (i. e. *the producer* will not modify it after creation)? > > It is a *good* thing not to know what you have in your hands, as you *do not start* making assumptions (like "it is immutable"). I am fond of getting *away* from those restricted semantics, towards a cleaner "do not assume, do not trust" policy. > > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... > > The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is _inefficient_ to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing. Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090374558 From tpushkin at openjdk.org Thu May 15 06:45:54 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 15 May 2025 06:45:54 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Thank you! > Once this PR has 2 reviews and is final, I will run some tests in our test pipeline. @iklam It is final, please run the tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2882738562 From peter.levart at gmail.com Thu May 15 07:01:42 2025 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 May 2025 09:01:42 +0200 Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream In-Reply-To: References: <8721e7784793451187c5b6099eb37756@amazon.com> <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu> <8d453b79099b4675bce7f3902e3cd74f@amazon.com> <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com> <3f1c69a7ac5946809d2af850d7d59db9@amazon.com> <4741eceb3beb40c2bc82613c67836d66@amazon.com> <95335d21438d4826a87db616b65d9ec9@amazon.com> Message-ID: <7dbee86b-b80e-4827-aaa9-603d5e6d3402@gmail.com> On 4/11/25 6:19 PM, Archie Cobbs wrote: > Sorry if that wasn't clear - I didn't mean power-of-two exponential > growth, I meant all segments were literally fixed size, like 256 or > something (or maybe this value would be provided to the constructor). > This keeps the access to individual elements constant time. You can have power-of-two exponentially growing segments and still access individual elements by index in constant time (although you don't need this if you are just doing the ByteArrayOutputStream implementation). For example, let the array of segments: byte[][] segments; start with 0th segment of length 1 byte, then 2, 4, 8, 16, ... To access the i-th byte you would do: ??? byte getByte(int i) { ??????? int segmentIndex = 31 - Integer.numberOfLeadingZeros(i + 1); ??????? int byteIndex = i + 1 - (1 << segmentIndex); ??????? return segments[segmentIndex][byteIndex]; ??? } This can be adapted to situations where the 0th segment starts not with 1 byte length but with any 2^N length. For example, 8: ??? byte getByte(int i) { ??????? int segmentIndex = 31 - Integer.numberOfTrailingZeros(8) - Integer.numberOfLeadingZeros(i + 8); ??????? int byteIndex = i + 8 - (8 << segmentIndex); ??????? return segments[segmentIndex][byteIndex]; ??? } What I'm trying to say is that constant segment length might not be the best choice if you consider the range of possible ByteArray (BAOS) final lengths. If you choose too small, the number of segments will be too large, so you end up with multiple resizing(s) of the array of segments then - the problem you are trying to solve would still be there, although divided by the segment size. If you choose to big, the up-front allocation overhead for small ByteArray(s) (BAOSes) would be too large. With power-of-two exponentially growing segments you get an allocation overhead below 2x the needed final length and no redundant copying (apart from final copy to the result if you need such result as byte[]). Regards, Peter From tschatzl at openjdk.org Thu May 15 08:18:47 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 May 2025 08:18:47 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v38] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * ayang review: remove sweep_epoch - Merge branch 'master' into card-table-as-dcq-merge - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * ayang review (part 2 - yield duration changes) - * ayang review (part 1) - * indentation fix - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fixes after merge related to 32 bit x86 removal - ... and 44 more: https://git.openjdk.org/jdk/compare/5e50a584...1def83af ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=37 Stats: 7088 lines in 111 files changed: 2568 ins; 3599 del; 921 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ihse at openjdk.org Thu May 15 09:19:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 15 May 2025 09:19:53 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Thu, 15 May 2025 03:18:30 GMT, Naoto Sato wrote: >> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? > > Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not. > So, this exactly reverses what was done in the fix for JDK-8301991 No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090692617 From ihse at openjdk.org Thu May 15 09:19:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 15 May 2025 09:19:53 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Thu, 15 May 2025 09:16:10 GMT, Magnus Ihse Bursie wrote: >> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not. > >> So, this exactly reverses what was done in the fix for JDK-8301991 > > No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. > > This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. > > Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence. > maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090695445 From lkorinth at openjdk.org Thu May 15 09:20:03 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 15 May 2025 09:20:03 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* After an offline discussion, we agreed to wait a bit with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218 From lkorinth at openjdk.org Thu May 15 09:20:03 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 15 May 2025 09:20:03 GMT Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25122 From alanb at openjdk.org Thu May 15 09:42:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 May 2025 09:42:52 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter wrote: >> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set test/jdk/java/io/File/DeleteReadOnly.java line 61: > 59: @Test > 60: @Order(1) > 61: @EnabledOnOs({OS.AIX, OS.LINUX, OS.MAC}) Have you look at creating a simpler test that doesn't use Order. If you drop DIR and FILE then each test could create the file or directory as needed so there wouldn't be any dependency on order. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2090748506 From pminborg at openjdk.org Thu May 15 09:54:29 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 15 May 2025 09:54:29 GMT Subject: RFR: 8356706: Foreign tests timeout after passing on linux-x64-zero Message-ID: This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin). ------------- Commit messages: - Improve robustness of tests on slow machines Changes: https://git.openjdk.org/jdk/pull/25248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356706 Stats: 32 lines in 2 files changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/25248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25248/head:pull/25248 PR: https://git.openjdk.org/jdk/pull/25248 From pminborg at openjdk.org Thu May 15 09:54:29 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 15 May 2025 09:54:29 GMT Subject: RFR: 8356706: Foreign tests timeout after passing on linux-x64-zero In-Reply-To: References: Message-ID: On Thu, 15 May 2025 09:49:10 GMT, Per Minborg wrote: > This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin). test/jdk/java/foreign/StdLibTest.java line 56: > 54: static final Linker abi = Linker.nativeLinker(); > 55: > 56: private static final StdLibHelper STD_LIB_HELPER = new StdLibHelper(); The `STD_LIB_HELPER` is now a constant. test/jdk/java/foreign/StdLibTest.java line 145: > 143: static final class StdLibHelper { > 144: > 145: static final MethodHandle strcat = abi.downcallHandle(abi.defaultLookup().findOrThrow("strcat"), Drive-by cleanup to blessed order. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25248#discussion_r2090771644 PR Review Comment: https://git.openjdk.org/jdk/pull/25248#discussion_r2090769634 From duke at openjdk.org Thu May 15 09:57:18 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 09:57:18 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v4] In-Reply-To: References: Message-ID: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Remove unused method getDockerVersionStr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/3b18431d..61ca55ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=02-03 Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From duke at openjdk.org Thu May 15 09:57:19 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 09:57:19 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com> References: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com> Message-ID: <2ipbr_eKTB9-n_iHSSim1CqnM4thc3Yv6s5XuAvAKQE=.6a26fe01-853e-41fc-9090-182560004dd2@github.com> On Wed, 14 May 2025 09:41:58 GMT, Sergey Chernyshev wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor container runtime version code > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166: > >> 164: return null; >> 165: } >> 166: } > > Do you still need this method? Removed the method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2090785990 From pminborg at openjdk.org Thu May 15 10:01:57 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 15 May 2025 10:01:57 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation So, I think we are ready to go with the latest version. ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2843068669 From duke at openjdk.org Thu May 15 10:03:11 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 10:03:11 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: <1elyKkFE2sZemPibqVeEswvApPKGWXVqeEMHc4rJpds=.9fff5366-2c8c-48b1-9523-a51b7f4a52ad@github.com> On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor container runtime version code > > The change looks good. There might be some issues with container engine version parsing. > > I wrote 2 comments. but cold not post them. They are in "pending" state. > Not sure why. Should the comments be first reviewed by {Committers|Reviewers}? @Domest0s I have tested against both docker and podman version and it was able to parse for eg `docker version 20.10.0` and `podman version 4.9.4-rhel` ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2883250455 From alanb at openjdk.org Thu May 15 10:02:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 May 2025 10:02:54 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking Update to allow --add-reads is okay, no comments from me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2883257946 From duke at openjdk.org Thu May 15 10:03:11 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 10:03:11 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/61ca55ee..b3ccffd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From duke at openjdk.org Thu May 15 10:25:57 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 15 May 2025 10:25:57 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> Message-ID: <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com> On Thu, 15 May 2025 06:27:36 GMT, Johannes D?bler wrote: >> Granted in general, but again, it is not the job of *this particular API* to forbid mutation *iff* the caller and / or producer of the object see a good reason for that. This completely overdesigns the target of *this* API. Callers are no dummies, they can read JavaDocs, and they can `.toString()` on their own *iff* needed. Actually, in 30 years I never heard a Java Programmer say "oops, I did not expect `CharSequence` to mutate". With that attitude we could simply deprecate `CharSequence` for removal...! >> >> BTW, how will you mutate a `CharSequence` if you don't know its actual implementation? Try-and-error? ? Or with "immutable" do you mean *constant* objects (i. e. *the producer* will not modify it after creation)? >> >> It is a *good* thing not to know what you have in your hands, as you *do not start* making assumptions (like "it is immutable"). I am fond of getting *away* from those restricted semantics, towards a cleaner "do not assume, do not trust" policy. > >> > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... >> >> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is _inefficient_ to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing. > > Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink. If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090841625 From duke at openjdk.org Thu May 15 10:25:58 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 15 May 2025 10:25:58 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com> Message-ID: On Thu, 15 May 2025 10:21:26 GMT, Markus KARG wrote: >>> > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence... >>> >>> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is _inefficient_ to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing. >> >> Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink. > > If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`? Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090844002 From duke at openjdk.org Thu May 15 10:55:54 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 15 May 2025 10:55:54 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com> Message-ID: On Thu, 15 May 2025 10:22:51 GMT, Markus KARG wrote: >> If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`? > > Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object. Thanks for the examples. Imho I think that performance sensitive, specialised code can invest some lines to put together the best solution for the context whereas the majority of code can simply use a convenient `reader.readAllAsString()` instead of `reader.readAllAsCharSequence().toString()` which is borderline to parody. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090896148 From duke at openjdk.org Thu May 15 11:03:58 2025 From: duke at openjdk.org (Markus KARG) Date: Thu, 15 May 2025 11:03:58 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com> Message-ID: On Thu, 15 May 2025 10:53:27 GMT, Johannes D?bler wrote: >> Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object. > > Thanks for the examples. Imho I think that performance sensitive, specialised code can invest some lines to put together the best solution for the context whereas the majority of code can simply use a convenient `reader.readAllAsString()` instead of `reader.readAllAsCharSequence().toString()` which is borderline to parody. It is **impossible** to "invest some lines" to solve this in JAX-RS, and JAX-RS as a standard technology on tens of thousands of servers. Enforcing `String` prevents these useful optimizations, but brings *no actual benefit*, as *only few* callers actually care for *constant* objects, but would be satisfied with `CharSequence`'s lack of mutation methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090910821 From duke at openjdk.org Thu May 15 11:13:58 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 15 May 2025 11:13:58 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 09:40:13 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set > > test/jdk/java/io/File/DeleteReadOnly.java line 61: > >> 59: @Test >> 60: @Order(1) >> 61: @EnabledOnOs({OS.AIX, OS.LINUX, OS.MAC}) > > Have you look at creating a simpler test that doesn't use Order. If you drop DIR and FILE then each test could create the file or directory as needed so there wouldn't be any dependency on order. If each test method creates needed files and sub directories, then It could be useful to let JUnit create and inject a temporary root directory: @org.junit.jupiter.api.io.TempDir private static File testDir; JUnit will automatically delete it with all content after the test methods have run. (But this can fail if readonly files are encountered). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2090925493 From pminborg at openjdk.org Thu May 15 12:19:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 15 May 2025 12:19:53 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks wrote: >> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: >> >> - overrides and adds locking to SequencedCollection methods; >> - performs instance management of reversed synchronized views; >> - adds test for race conditions and functional tests of synchronized wrappers. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Reversed view of SynchronizedRandomAccessList should also be RandomAccess. > Add tests to ensure RandomAccess is preserved when reversing. src/java.base/share/classes/java/util/Collections.java line 2782: > 2780: synchronized (mutex) {list.sort(c);} > 2781: } > 2782: public void addFirst(E element) { Are these overloads strictly needed as the `default` implementations will delegate to `get` and `set`, which, in turn, are thread safe? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2091040080 From rgiulietti at openjdk.org Thu May 15 12:35:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 12:35:51 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> On Thu, 15 May 2025 09:17:42 GMT, Magnus Ihse Bursie wrote: >>> So, this exactly reverses what was done in the fix for JDK-8301991 >> >> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. >> >> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. >> >> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence. > >> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? > > That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case. FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France): - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark. - U+00A0 (No-Break Space NBSP) preceding colon. Similar conventions are used in other French speaking countries. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2091068610 From erikj at openjdk.org Thu May 15 13:06:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 15 May 2025 13:06:59 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 > - Added param to makefile function SetupAOT for choosing onestep vs twostep > - Allow one-step training even when -XX:AOTMode=auto is specified > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b doc/testing.md line 619: > 617: run existing jtreg test cases in a special "AOT_JDK" mode. Example: > 618: > 619: Is this extra newline intentional? doc/testing.md line 629: > 627: these classes (such as pre-linked lambda expressions, execution profiles, and pre-generated native code) > 628: are stored into an AOT cache file, which will be used by all the JVMs launched by the selected jtreg > 629: test cases. Some of these lines are >80 chars. Can you try to format line lengths in this file to stay under where reasonably feasible? It's ok if long markups such as links go over, just try to keep the normal text adhering to this. doc/testing.md line 640: > 638: Also, test cases that were written specifically to test AOT, such as the tests > 639: under [test/hotspot/jtreg/runtime/cds](../test/hotspot/jtreg/runtime/cds/), cannot > 640: be execute with the AOT_JDK mode. Suggestion: be executed with the AOT_JDK mode. doc/testing.md line 642: > 640: be execute with the AOT_JDK mode. > 641: > 642: Valid values for `AOT_JDK` are `one_step` and `two_step`. These control how Looks like the values are `onestep` and `twostep` in the makefile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091117516 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091125422 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091121317 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091122470 From rgiulietti at openjdk.org Thu May 15 13:38:06 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 13:38:06 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v4] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Update names Since you are at it, I'd suggest changing `javaIncrement` to be `static` (no need to change access). Also, if you find remnants of C-style array notation, like `int newMag[]`, it would be nice to have them as `int[] newMag`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883843995 From duke at openjdk.org Thu May 15 13:43:53 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 15 May 2025 13:43:53 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v4] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Thu, 15 May 2025 13:35:29 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Update names > > Since you are at it, I'd suggest changing `javaIncrement` to be `static` (no need to change access). > > Also, if you find remnants of C-style array notation, like `int newMag[]`, it would be nice to have them as `int[] newMag`. @rgiulietti And what about the [suggestion](https://github.com/openjdk/jdk/pull/25166#discussion_r2083561722) of @liach? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883862016 From rgiulietti at openjdk.org Thu May 15 13:53:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 13:53:51 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v4] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Update names I agree renaming it `magBitLength` and having just the `int[]` as parameter. It cannot be made an instance method, though. There's one usage which needs a static invocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883894295 From vyazici at openjdk.org Thu May 15 14:01:57 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 15 May 2025 14:01:57 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: <6NeDdpJHPkF7E3zioEtxyeVC1fX4FT2w38VbpJg5BUA=.6c1d39fd-a07b-49b0-8303-36f65aec17f3@github.com> On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation Green `tier1,2` results are attached to ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2883918329 From duke at openjdk.org Thu May 15 14:01:58 2025 From: duke at openjdk.org (duke) Date: Thu, 15 May 2025 14:01:58 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation @vy Your change (at version 0e06ce1d028ce2fef5705e59d9245fcaa93abcd9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2883921694 From archie.cobbs at gmail.com Thu May 15 14:04:22 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 15 May 2025 09:04:22 -0500 Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream In-Reply-To: <7dbee86b-b80e-4827-aaa9-603d5e6d3402@gmail.com> References: <8721e7784793451187c5b6099eb37756@amazon.com> <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu> <8d453b79099b4675bce7f3902e3cd74f@amazon.com> <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com> <3f1c69a7ac5946809d2af850d7d59db9@amazon.com> <4741eceb3beb40c2bc82613c67836d66@amazon.com> <95335d21438d4826a87db616b65d9ec9@amazon.com> <7dbee86b-b80e-4827-aaa9-603d5e6d3402@gmail.com> Message-ID: On Thu, May 15, 2025 at 2:02?AM Peter Levart wrote: > On 4/11/25 6:19 PM, Archie Cobbs wrote: > > Sorry if that wasn't clear - I didn't mean power-of-two exponential > > growth, I meant all segments were literally fixed size, like 256 or > > something (or maybe this value would be provided to the constructor). > > This keeps the access to individual elements constant time. > > You can have power-of-two exponentially growing segments and still > access individual elements by index in constant time... Good point! There are more clever ways to size the chunks that still retain constant time access. What I would love to see someday is all of this kind of cleverness baked into a standard set of "ArrayBuilder" classes, so we can then declare victory for cleverness and never have to worry about the fastest way to buffer data into memory again. Then we could focus our optimization efforts just on those classes, and the users of those classes all over the JDK (e.g., ArrayList, StringBuilder, whatever) would automatically benefit. This might be a pipe dream. At least, it brings up an interesting question re: how you would design such a thing... e.g., how would you parameterize it? E.g., Initial chunk size, maximum chunk size, growth rate exponent, etc. Or could it be truly adaptive (one (initial) size fits all)? Etc. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu May 15 14:05:01 2025 From: duke at openjdk.org (Abhishek N) Date: Thu, 15 May 2025 14:05:01 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() [v2] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 23:24:03 GMT, Justin Lu wrote: >> Abhishek N has updated the pull request incrementally with one additional commit since the last revision: >> >> correcting jtreg header order, add meaningful comments for each test methods and properties file > > Hi @abhn-git, I think it would be beneficial if we first addressed the concerns raised before continuing work on this PR. [JDK-8355393](https://bugs.openjdk.org/browse/JDK-8355393) assigned to you and [JDK-8355045](https://bugs.openjdk.org/browse/JDK-8355045) assigned to @weibxiao appear to be duplicates. Hi @justin-curtis-lu @weibxiao The main cause for failure in https://bugs.openjdk.org/browse/JDK-8353433 is that "currency cut-over date functionality was broken for the Currency.getInstance(String currencyCode, int defaultFractionDigits, int numericCode)" call and the currency 8u code threw illegalArguementException for new Currency after cut-over time was passed by System. Example: "CW=ANG;2025-04-01-04-00-00;XCG" -> After System time passed 1st April 2025 4:00 am, Currency.getInstance(XCG) -> throw illegalArguementException Please note the issue could not be caught earlier and was caught only after System time passed the cut over time. So to prevent such miss in future, we have to write tests to check that after System time has passed cut over time the expected new currency instance is returned by both Currency.getInstance methods. This can be achieved by two ways 1. To mock System time to be after cut over time and see if Currency.getInstance is working as expected. 2. **To perform Currency overriding mechanism via the system property, where a modified currencies.properties file is set and it has entries for currencies whose cut over time is passed. And we write tests to verify both Currency.getInstance() methods and it has to return values as required.** The test written in this PR does option 2 Example: In our modified currencies.properties file we have below entry SX=ANG,532,2,2025-04-22T00:00:00 So, the test code ensures that since System time is past the cut over time the Currency.getInstance(new Locale("SX")) and Currency.getInstance("ANG") should return values as expected (expected values are in CurrencyList.txt). And if new currencies are added in future with cut over timeconditions it should work properly once the System time passes cut over time ,provided our test in above PR is Passing. The test written in this PR does option 2. and works fine for all the release. @justin-curtis-lu @weibxiao please let me know if there are any issues with this test fix. thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2883930487 From duke at openjdk.org Thu May 15 14:05:01 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 15 May 2025 14:05:01 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v4] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Thu, 15 May 2025 13:51:29 GMT, Raffaello Giulietti wrote: > It cannot be made an instance method, though. There's one usage which needs a static invocation. @rgiulietti If you are referring to [this invocation](https://github.com/fabioromano1/jdk/blob/5ad26a14049e1765d9ef46f307d723dd4b315382/src/java.base/share/classes/java/math/BigInteger.java#L3126), the local variable `exp` is just an alias of `y.mag`, so it can be made an instance invocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883932854 From rgiulietti at openjdk.org Thu May 15 14:07:56 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 14:07:56 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v4] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Update names Right. Let's go with an instance method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883943091 From duke at openjdk.org Thu May 15 14:08:04 2025 From: duke at openjdk.org (duke) Date: Thu, 15 May 2025 14:08:04 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand @TimPushkin Your change (at version a3b7dd962a0b5ee32395c2b08232bf1cbd0ef0f9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2883940576 From acobbs at openjdk.org Thu May 15 14:14:59 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 15 May 2025 14:14:59 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops In-Reply-To: References: Message-ID: On Thu, 15 May 2025 06:07:06 GMT, Alan Bateman wrote: > Are you planning to add some JMH benchmarks to go with this? I wasn't planning to, but I'm inferring from your question that you'd prefer to see one. Which also makes me curious. I'd be shocked if this were slower, but even if not, I wonder how much faster it would be. I will work on creating one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2883965303 From duke at openjdk.org Thu May 15 14:15:29 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 15 May 2025 14:15:29 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v5] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Make javaIncrement(int[]) static ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/5ad26a14..d0df9eb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From rriggs at openjdk.org Thu May 15 14:48:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 May 2025 14:48:54 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops In-Reply-To: References: Message-ID: On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs wrote: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. I'm curious to know whether C2 turns the loop into a vectorized operation. The Arrays.fill might be more expressive, but not necessarily faster. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884095477 From liach at openjdk.org Thu May 15 14:57:05 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 15 May 2025 14:57:05 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2884130126 From vyazici at openjdk.org Thu May 15 14:57:05 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 15 May 2025 14:57:05 GMT Subject: Integrated: 8353197: Document preconditions for JavaLangAccess methods In-Reply-To: References: Message-ID: <83yYC2PGBDztvGXa1rA5Jrt561lI1FiaEBk3EaauueM=.a287f882-4ec9-47b0-9e08-67b29982dbb8@github.com> On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici wrote: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. This pull request has now been integrated. Changeset: 8fcfddb2 Author: Volkan Yazici Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/8fcfddb2d202cdb61941efdb3fec5807fee98c33 Stats: 124 lines in 22 files changed: 23 ins; 3 del; 98 mod 8353197: Document preconditions for JavaLangAccess methods Reviewed-by: pminborg, liach ------------- PR: https://git.openjdk.org/jdk/pull/24982 From duke at openjdk.org Thu May 15 15:37:39 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 15 May 2025 15:37:39 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: make magBitLength() an instance method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/d0df9eb2..642461fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=04-05 Stats: 36 lines in 1 file changed: 7 ins; 10 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From mseledtsov at openjdk.org Thu May 15 15:48:52 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Thu, 15 May 2025 15:48:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import Marked as reviewed by mseledtsov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844233145 From aph at openjdk.org Thu May 15 15:52:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 May 2025 15:52:14 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v7] In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Delete unused label ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25147/files - new: https://git.openjdk.org/jdk/pull/25147/files/e5771988..da574ccb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From aph at openjdk.org Thu May 15 15:52:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 May 2025 15:52:14 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Wed, 14 May 2025 15:36:32 GMT, Andrew Dinn wrote: > Looks good to me. Sorry, please approve again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2884310593 From bpb at openjdk.org Thu May 15 15:54:53 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 May 2025 15:54:53 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v3] In-Reply-To: References: Message-ID: <92OaTIqTXS4w5ePqmjBG7ONU82fcDYGCw5jSmt8M-eI=.0b055f31-0e97-41f4-b0dd-2a473f9ee2b0@github.com> On Thu, 15 May 2025 11:11:06 GMT, Johannes D?bler wrote: > [I]t could be useful to let JUnit create and inject a temporary root directory [...] I am not sure about this. The temporary file path created by JUnit, on macOS at least, is in a different directory hierarchy (`/var/...`) from the jtreg work directory (`/tmp/...`) so jtreg's own cleanup phase might not remove files if there are any straggling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2091502403 From aph at openjdk.org Thu May 15 16:03:44 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 15 May 2025 16:03:44 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8] In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Copyright format correction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25147/files - new: https://git.openjdk.org/jdk/pull/25147/files/da574ccb..283b900e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147 PR: https://git.openjdk.org/jdk/pull/25147 From rgiulietti at openjdk.org Thu May 15 16:24:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 16:24:54 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v4] In-Reply-To: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com> References: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com> Message-ID: On Wed, 14 May 2025 14:39:37 GMT, Johannes Graham wrote: >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. > > Johannes Graham has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java > > Align better with spec > > Co-authored-by: Raffaello Giulietti > - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java > > Better alignment with spec > > Co-authored-by: Raffaello Giulietti > - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java > > Add another final > > Co-authored-by: Raffaello Giulietti Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25173#pullrequestreview-2844337861 From duke at openjdk.org Thu May 15 16:27:53 2025 From: duke at openjdk.org (Johannes Graham) Date: Thu, 15 May 2025 16:27:53 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) In-Reply-To: References: Message-ID: On Mon, 12 May 2025 02:06:23 GMT, Chen Liang wrote: >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. > > Sorry, didn't see your core-libs-dev mail. Created an issue for you at https://bugs.openjdk.org/browse/JDK-8356709 Thank you @liach @rgiulietti and @jddarcy ------------- PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2884410316 From duke at openjdk.org Thu May 15 16:27:54 2025 From: duke at openjdk.org (duke) Date: Thu, 15 May 2025 16:27:54 GMT Subject: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) [v4] In-Reply-To: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com> References: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com> Message-ID: On Wed, 14 May 2025 14:39:37 GMT, Johannes Graham wrote: >> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. > > Johannes Graham has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java > > Align better with spec > > Co-authored-by: Raffaello Giulietti > - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java > > Better alignment with spec > > Co-authored-by: Raffaello Giulietti > - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java > > Add another final > > Co-authored-by: Raffaello Giulietti @j3graham Your change (at version 0cc32fc02afc461ae3a161011e32c339b4e44241) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2884411223 From lmesnik at openjdk.org Thu May 15 16:29:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 May 2025 16:29:13 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73: > 71: return; > 72: } > 73: if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) { Better to replace this with `isContainerVersionSupported()` ... and implement all logic in the the ContainerRuntimeVersionTestUtils test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38: > 36: private final int micro; > 37: private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0); > 38: public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0); Please add comment about meaning of the version or even better rename DOCKER_MINIMAL_SUPPORTED_VERSION = .... test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53: > 51: } else if (this.major < other.major) { > 52: return -1; > 53: } else { // equal major no need to add `else {` here test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58: > 56: } else if (this.minor < other.minor) { > 57: return -1; > 58: } else { // equal majors and minors no need to add `else {` here test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81: > 79: } catch (Exception e) { > 80: System.out.println("Failed to parse container runtime version: " + version); > 81: return DEFAULT; Any reason to don't fail here? test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94: > 92: } catch (Exception e) { > 93: System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null"); > 94: return null; Any reason to don't fail here? ------------- PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844326936 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091561369 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091564985 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555059 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555200 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091567641 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091566692 From duke at openjdk.org Thu May 15 16:37:05 2025 From: duke at openjdk.org (Johannes Graham) Date: Thu, 15 May 2025 16:37:05 GMT Subject: Integrated: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) In-Reply-To: References: Message-ID: On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham wrote: > Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me. This pull request has now been integrated. Changeset: 1e61352b Author: Johannes Graham Committer: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/1e61352b54e1ac85fbc6b54a7a29e8782dd42d2c Stats: 178 lines in 4 files changed: 169 ins; 1 del; 8 mod 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double) Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/25173 From stuefe at openjdk.org Thu May 15 16:40:57 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 15 May 2025 16:40:57 GMT Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4] In-Reply-To: References: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com> <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com> Message-ID: On Wed, 14 May 2025 00:32:08 GMT, David Holmes wrote: >> Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some implementations, vfork() is equivalent to fork()." AIX manpage says just "The vfork subroutine is supported as a compatibility interface for older Berkeley Software Distribution (BSD) system programs" which sounds to me its just an alias for fork(). MacOS has no vfork anymore. >> >> So maybe Solaris was the last platform with a true vfork. > > @tstuefe the helper was needed in part to enable a chdir between fork and exec - see this comment: https://bugs.openjdk.org/browse/JDK-5049299?focusedId=12148272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12148272 @dholmes-ora My memory was failing me again. Looks like I had found all of this out already, and tested real scenarios where the child process after vfork accidentally damages the parent process: https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html . Back then I also proposed to use the jspawnhelper to isolate this problem, but we went with David Loyd's proposal of adding posix_spawn, and later we switched over to posix_spawn by default. The only remaining question is what to do with the still unsafe vfork mode. I will send a mail to core-libs and feel out the room. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2091589002 From jlahoda at openjdk.org Thu May 15 16:48:35 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 15 May 2025 16:48:35 GMT Subject: RFR: 8357016: Candidate main methods not computed properly Message-ID: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> A consider class like this: public class TwoMains { private static void main(String... args) {} static void main() { System.out.println("Should be called, but is not."); } } The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. Something similar happens if the return type is not `void`. This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). ------------- Commit messages: - 8357016: Candidate main methods not computed properly Changes: https://git.openjdk.org/jdk/pull/25256/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357016 Stats: 129 lines in 8 files changed: 103 ins; 10 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From swen at openjdk.org Thu May 15 16:51:17 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 15 May 2025 16:51:17 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods Message-ID: Similar to PR #24982 Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. ------------- Commit messages: - Document preconditions for DecimalDigits methods Changes: https://git.openjdk.org/jdk/pull/25246/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357063 Stats: 53 lines in 7 files changed: 0 ins; 0 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/25246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246 PR: https://git.openjdk.org/jdk/pull/25246 From thomas.stuefe at gmail.com Thu May 15 16:52:34 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 15 May 2025 18:52:34 +0200 Subject: ProcessImpl: Can we obsolete the vfork mode? Message-ID: Hi, I am currently working on child process issues and again noticed how inherently dangerous the vfork mode is. The child process can damage or kill the parent process if bad things happen in the time window between vfork and exec, when we prepare the target binary execution. For a non-exclusive list of things that can go wrong please see my old mail from 2018 here: https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html These errors are vicious too, since they would rarely be attributable to vfork; they would probably look like random crashes or libc problems. Back in 2018, I proposed an exec-twice technique whereby one execs a helper binary first to isolate the child process preparations; then do the final exec of the target binary. That is safe, fast, and it works. We can still do this. Would be wven simpler to implement now: we have the jspawnhelper and can just reuse that for vfork. However, we also could just get rid of vfork. That would simplify things alot. We have moved to posix_spawn-by-default with JDK 13 in 2019 ( https://bugs.openjdk.org/browse/JDK-8213192). That is a long time ago; probably long enough to ween all customers off vfork use. What do people think? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli at openjdk.org Thu May 15 17:17:55 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 17:17:55 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com> References: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com> Message-ID: On Wed, 14 May 2025 13:21:37 GMT, SendaoYan wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. > > test/lib-test/TEST.ROOT line 31: > >> 29: keys=randomness >> 30: >> 31: # Minimum jtreg version > > Shoule we update the copyright year for file TestNativeProcessBuilder.java @sendaoYan Please let me know if you have any additional review comments, thanks. Also looking for a 'R'eviewer for reviewing. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2091647230 From duke at openjdk.org Thu May 15 17:18:56 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:18:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Tue, 13 May 2025 12:32:56 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 147: > >> 145: // this could exist somewhere common, but if it's definitely never going to >> 146: // be shared, it could be made public here. >> 147: private enum AccessMode { > > Hello David, I think having it `private` is fine and in fact more appropriate. I would suggest removing the comment though. Done. And if it's not getting made visible (i.e. values are always strings) I can simplify things too. > src/jdk.zipfs/share/classes/module-info.java line 277: > >> 275: *

      >> 276: * A value defining the desired read/write access mode of the file system >> 277: * (either read-write or read-only). > > This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system. > > Perhaps we could reword this to something like: > >> >> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access. Yeah, I tried to distinguish the accessMode flags (for which there are 3 states, ro, rw, n/a) and the final state of the file system from fs.isReadOnly(). Hence using `...` for whenever the actually resulting state is mentioned. I guess it wasn't clear enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091645807 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091649006 From duke at openjdk.org Thu May 15 17:26:53 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:26:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Tue, 13 May 2025 13:48:32 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 174: > >> 172: } >> 173: default -> { >> 174: } > > Since we don't allow for any other value, I think moving the `throw new IllegalArgumentException` from outside of the switch into this `default` case might be suitable. I rewrote to avoid the switch now there's no way it needs to cope with being the enum value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091660167 From duke at openjdk.org Thu May 15 17:32:55 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:32:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Tue, 13 May 2025 13:56:34 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 160: > >> 158: >> 159: // Parses the file system permission from an environmental parameter. While >> 160: // the FileSystemAccessMode is private, we don't need to check if it was > > The second sentence perhaps is a leftover? I don't see any `FileSystemAccessMode` type. I think it would be better to remove that second sentence altogether. The rest of the comment looks good and clearly states what this method does. Done. > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167: > >> 165: return null; >> 166: } >> 167: case String label when READ_WRITE.label.equals(label) -> { > > I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler: > > > case "readWrite" -> { > return READ_WRITE; > } > case "readOnly" -> { > return READ_ONLY; > } Or just an if :) The reason for the new style was the "need" for the "String label when" qualifier, which I don't actually need because String.equals(xx) copes with being given non-strings fine. You can't use the syntax you suggested in the new switch since "value" isn't a String. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091667975 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091665729 From duke at openjdk.org Thu May 15 17:32:55 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:32:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com> Message-ID: On Wed, 14 May 2025 07:43:54 GMT, Alan Bateman wrote: >> I'll file an issue for this today, shortly. > > I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already. So does this mean the code is good as-is now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091670125 From duke at openjdk.org Thu May 15 17:39:56 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:39:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: <_fOwfCN-skLDUctxfNIhNVFJB6Q6-RWR7ohRsKi0Yck=.5f156736-e8df-4735-b8b6-fc2cb96ad6d0@github.com> On Wed, 14 May 2025 15:40:41 GMT, Lance Andersen wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 95: > >> 93: >> 94: private static final Set DEFAULT_PERMISSIONS = >> 95: PosixFilePermissions.fromString("rwxrwxrwx"); > > I am not convinced this needs to be changed as it becomes a personal style preference Possibly not, but it is only used in one place, and anyone reading the code now has the comment saying "If not specified in env, it will return 777." three lines away from the code that uses "rwxrwxrwx" instead of nearly 300. Plus, there isn't now a *mutable* static final constant which could be accidentally leaked and mutated in the future. Yes, it's personal preference to a degree, but I feel this is a small, but non-zero, improvement in maintainability, and I would ask someone to do this if I were reviewing a change which added this to the code. > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 113: > >> 111: final ZipCoder zc; >> 112: private final ZipPath rootdir; >> 113: // Start readOnly (safe mode) and maybe reset at end of initialization. > > maybe -> may be Both work. It "may be reset", but also "maybe we will reset it". I reworded slightly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091678054 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091679779 From adinn at openjdk.org Thu May 15 17:41:52 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 15 May 2025 17:41:52 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Copyright format correction Still good ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25147#pullrequestreview-2844529876 From duke at openjdk.org Thu May 15 17:42:52 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:42:52 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Wed, 14 May 2025 16:39:18 GMT, Lance Andersen wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 219: > >> 217: assertFalse(fs.isReadOnly()); >> 218: if (!"Default version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) { >> 219: throw new RuntimeException("unexpected file content"); > > could also consider > > fail("unexpected file content"); Oh thanks for spotting! That's a hangover from when it was in the old-style test class (ZipFSTester or whatever it's called). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091684373 From jpai at openjdk.org Thu May 15 17:45:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 15 May 2025 17:45:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com> Message-ID: On Thu, 15 May 2025 17:30:35 GMT, David Beaumont wrote: >> I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already. > > So does this mean the code is good as-is now? Hello David, yes it's fine to throw `IllegalArgumentException` from here. The specification of `FileSystemProvider.newFileSystem(...)` APIs will be updated in a separate PR to specify the `IllegalArgumentException` that gets thrown. With that, the zipfs provider implementation will conform to the specification and applications are then expected to deal with the `IllegalArgumentException` caused by an incorrect environment property value that was passed during the filesystem construction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091688623 From acobbs at openjdk.org Thu May 15 17:46:39 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 15 May 2025 17:46:39 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2] In-Reply-To: References: Message-ID: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add benchmark for ArrayDeque.clear(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25237/files - new: https://git.openjdk.org/jdk/pull/25237/files/84fb0903..1b8fb830 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=00-01 Stats: 69 lines in 1 file changed: 69 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25237/head:pull/25237 PR: https://git.openjdk.org/jdk/pull/25237 From acobbs at openjdk.org Thu May 15 17:48:50 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 15 May 2025 17:48:50 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops In-Reply-To: References: Message-ID: <5ftJn6TBx1Ig47gp6OywxkkcOM_jepkpJzmILDnf8dE=.d6fdb8b8-94c0-44fe-80b4-cc047acbc9b9@github.com> On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs wrote: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. I added a benchmark to the PR (hopefully I did that right). It shows a _decrease_ in performance. I have no idea why. I did this on my laptop so who knows, but if the effect is real then it kind of raises a lot of larger questions. jdk-25+22-94-g0318e49500e (master): Benchmark Mode Cnt Score Error Units ArrayDeque.ClearBenchmarkTestJMH.fillAndClear thrpt 50 37.064 ? 0.225 ops/s jdk-25+22-95-g84fb0903be0 (JDK-8356993): Benchmark Mode Cnt Score Error Units ArrayDeque.ClearBenchmarkTestJMH.fillAndClear thrpt 50 35.528 ? 0.180 ops/s ------------- PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884609647 From forax at openjdk.org Thu May 15 17:53:00 2025 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 15 May 2025 17:53:00 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 17:46:39 GMT, Archie Cobbs wrote: >> Please review this small performance tweak `ArrayDeque`. >> >> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add benchmark for ArrayDeque.clear(). test/jdk/java/util/ArrayDeque/ClearBenchmarkTestJMH.java line 64: > 62: @Measurement(iterations = 10) > 63: @Warmup(iterations = 3) > 64: public void fillAndClear() { I think you need to return the collection or send it to a BlackHole ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091698886 From duke at openjdk.org Thu May 15 17:54:51 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:54:51 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Tue, 13 May 2025 06:12:11 GMT, Alan Bateman wrote: >> Is this comment just agreeing with the proposed behaviour stated here? >> >> At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests). >> >> The only allowed access mode options with "create" are "readWrite" or , and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured. > > I agree that read-only && create is a combination to be rejected. My comment is about the update to the description of the "create" option. It's the first row in the table and the changes suggests that it is forcing the file system to be read-write. I think the wording for the "readOnly" option is sufficient, meaning just one place to document the conflict between these two options. Restored the original comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091701008 From duke at openjdk.org Thu May 15 17:54:53 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:54:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Mon, 12 May 2025 20:12:53 GMT, David Beaumont wrote: >> src/jdk.zipfs/share/classes/module-info.java line 281: >> >>> 279: * Even if a zip file system is writable ({@code fs.isReadOnly() == false}), >>> 280: * this says nothing about whether individual files can be created or >>> 281: * modified, simply that it might be possible. >> >> Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean? > > Hmm, you're right, it's not totally clear. It's trying to draw the same sort of distinction that you have with mounted file systems, in which the mode that something is mounted in doesn't override any underlying read-only state. > > For example you can still open a ZipFileSystem for a ZIP file which is on a remote drive, where the permissions show the underlying file as "writable", but an attempt to modify the contents would still fail. > > The POSIX stuff is mentioned at the end, and while it's related, it's not quite the same point. After thinking about it, I removed the sentence it only applied in edge cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091701964 From duke at openjdk.org Thu May 15 17:54:54 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 17:54:54 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Wed, 14 May 2025 17:04:01 GMT, Lance Andersen wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment based on current behaviour. > > test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 207: > >> 205: Map.of("create", true, "accessMode", "badValue"))); >> 206: } >> 207: > > You could simplify the above tests using a DataProvider similar to > > @DataProvider(name = "zipfsMap") > protected Object[][] zipfsMap() { > return new Object[][]{ > {Map.of(), NoSuchFileException.class}, > {Map.of("accessMode", "readOnly"), NoSuchFileException.class}, > {Map.of("accessMode", "readWrite"), NoSuchFileException.class}, > {Map.of("create", true, "accessMode", "readOnly"), IllegalArgumentException.class}, > {Map.of("create", true, "accessMode", "badValue"), IllegalArgumentException.class}, > }; > @Test(dataProvider = "zipfsMap?) > public void testZipFSCreationException(Map env, Class exception) throws Exception { > assertThrows(exception, () -> FileSystems.newFileSystem(noSuchZip, env)); > } Done. Thanks for giving the example, it really helped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091698261 From acobbs at openjdk.org Thu May 15 17:58:52 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 15 May 2025 17:58:52 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2] In-Reply-To: References: Message-ID: <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com> On Thu, 15 May 2025 17:50:30 GMT, R?mi Forax wrote: > I think you need to return the collection or send it to a BlackHole I'm fairly new to the benchmark game so I would not be surprised if this is broken. Previously I was adding them to a list but that caused OOMs. Can you clarify what you mean? By 'return' do you just mean returning the deque from the method? Also I don't konw what a BlackHole is. Apologies for not knowing what I'm doing here. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091707587 From alan.bateman at oracle.com Thu May 15 18:00:06 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 15 May 2025 19:00:06 +0100 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: References: Message-ID: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> On 15/05/2025 17:52, Thomas St?fe wrote: > : > > However,? we also could just get rid of vfork. That would simplify > things alot. We have moved to posix_spawn-by-default with JDK 13 in > 2019 (https://bugs.openjdk.org/browse/JDK-8213192). That is a long > time ago; probably long enough to ween all customers off vfork use. > > What do people think? > I haven't see any complaints or JBS issues since the change in JDK 13.? It's possible that there deployments running with jdk.lang.Process.launchMechanism set to vfork but my guess is that this configuration knob isn't widely known. If there are deployments doing this then there must be some reason, and I think we would have heard about it via a JBS issue by now. I checked the JDK release notes.? The property was documented in the JDK 12 release notes. The release note in JDK 13 about the move to posix_spawn didn't name the property to go back to vfork. So my initial reaction is that removing vfork would not be disruptive. -Alan From rgiulietti at openjdk.org Thu May 15 18:14:53 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 18:14:53 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods In-Reply-To: References: Message-ID: On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen wrote: > Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. @wenshao I understand this is a kind of followup of #24982, but why this title? It seems just renaming some methods with more speaking names. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2884680422 From duke at openjdk.org Thu May 15 18:16:59 2025 From: duke at openjdk.org (duke) Date: Thu, 15 May 2025 18:16:59 GMT Subject: Withdrawn: 8352489: Relax jspawnhelper version checks to informative In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev wrote: > See the bug for rationale. > > This goal for this improvement is to be easily backportable, so we can catch up with update releases. As such, it does a few borderline-trivial changes, and _does not_ change the jspawnhelper protocol. So the overwrite of `jspawnhelper` with this new version would be "compatible" in a very weak sense of the word. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/lang/ProcessBuilder` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24127 From duke at openjdk.org Thu May 15 18:27:35 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 15 May 2025 18:27:35 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Changes based on review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/9b356a24..2326999b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=02-03 Stats: 66 lines in 3 files changed: 6 ins; 30 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From naoto at openjdk.org Thu May 15 18:32:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 May 2025 18:32:53 GMT Subject: RFR: 8356977: UTF-8 cleanups In-Reply-To: References: Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com> On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie wrote: > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. test/jdk/sun/text/resources/LocaleDataTest.java line 106: > 104: * FormatData/fr_FR/MonthNames/0=janvier > 105: * FormatData/fr_FR/MonthNames/1=f?vrier > 106: * LocaleNames/fr_FR/US=?tats-Unis This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029 From rgiulietti at openjdk.org Thu May 15 18:35:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 18:35:51 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2] In-Reply-To: <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com> References: <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com> Message-ID: On Thu, 15 May 2025 17:56:10 GMT, Archie Cobbs wrote: >> test/jdk/java/util/ArrayDeque/ClearBenchmarkTestJMH.java line 64: >> >>> 62: @Measurement(iterations = 10) >>> 63: @Warmup(iterations = 3) >>> 64: public void fillAndClear() { >> >> I think you need to return the collection or send it to a BlackHole > >> I think you need to return the collection or send it to a BlackHole > > I'm fairly new to the benchmark game so I would not be surprised if this is broken. > > Previously I was adding them to a list but that caused OOMs. > > Can you clarify what you mean? By 'return' do you just mean returning the deque from the method? Also I don't konw what a BlackHole is. > > Apologies for not knowing what I'm doing here. Thanks. Here are many [exmaples](https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples) on how to correctly use JMH. A [blackhole](https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_09_Blackholes.java) prevents the compiler to optimize away your code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091761040 From henryjen at openjdk.org Thu May 15 18:37:08 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 15 May 2025 18:37:08 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v7] In-Reply-To: References: Message-ID: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Move all validation into EntryValidator, update the document ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/e0eff6ef..1150fb50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=05-06 Stats: 212 lines in 4 files changed: 105 ins; 22 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From jlu at openjdk.org Thu May 15 18:52:53 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 May 2025 18:52:53 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() [v2] In-Reply-To: References: Message-ID: On Sun, 11 May 2025 08:42:41 GMT, Abhishek N wrote: >> Create a Test case to have special cases coverage for currency.getInstance(). >> >> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API. >> >> test results: >> >> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java >> Directory "JTwork" not found: creating >> Directory "JTreport" not found: creating >> Test results: passed: 1 >> Report written to JTreport\html\report.html >> Results written to JTwork > > Abhishek N has updated the pull request incrementally with one additional commit since the last revision: > > correcting jtreg header order, add meaningful comments for each test methods and properties file This test is not effectively testing standard ISO 4217 future transition currencies. For example, with your patch, if I supply the following changes to the ISO 4217 currency data: (i.e. Make country `LK` have a transition currency of `XCH` in July) --- a/src/java.base/share/data/currency/CurrencyData.properties +++ b/src/java.base/share/data/currency/CurrencyData.properties @@ -55,7 +55,7 @@ all=ADP020-AED784-AFA004-AFN971-ALL008-AMD051-ANG532-AOA973-ARS032-ATS040-AUD036 SRD968-SRG740-SSP728-STD678-STN930-SVC222-SYP760-SZL748-THB764-TJS972-TMM795-TMT934-TND788-TOP776-\ TPE626-TRL792-TRY949-TTD780-TWD901-TZS834-UAH980-UGX800-USD840-USN997-USS998-UYI940-\ UYU858-UZS860-VEB862-VED926-VEF937-VES928-VND704-VUV548-WST882-XAF950-XAG961-XAU959-XBA955-\ - XBB956-XBC957-XBD958-XCD951-XCG532-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\ + XBB956-XBC957-XBD958-XCD951-XCG532-XCH533-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\ XPT962-XSU994-XTS963-XUA965-XXX999-YER886-YUM891-ZAR710-ZMK894-ZMW967-ZWD716-ZWG924-\ ZWL932-ZWN942-ZWR935 @@ -502,7 +502,7 @@ GS=GBP # SPAIN ES=EUR # SRI LANKA -LK=LKR +LK=LKR;2025-07-01-04-00-00;XCH and break some functionality related to _future/special_ currencies in `Currency.getInstance(String)`, (Similar to 8, prior to the fix backported) --- a/src/java.base/share/classes/java/util/Currency.java +++ b/src/java.base/share/classes/java/util/Currency.java @@ -326,13 +326,6 @@ private static Currency getInstance(String currencyCode, int defaultFractionDigi defaultFractionDigits = (tableEntry & SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_MASK) >> SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_SHIFT; numericCode = (tableEntry & NUMERIC_CODE_MASK) >> NUMERIC_CODE_SHIFT; found = true; - } else { //special case - int[] fractionAndNumericCode = SpecialCaseEntry.findEntry(currencyCode); - if (fractionAndNumericCode != null) { - defaultFractionDigits = fractionAndNumericCode[0]; - numericCode = fractionAndNumericCode[1]; - found = true; - } } With the above changes, we would expect this test to fail, since `getInstance("XCH")` should throw an exception. However, your test still passes. What this patch is doing is selectively testing a handful of Currencies with the system property override. This is not sufficient to ensure test coverage for testing a standard ISO 4217 transition currency after the transition date has passed. As mentioned above, the system property override does not mock a standard ISO 4217 transition currency, (they have different functionality). Also as @weibxiao has mentioned, we already have such a test in mainline. Additional testing would be required as backports for LTS releases only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2884773970 From vromero at openjdk.org Thu May 15 19:07:37 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 May 2025 19:07:37 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v14] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: update warning message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/22acaf29..bdbcd332 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From alanb at openjdk.org Thu May 15 19:12:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 May 2025 19:12:52 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: <71l9wpZh5nV-zhaS25IHhhovPGu1FqOAHBI8QUmUZhI=.f1a0620c-322a-4933-9438-ddfe1c0caa99@github.com> On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25109#pullrequestreview-2844740491 From mullan at openjdk.org Thu May 15 19:31:54 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 May 2025 19:31:54 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3] In-Reply-To: References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com> <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com> Message-ID: On Tue, 13 May 2025 14:01:10 GMT, Artur Barashev wrote: > > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code). > > @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this. > > @seanjmullan What do you think? Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2884859280 From vromero at openjdk.org Thu May 15 19:32:59 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 May 2025 19:32:59 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13] In-Reply-To: References: Message-ID: <2oFLdya1PI3WV3lloInRQG1oHs3k2gNhmZjv-V-OLrg=.8e5773fa-4993-4ef1-9e78-7899fa86fd4c@github.com> On Wed, 14 May 2025 18:23:09 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8354556 >> - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java >> >> Co-authored-by: Chen Liang >> - additional changes from Archie >> - removing dead code >> - integrating code from Archie >> - fixing bugs, removing dead code >> - additional documentation changes and bug fixes >> - documentation and adding alias to lint categories >> - Merge branch 'master' into JDK-8354556 >> - addressing review comment >> - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2673: > >> 2671: result = check(tree, capturedRes, KindSelector.VAL, resultInfo); >> 2672: } >> 2673: if (env.info.lint.isEnabled(LintCategory.IDENTITY)) { > > This is the only place where there's a check whether the lint is enabled before the call to `checkRequiresIdentity`. Is there a reason for that? left over of the initial approach I guess. I will remove it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2091837488 From naoto at openjdk.org Thu May 15 19:36:02 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 May 2025 19:36:02 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests Message-ID: Removing now-defunct COMPAT locale provider tests. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/25257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25257&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357075 Stats: 8496 lines in 2 files changed: 0 ins; 8484 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25257/head:pull/25257 PR: https://git.openjdk.org/jdk/pull/25257 From vromero at openjdk.org Thu May 15 19:48:55 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 May 2025 19:48:55 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:25:26 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8354556 >> - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java >> >> Co-authored-by: Chen Liang >> - additional changes from Archie >> - removing dead code >> - integrating code from Archie >> - fixing bugs, removing dead code >> - additional documentation changes and bug fixes >> - documentation and adding alias to lint categories >> - Merge branch 'master' into JDK-8354556 >> - addressing review comment >> - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5671: > >> 5669: } >> 5670: >> 5671: void checkRequiresIdentity(JCTree tree, Lint lint) { > > For consideration: as far as I can see, we have a sharp(er) type when we call `checkRequiresIdentity`, but we give up the type, and re-instante it here using the pattern matching switch. I wonder if it would be more elegant (and hopefully not really too much longer) if the `checkRequiresIdentity` method would have multiple overloads, with the sharp(er) types, like `JCClassDecl`/`JCVariableDecl`, etc. > > Or is there a reason to given up the sharp(er) type and re-create it using the switch? I guess the motivation was to have all this related code in one place, if this code is split into several overloaded methods then I guess an entity, a class, should probably be defined to contain all this code. Dunno I guess the current solution seemed more self-contained to me ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2091858747 From duke at openjdk.org Thu May 15 19:55:53 2025 From: duke at openjdk.org (ExE Boss) Date: Thu, 15 May 2025 19:55:53 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2] In-Reply-To: References: Message-ID: <-e84j1Q5W39W8HRZmgrMWo-S9hyrLhZneLYeU81CoHc=.0d9bc5bc-1a9d-4079-af7e-12ab21c5ba1c@github.com> On Thu, 15 May 2025 17:46:39 GMT, Archie Cobbs wrote: >> Please review this small performance tweak `ArrayDeque`. >> >> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add benchmark for ArrayDeque.clear(). Note?that `Arrays.fill(?)` is?simply a?`for(?)`?loop with?an?additional range?check and?is?potentially subject to?profile?pollution due?to?[JDK?8015417]: [JDK?8015417]: https://bugs.openjdk.org/browse/JDK-8015417 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884908080 From acobbs at openjdk.org Thu May 15 20:07:53 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 15 May 2025 20:07:53 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2] In-Reply-To: <-e84j1Q5W39W8HRZmgrMWo-S9hyrLhZneLYeU81CoHc=.0d9bc5bc-1a9d-4079-af7e-12ab21c5ba1c@github.com> References: <-e84j1Q5W39W8HRZmgrMWo-S9hyrLhZneLYeU81CoHc=.0d9bc5bc-1a9d-4079-af7e-12ab21c5ba1c@github.com> Message-ID: On Thu, 15 May 2025 19:53:03 GMT, ExE Boss wrote: > Note that `Arrays.fill(?)` is simply a `for(?)` loop with an additional range check Interesting... I was assuming that most of the "bulk" methods in `Arrays` were being hand-optimized with special hardware magic (e.g., vector instructions), and that the opportunity to do this was part of the motivation for adding them in the first place. If C2 is already able to automatically optimize this into the maximum possible hardware performance, then great! But is that actually the case? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884933648 From joehw at openjdk.org Thu May 15 20:26:53 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 15 May 2025 20:26:53 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests In-Reply-To: References: Message-ID: On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato wrote: > Removing now-defunct COMPAT locale provider tests. Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2844891980 From vromero at openjdk.org Thu May 15 20:29:16 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 May 2025 20:29:16 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v15] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/bdbcd332..6c8d2b1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=13-14 Stats: 21 lines in 2 files changed: 1 ins; 12 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From paul.sandoz at oracle.com Thu May 15 20:30:42 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 May 2025 20:30:42 +0000 Subject: Towards a JSON API for the JDK Message-ID: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Hi, We would like to share with you our thoughts and plans towards a JSON API for the JDK. Please see the document below. - We have had the pleasure of using a clone of this API in some experiments we are conducting with ONNX and code reflection [1]. Using the API we were able to quickly write code to ingest and convert a JSON document representing ONNX operation schema into instances of records modeling the schema (see here [2]). The overall out-of-box experience with such a minimal "batteries included? API has so far been positive. Thanks, Paul. [1] https://openjdk.org/projects/babylon/ [2] https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 # Towards a JSON API for the JDK One of the most common requests for the JDK is an API for parsing and generating JSON. While JSON originated as a text-based serialization format for JSON objects ("JSON" stands for "JavaScript Object Notation"), because of its simple and flexible syntax, it eventually found use outside the JavaScript ecosystem as a general data interchange format, such as framework configuration files and web service requests/response formats. While the JDK cannot, and should not, provide libraries for every conceivable file format or protocol, the JDK philosophy is one of "batteries included", which is to say we should be able to write basic programs that use common protocols such as HTTP, without having to appeal to third party libraries. The Java ecosystem already has plenty of JSON libraries, so inclusion in the JDK is largely meant to be a convenience, rather than needing to be the "one true" JSON library to meet the needs of all users. Users with specific needs are always free to select one of the existing third-party libraries. ## Goals and requirements Our primary goal is that the library be simple to use for parsing, traversing, and generating conformant JSON documents. Advanced features, such as data binding or path-based traversal should be possible to implement as layered features, but for simplicity are not included in the core API. We adopt a goal that the performance should be "good enough", but where performance considerations conflict with simplicity and usability, we will choose in favor of the latter. ## API design approach The description of JSON at `https:://json.org` describes a JSON document using the familiar "railroad diagram": ![image](https://www.json.org/img/value.png) This diagram describes an algebraic data type (a sum of products), which we model directly with a set of Java interfaces: ``` interface JsonValue { } interface JsonArray extends JsonValue { List values(); } interface JsonObject extends JsonValue { Map members(); } interface JsonNumber extends JsonValue { Number toNumber(); } interface JsonString extends JsonValue { String value(); } interface JsonBoolean extends JsonValue { boolean value(); } interface JsonNull extends JsonValue { } ``` These interfaces have (hidden) companion implementation classes that admit greater flexibility of implementation than modeling them directly with records would permit. Further, these interfaces are unsealed. We compromise on the sealed sum of products to enable alternative implementations, for example to support alternative formats that encode the same information in a JSON document but in a more efficient form than text. The API has static methods for parsing strings into a `JsonValue`, conversion to and from purely untyped representations (lists and maps), and factory methods for building JSON documents. We apply composition consistently, e.g, a JsonString has a string, a JsonObject has a map of string to JsonValue, as opposed to extension for structural JSON values. It turns out that this simple API is almost all we need for traversal. It gives us an immutable representation of a document, and we can use pattern matching to answer the myriad questions that will come up (Does this object have key X? Does it map to a number? Is that number representable as an integer?) when going from an untyped format like JSON to a more strongly typed domain model. Given a simple document like: ``` { "name": "John?, "age": 30 } ``` we can parse and traverse the document as follows: ``` JsonValue doc = Json.parse(inputString); if (doc instanceof JsonObject o && o.members().get("name") instanceof JsonString s && s.value() instanceof String name && o.members().get("age") instanceof JsonNumber n && n.toNumber() instanceof Long l && l instanceof int age) { // use "name" and "age" } ``` Later, when the language acquires the ability to expose deconstruction patterns for arbitrary interfaces (similar to today's record patterns, see https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), this will be simplifiable to: ``` JsonValue doc = Json.parse(inputString); if (doc instanceof JsonObject(var members) && members.get("name") instanceof JsonString(String name) && members.get("age") instanceof JsonNumber(int age)) { // use "name" and "age" } ``` So, overtime, as more pattern matching features are introduced we anticipate improved use of the API. This is a primary reason why the API is so minimal. Convenience methods we add today, such as a method that accesses a JSON object component as say a JSON string or throws an exception, will become redundant in the future. ## JSON numbers The specification of JSON number makes no explicit distinction between integral and decimal numbers, nor specifies limits on the size of those numbers. This is a common source of interoperability issues when consuming JSON documents. Generally users cannot always but often do assume JSON numbers are parsable, without loss of precision, to IEEE double-precision floating point numbers or 32-bit signed integers. In this respect the API provides three means to operate on the JSON number, giving the user full control: 1. Underlying string representation can be obtained, if preserving syntactic details such as leading or trailing zeros is important. 2. The string representation can be parsed to an instance of `BigDecimal`, using `toBigDecimal` if preserving decimal numbers is important. 3. The string representation can be parsed into an instance of `Long`, `Double`, `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method depends on how the representation can be parsed, possibly losing precision, choosing a suitably convenient numeric type that can then be pattern matched on. Primitive pattern matching will help as will further pattern matching features enabling the user to partially match. ## Prototype implementation The prototype implementation is currently located into the JDK sandbox repository under the `json` branch, see here https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json The prototype API javadoc generated from the repository is also available at https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html ### Testing and conformance The prototype implementation passes all conformance test cases but two, available on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which the prototype specifically prohibits, i.e, duplicated names in JSON objects (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). ### Performance Our main focus so far has been on the API design and a functional implementation. Hence, there has been less focus on performance even though we know there are a number of performance enhancements we can make eventually. We are reasonably happy with the current performance. The implementation performs well when compared to other JSON implementations parsing from string instances and traversing documents. An example of where we may choose simplicity and usability over performance is the rejection of JSON documents containing objects that in turn contain members with duplicate names. That may increase the cost of parsing, but simplifies the user experience for the majority of cases since if we reasonably assume JsonObjects are map-like, what should the user do with such members, pick one the last one? merge the values? or reject? ## A JSON JEP? We plan to draft JEP when we are ready. Attentive readers will observe that a JEP already exists, JEP 198: Light-Weight JSON API (https://openjdk.org/jeps/198). We will either update this JEP, or withdraw it and draft a new one. From wxiao at openjdk.org Thu May 15 20:32:54 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Thu, 15 May 2025 20:32:54 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() [v2] In-Reply-To: References: Message-ID: On Sun, 11 May 2025 08:42:41 GMT, Abhishek N wrote: >> Create a Test case to have special cases coverage for currency.getInstance(). >> >> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API. >> >> test results: >> >> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java >> Directory "JTwork" not found: creating >> Directory "JTreport" not found: creating >> Test results: passed: 1 >> Report written to JTreport\html\report.html >> Results written to JTwork > > Abhishek N has updated the pull request incrementally with one additional commit since the last revision: > > correcting jtreg header order, add meaningful comments for each test methods and properties file The test case, by using example data "CW=ANG;2099-04-01-04-00-00;XCG", when Currency.getInstance ("XCG) is called; instead failing, it will work by overwriting System::currentTimeMillis. This call will return any future time. This will allow the currency XG to be a valid currency. It verifies the future currency at current time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2884983555 From liach at openjdk.org Thu May 15 20:35:04 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 15 May 2025 20:35:04 GMT Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v15] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:56:37 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. >> >> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. >> >> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > More suggestions from viktor Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2884986670 From liach at openjdk.org Thu May 15 20:35:05 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 15 May 2025 20:35:05 GMT Subject: Integrated: 8351996: Behavioral updates for ClassValue::remove In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 00:01:21 GMT, Chen Liang wrote: > The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method. > > The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix. > > The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects. > > Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well. This pull request has now been integrated. Changeset: 9223ed78 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/9223ed788a53820dcc1e285a6e0df0c97b05fb09 Stats: 646 lines in 2 files changed: 387 ins; 137 del; 122 mod 8351996: Behavioral updates for ClassValue::remove Co-authored-by: John R Rose Reviewed-by: vklang, jrose ------------- PR: https://git.openjdk.org/jdk/pull/24043 From bpb at openjdk.org Thu May 15 20:36:59 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 May 2025 20:36:59 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com> Message-ID: On Thu, 15 May 2025 05:53:44 GMT, Markus KARG wrote: >> @mkarg Please don't invoke my name to try to buttress your arguments. The calls the Reader.of() instance makes on its backing CharSequence is a different kind of issue from what promises or guarantees the concrete methods of the Reader class makes to its subclasses. > > @stuart-marks Sorry, didn't want to pull you in here, that's why I said, I am just *paraphrasing*. > > That is correct, it is a different case, but the *final effect* for the caller is the same: If he needs to now whether a copy is made *or not*, he needs to have JavaDocs telling him *how* the new method works inside (whether it calls `subSequence` or whether it calls `getChars`). Otherwise he might make false assumptions about the result. This API is concerned with the "what" and not so much the "how." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2091919761 From jlu at openjdk.org Thu May 15 20:43:54 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 May 2025 20:43:54 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests In-Reply-To: References: Message-ID: On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato wrote: > Removing now-defunct COMPAT locale provider tests. Nice cleanup; lgtm test/jdk/sun/text/resources/LocaleDataTest.java line 178: > 176: public class LocaleDataTest > 177: { > 178: static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr"; Suggestion: static final String TEXT_RESOURCES_PACKAGE = "sun.text.resources.cldr"; test/jdk/sun/text/resources/LocaleDataTest.java line 179: > 177: { > 178: static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr"; > 179: static final String UTIL_RESOURCES_PACKAGE ="sun.util.resources.cldr"; Suggestion: static final String UTIL_RESOURCES_PACKAGE = "sun.util.resources.cldr"; test/jdk/sun/text/resources/LocaleDataTest.java line 180: > 178: static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr"; > 179: static final String UTIL_RESOURCES_PACKAGE ="sun.util.resources.cldr"; > 180: static final String DEFAULT_DATAFILE ="LocaleData.cldr"; Suggestion: static final String DEFAULT_DATAFILE = "LocaleData.cldr"; ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2844921929 PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926227 PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926415 PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926586 From naoto at openjdk.org Thu May 15 20:53:10 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 May 2025 20:53:10 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2] In-Reply-To: References: Message-ID: > Removing now-defunct COMPAT locale provider tests. Naoto Sato has updated the pull request incrementally with three additional commits since the last revision: - Update test/jdk/sun/text/resources/LocaleDataTest.java Co-authored-by: Justin Lu - Update test/jdk/sun/text/resources/LocaleDataTest.java Co-authored-by: Justin Lu - Update test/jdk/sun/text/resources/LocaleDataTest.java Co-authored-by: Justin Lu ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25257/files - new: https://git.openjdk.org/jdk/pull/25257/files/5112a966..b9cf8d18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25257&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25257&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25257/head:pull/25257 PR: https://git.openjdk.org/jdk/pull/25257 From naoto at openjdk.org Thu May 15 20:53:10 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 May 2025 20:53:10 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2] In-Reply-To: References: Message-ID: <8X53b-CEba172PLu24gc0HukUUfBc5egPMqMGiKnXmA=.8a512b9c-4684-4181-985e-e2fe178b5c09@github.com> On Thu, 15 May 2025 20:39:28 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update test/jdk/sun/text/resources/LocaleDataTest.java >> >> Co-authored-by: Justin Lu >> - Update test/jdk/sun/text/resources/LocaleDataTest.java >> >> Co-authored-by: Justin Lu >> - Update test/jdk/sun/text/resources/LocaleDataTest.java >> >> Co-authored-by: Justin Lu > > test/jdk/sun/text/resources/LocaleDataTest.java line 178: > >> 176: public class LocaleDataTest >> 177: { >> 178: static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr"; > > Suggestion: > > static final String TEXT_RESOURCES_PACKAGE = "sun.text.resources.cldr"; Thanks. Committed with others ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091940230 From acobbs at openjdk.org Thu May 15 21:04:40 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 15 May 2025 21:04:40 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v3] In-Reply-To: References: Message-ID: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Blackhole ArrayDeque to ensure it's not ignored by the compiler. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25237/files - new: https://git.openjdk.org/jdk/pull/25237/files/1b8fb830..9f0c5fe1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25237/head:pull/25237 PR: https://git.openjdk.org/jdk/pull/25237 From acobbs at openjdk.org Thu May 15 21:04:40 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 15 May 2025 21:04:40 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2] In-Reply-To: References: <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com> Message-ID: <_3B3G3M1DvwY5x6FZYu--qj9acrcToP-oIPp1zFpaUQ=.74790f82-8962-484d-9732-db06680e2442@github.com> On Thu, 15 May 2025 18:33:22 GMT, Raffaello Giulietti wrote: > Here are many [exmaples](https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples) on how to correctly use JMH. > > A [blackhole](https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_09_Blackholes.java) prevents the compiler to optimize away your code. Thanks for the tip. FWIW after doing that the numbers came out about the same - which is not surprising given that `Arrays.fill()` is just the same `for()` loop... #2 - After adding Blackhole jdk-25+22-94-g0318e49500e (master): Benchmark Mode Cnt Score Error Units ArrayDeque.ClearBenchmarkTestJMH.fillAndClear thrpt 50 35.663 ? 0.163 ops/s jdk-25+22-97-g9f0c5fe1f90 (JDK-8356993): Benchmark Mode Cnt Score Error Units ArrayDeque.ClearBenchmarkTestJMH.fillAndClear thrpt 50 35.112 ? 0.501 ops/s ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091954179 From ccheung at openjdk.org Thu May 15 21:17:03 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 21:17:03 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 03:22:32 GMT, Ioi Lam wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > I think we need a test to validate that the `--add-reads` flag actually works. I wrote such a test when I implemented `--add-exports`: see [runtime/cds/appcds/jigsaw/modulepath/AddExports.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddExports.java) > > I think we need a similar test for `--add-opens` as well. > > Since the main reason for supporting `--add-{expors,opens,reads}` is for user of AOT class linking, I would suggest moving the above AddExports.java test to > > - runtime/cds/appcds/aotClassLinking/modules/AddExports.java > > And then add AddReads.java and AddOpens.java there as well. > > The reason for putting the tests inside aotClassLinking is that they will be excluded from the `hotspot_appcds_dynamic` and `hotspot_aot_classlinking` test groups, so you don't need to add special case code to handle those two test groups. Thanks @iklam @AlanBateman for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2885067118 From ccheung at openjdk.org Thu May 15 21:17:04 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 21:17:04 GMT Subject: Integrated: 8354083: Support --add-reads with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 00:19:17 GMT, Calvin Cheung wrote: > This fix adds the `--add-reads` support for CDS and AOTClassLinking. > Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: > `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` > During runtime, the archived full module graph will be disabled: > `[0.021s][info][cds ] full module graph: disabled` > > With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. > > Testing: tiers 1 - 4. This pull request has now been integrated. Changeset: efdbb6af Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/efdbb6afce4116140c066641128264ab42697912 Stats: 723 lines in 9 files changed: 443 ins; 277 del; 3 mod 8354083: Support --add-reads with -XX:+AOTClassLinking Reviewed-by: iklam, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25109 From forax at univ-mlv.fr Thu May 15 21:27:57 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 15 May 2025 23:27:57 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Message-ID: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Hi Paul, yes, not having a simple JSON API in Java is an issue for beginners. It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? I understand why Json.parse() only works on String and char[] but the API make it too easy to have many performance issues. I think you need versions using a Reader and a Path. Bonus point, if there is a method walk() that also returns a JsonValue but the List/Map inside JsonArray/JsonObject are populated lazily. Minor point: Json.toDisplayString() should takes a second parameters indicating the number of spaces used for the indentation (like JSON.stringify in JS). regards, R?mi ----- Original Message ----- > From: "Paul Sandoz" > To: "core-libs-dev" > Sent: Thursday, May 15, 2025 10:30:42 PM > Subject: Towards a JSON API for the JDK > Hi, > > We would like to share with you our thoughts and plans towards a JSON API for > the JDK. > Please see the document below. > > - > > We have had the pleasure of using a clone of this API in some experiments we are > conducting with > ONNX and code reflection [1]. Using the API we were able to quickly write code > to ingest and convert > a JSON document representing ONNX operation schema into instances of records > modeling the schema > (see here [2]). > > The overall out-of-box experience with such a minimal "batteries included? API > has so far been positive. > > Thanks, > Paul. > > [1] https://openjdk.org/projects/babylon/ > [2] > https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 > > # Towards a JSON API for the JDK > > One of the most common requests for the JDK is an API for parsing and generating > JSON. While JSON originated as a text-based serialization format for JSON > objects ("JSON" stands for "JavaScript Object Notation"), because of its simple > and flexible syntax, it eventually found use outside the JavaScript ecosystem as > a general data interchange format, such as framework configuration files and web > service requests/response formats. > > While the JDK cannot, and should not, provide libraries for every conceivable > file format or protocol, the JDK philosophy is one of "batteries included", > which is to say we should be able to write basic programs that use common > protocols such as HTTP, without having to appeal to third party libraries. > The Java ecosystem already has plenty of JSON libraries, so inclusion in > the JDK is largely meant to be a convenience, rather than needing to be the "one > true" JSON library to meet the needs of all users. Users with specific needs > are always free to select one of the existing third-party libraries. > > ## Goals and requirements > > Our primary goal is that the library be simple to use for parsing, traversing, > and generating conformant JSON documents. Advanced features, such as data > binding or path-based traversal should be possible to implement as layered > features, but for simplicity are not included in the core API. We adopt a goal > that the performance should be "good enough", but where performance > considerations conflict with simplicity and usability, we will choose in favor > of the latter. > > ## API design approach > > The description of JSON at `https:://json.org` describes a JSON document using > the familiar "railroad diagram": > ![image](https://www.json.org/img/value.png) > > This diagram describes an algebraic data type (a sum of products), which we > model directly with a set of Java interfaces: > > ``` > interface JsonValue { } > interface JsonArray extends JsonValue { List values(); } > interface JsonObject extends JsonValue { Map members(); } > interface JsonNumber extends JsonValue { Number toNumber(); } > interface JsonString extends JsonValue { String value(); } > interface JsonBoolean extends JsonValue { boolean value(); } > interface JsonNull extends JsonValue { } > ``` > > These interfaces have (hidden) companion implementation classes that admit > greater flexibility of implementation than modeling them directly with records > would permit. > Further, these interfaces are unsealed. We compromise on the sealed sum of > products to enable > alternative implementations, for example to support alternative formats that > encode the same information in a JSON document but in a more efficient form than > text. > > The API has static methods for parsing strings into a `JsonValue`, conversion to > and from purely untyped representations (lists and maps), and factory methods > for building JSON documents. We apply composition consistently, e.g, a > JsonString has a string, a JsonObject has a map of string to JsonValue, as > opposed to extension for structural JSON values. > > It turns out that this simple API is almost all we need for traversal. It gives > us an immutable representation of a document, and we can use pattern matching to > answer the myriad questions that will come up (Does this object have key X? Does > it map to a number? Is that number representable as an integer?) when going > from an untyped format like JSON to a more strongly typed domain model. > Given a simple document like: > > ``` > { > "name": "John?, > "age": 30 > } > ``` > > we can parse and traverse the document as follows: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject o > && o.members().get("name") instanceof JsonString s > && s.value() instanceof String name > && o.members().get("age") instanceof JsonNumber n > && n.toNumber() instanceof Long l && l instanceof int age) { > // use "name" and "age" > } > ``` > > Later, when the language acquires the ability to expose deconstruction patterns > for arbitrary interfaces (similar to today's record patterns, see > https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), > this will be simplifiable to: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject(var members) > && members.get("name") instanceof JsonString(String name) > && members.get("age") instanceof JsonNumber(int age)) { > // use "name" and "age" > } > ``` > > So, overtime, as more pattern matching features are introduced we anticipate > improved use of the API. This is a primary reason why the API is so minimal. > Convenience methods we add today, such as a method that accesses a JSON > object component as say a JSON string or throws an exception, will become > redundant in the future. > > ## JSON numbers > > The specification of JSON number makes no explicit distinction between integral > and decimal numbers, nor specifies limits on the size of those numbers. > This is a common source of interoperability issues when consuming JSON > documents. Generally users cannot always but often do assume JSON numbers are > parsable, without loss of precision, to IEEE double-precision floating point > numbers or 32-bit signed integers. > > In this respect the API provides three means to operate on the JSON number, > giving the user full control: > > 1. Underlying string representation can be obtained, if preserving syntactic > details such as leading or trailing zeros is important. > 2. The string representation can be parsed to an instance of `BigDecimal`, using > `toBigDecimal` if preserving decimal numbers is important. > 3. The string representation can be parsed into an instance of `Long`, `Double`, > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method > depends on how the representation can be parsed, possibly losing precision, > choosing a suitably convenient numeric type that can then be pattern > matched on. > > Primitive pattern matching will help as will further pattern matching features > enabling the user to partially match. > > ## Prototype implementation > > The prototype implementation is currently located into the JDK sandbox > repository > under the `json` branch, see > here > https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json > The prototype API javadoc generated from the repository is also available at > https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html > > ### Testing and conformance > > The prototype implementation passes all conformance test cases but two, > available > on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which > the > prototype specifically prohibits, i.e, duplicated names in JSON objects > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). > > ### Performance > > Our main focus so far has been on the API design and a functional > implementation. > Hence, there has been less focus on performance even though we know there are a > number of performance enhancements we can make eventually. > We are reasonably happy with the current performance. The > implementation performs well when compared to other JSON implementations > parsing from string instances and traversing documents. > > An example of where we may choose simplicity and usability over performance > is the rejection of JSON documents containing objects that in turn contain > members > with duplicate names. That may increase the cost of parsing, but simplifies the > user > experience for the majority of cases since if we reasonably assume JsonObjects > are > map-like, what should the user do with such members, pick one the last one? > merge > the values? or reject? > > ## A JSON JEP? > > We plan to draft JEP when we are ready. Attentive readers will observe that > a JEP already exists, JEP 198: Light-Weight JSON API > (https://openjdk.org/jeps/198). We will > either update this JEP, or withdraw it and draft a new one. From duke at openjdk.org Thu May 15 21:37:52 2025 From: duke at openjdk.org (Hendrik Schick) Date: Thu, 15 May 2025 21:37:52 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner In-Reply-To: References: Message-ID: On Wed, 14 May 2025 23:51:36 GMT, Brent Christian wrote: > Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner. > > (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.) > > In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical. > > Details of note: > > 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state. > > The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same. > > Thanks. > > **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.** test/jdk/com/sun/jndi/ldap/CleanerTests/LdapEnumeration.ldap line 2: > 1: # > 2: # Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. Suggestion: # Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. (?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2091992166 From henryjen at openjdk.org Thu May 15 21:57:17 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 15 May 2025 21:57:17 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v8] In-Reply-To: References: Message-ID: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Adjust message based on review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/1150fb50..1bc1f8cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=06-07 Stats: 10 lines in 2 files changed: 3 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From swen at openjdk.org Thu May 15 22:01:51 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 15 May 2025 22:01:51 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:12:28 GMT, Raffaello Giulietti wrote: > @wenshao I understand this is a kind of followup of #24982, but why this title? It seems just renaming some methods with more speaking names. Yes, it is just a renaming of some methods, the title is followup #24982, does the same thing, so uses the same title ------------- PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2885146769 From henryjen at openjdk.org Thu May 15 22:03:52 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 15 May 2025 22:03:52 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v6] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 18:00:23 GMT, Henry Jen wrote: >> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127: >> >>> 125: >>> 126: public DedupEntryNames(boolean isCEN) { >>> 127: this.isCEN = isCEN; >> >> Might be clearer if this was an enum vs boolean? > > I feel the same way but wondering if that's an overkill. Refactored to consolidate validation on entries into a standalone EntryValidator. Hope that's easier to understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2092018706 From henryjen at openjdk.org Thu May 15 22:03:54 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 15 May 2025 22:03:54 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v6] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:28:34 GMT, Lance Andersen wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore Validator access level > > test/jdk/tools/jar/ValidatorTest.java line 232: > >> 230: var err = e.getMessage(); >> 231: System.out.println(err); >> 232: Assertions.assertTrue(err.contains("Warning: 2 copies of META-INF/MANIFEST.MF is detected in local file header")); > > Given you are importing Assertions, you should be able to just use `assertTrue` I didn't use static import. Since that seems to be preferred, I changed to do static imports. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2092017390 From rgiulietti at openjdk.org Thu May 15 22:05:56 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 22:05:56 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > make magBitLength() an instance method There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2885152927 From bpb at openjdk.org Thu May 15 22:09:55 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 May 2025 22:09:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com> Message-ID: <6R_dYDxxb9DRXAYBzENkNbRAn4rzQvNJmhd5KQPRj_g=.306a738b-b82b-4da4-a762-b7bd0cbe2f47@github.com> On Thu, 15 May 2025 11:01:36 GMT, Markus KARG wrote: >> Thanks for the examples. Imho I think that performance sensitive, specialised code can invest some lines to put together the best solution for the context whereas the majority of code can simply use a convenient `reader.readAllAsString()` instead of `reader.readAllAsCharSequence().toString()` which is borderline to parody. > > It is **impossible** to "invest some lines" to solve this in JAX-RS, and JAX-RS as a standard technology on tens of thousands of servers. Enforcing `String` prevents these useful optimizations, but brings *no actual benefit*, as *only few* callers actually care for *constant* objects, but would be satisfied with `CharSequence`'s lack of mutation methods. > Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object. What relation does such a "heap object" have to character streams? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2092023770 From vromero at openjdk.org Thu May 15 22:32:12 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 May 2025 22:32:12 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v16] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/6c8d2b1d..def2505f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=14-15 Stats: 18 lines in 1 file changed: 1 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Thu May 15 22:36:58 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 May 2025 22:36:58 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v13] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:27:18 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' into JDK-8354556 >> - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java >> >> Co-authored-by: Chen Liang >> - additional changes from Archie >> - removing dead code >> - integrating code from Archie >> - fixing bugs, removing dead code >> - additional documentation changes and bug fixes >> - documentation and adding alias to lint categories >> - Merge branch 'master' into JDK-8354556 >> - addressing review comment >> - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5823: > >> 5821: SymbolMetadata sm = t.tsym.getMetadata(); >> 5822: if (sm != null && !t.getTypeArguments().isEmpty()) { >> 5823: for (Attribute.TypeCompound ta: sm.getTypeAttributes().stream() > > The code here, and the code in `checkIfTypeParamsRequiresIdentity` look similar a lot (although they manipulate `List` and `List`, of course. I wonder if there's a chance to share the code, at least partially. I have rewritten both using streams, technically we could still reuse some code but not a big deal, dunno ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2092053355 From bpb at openjdk.org Thu May 15 22:42:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 May 2025 22:42:15 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v4] In-Reply-To: References: Message-ID: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. Brian Burkhalter 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: - 8355954: Simplify test - Merge - 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set - 8355954: Address comments on naming in the PR - 8355954: File.delete removes read-only files (win) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24977/files - new: https://git.openjdk.org/jdk/pull/24977/files/0fef4782..352c54dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=02-03 Stats: 53700 lines in 1729 files changed: 33644 ins; 11237 del; 8819 mod Patch: https://git.openjdk.org/jdk/pull/24977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977 PR: https://git.openjdk.org/jdk/pull/24977 From swen at openjdk.org Thu May 15 22:46:54 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 15 May 2025 22:46:54 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > make magBitLength() an instance method src/java.base/share/classes/java/math/BigInteger.java line 3860: > 3858: && Integer.lowestOneBit(mag[0]) == mag[0] > 3859: && numberOfTrailingZeroInts() == mag.length - 1 > 3860: ? magBitLength() - 1 : magBitLength(); Suggestion: int[] mag = this.mag; return magBitLength() - (signum < 0 // Check if magnitude is a power of two && Integer.lowestOneBit(mag[0]) == mag[0] && numberOfTrailingZeroInts() == mag.length - 1 ? 1 : 0); In this way, codeSize will drop from 52 to 45 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2092060927 From ethan at mccue.dev Thu May 15 23:44:52 2025 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 16 May 2025 01:44:52 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I present for your consideration the library I made when spiraling about this problem space a few years ago https://github.com/bowbahdoe/json https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html Notably missing during the design process here were patterns, hence the JsonDecoder design. I haven't been able to evaluate how patterns affect that on account of them not being out. I will more thoroughly peruse the draft of java.util.json at a later date, but my initial observations/comments: * I am not sure having JsonValue be distinct from Json has value. * toUntyped feels a little strange to me - the only type information presumably lost is the sealed-ness of the hierarchy. The interplay between that and toNumber is also a little unnerving. * One notion that I found helpful was that a class could be "json encodable," meaning there is a method to call to obtain a canonical json representation. record Person(String name) implements JsonEncodable { @Override public Json toJson() { return Json.objectBuilder() .put("namen", name) .build(); } } Which helper methods like Json#of(List) could make use of. Json itself (JsonValue in your prototype) could then have a vacuous implementation. * Terminology wise - I went with reading/writing for the actual parsing/generation of json and encoding/decoding for the mapping of those representations to/from specific classes. The merits are not top of mind, just noting the difference. read/write vs parse/toString+toDisplayString * One thing I did was make the helper methods in Json null tolerant and the ones in the specific subtypes like JsonString not. This was because from what I saw of usages of javax.json/jakarta.json that nullability was a footgun and correcting for it required changes to code structure (breaking up builder chains with if (x != null) checks) * The functionality you want from JsonNumber could be achieved by making it just extend Number ( https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java) instead of a bespoke toNumber. You need the extra methods to go to big decimal and co, but it's just an extension to the behavior of Number at that point. * JsonObject and JsonArray could implement Map and List respectively. This lowers the need for toUntyped() - since presumably one of the use cases for that is turning the json tree into something that more generic map/list traversal code can handle. It also complicates any lazy loading somewhat. * Assuming patterns can be placed on interfaces, you might want to consider something similar to JsonDecoder, but with a pattern instead of a method that throws an exception. // Where here fromJson would box up the logic for testing and extracting from each element in the array. List people = array(json, Person::fromJson); * I don't think there is sufficient cause for anything to be non-sealed at this point. * JsonBoolean and JsonNull do not have reasonable alternative implementations - as far as I can imagine, maybe i'm wrong - so maybe those can just be final classes? * If you seal up the whole hierarchy then its pretty trivial to make it serializable ( https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java ) On Thu, May 15, 2025 at 11:29?PM Remi Forax wrote: > Hi Paul, > yes, not having a simple JSON API in Java is an issue for beginners. > > It's not clear to me why JsonArray (for example) has to be an interface > instead of a record ? > > I understand why Json.parse() only works on String and char[] but the API > make it too easy to have many performance issues. > I think you need versions using a Reader and a Path. > Bonus point, if there is a method walk() that also returns a JsonValue but > the List/Map inside JsonArray/JsonObject are populated lazily. > > Minor point: Json.toDisplayString() should takes a second parameters > indicating the number of spaces used for the indentation (like > JSON.stringify in JS). > > regards, > R?mi > > ----- Original Message ----- > > From: "Paul Sandoz" > > To: "core-libs-dev" > > Sent: Thursday, May 15, 2025 10:30:42 PM > > Subject: Towards a JSON API for the JDK > > > Hi, > > > > We would like to share with you our thoughts and plans towards a JSON > API for > > the JDK. > > Please see the document below. > > > > - > > > > We have had the pleasure of using a clone of this API in some > experiments we are > > conducting with > > ONNX and code reflection [1]. Using the API we were able to quickly > write code > > to ingest and convert > > a JSON document representing ONNX operation schema into instances of > records > > modeling the schema > > (see here [2]). > > > > The overall out-of-box experience with such a minimal "batteries > included? API > > has so far been positive. > > > > Thanks, > > Paul. > > > > [1] https://openjdk.org/projects/babylon/ > > [2] > > > https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 > > > > # Towards a JSON API for the JDK > > > > One of the most common requests for the JDK is an API for parsing and > generating > > JSON. While JSON originated as a text-based serialization format for JSON > > objects ("JSON" stands for "JavaScript Object Notation"), because of its > simple > > and flexible syntax, it eventually found use outside the JavaScript > ecosystem as > > a general data interchange format, such as framework configuration files > and web > > service requests/response formats. > > > > While the JDK cannot, and should not, provide libraries for every > conceivable > > file format or protocol, the JDK philosophy is one of "batteries > included", > > which is to say we should be able to write basic programs that use common > > protocols such as HTTP, without having to appeal to third party > libraries. > > The Java ecosystem already has plenty of JSON libraries, so inclusion in > > the JDK is largely meant to be a convenience, rather than needing to be > the "one > > true" JSON library to meet the needs of all users. Users with specific > needs > > are always free to select one of the existing third-party libraries. > > > > ## Goals and requirements > > > > Our primary goal is that the library be simple to use for parsing, > traversing, > > and generating conformant JSON documents. Advanced features, such as data > > binding or path-based traversal should be possible to implement as > layered > > features, but for simplicity are not included in the core API. We adopt > a goal > > that the performance should be "good enough", but where performance > > considerations conflict with simplicity and usability, we will choose in > favor > > of the latter. > > > > ## API design approach > > > > The description of JSON at `https:://json.org` describes a JSON > document using > > the familiar "railroad diagram": > > ![image](https://www.json.org/img/value.png) > > > > This diagram describes an algebraic data type (a sum of products), which > we > > model directly with a set of Java interfaces: > > > > ``` > > interface JsonValue { } > > interface JsonArray extends JsonValue { List values(); } > > interface JsonObject extends JsonValue { Map > members(); } > > interface JsonNumber extends JsonValue { Number toNumber(); } > > interface JsonString extends JsonValue { String value(); } > > interface JsonBoolean extends JsonValue { boolean value(); } > > interface JsonNull extends JsonValue { } > > ``` > > > > These interfaces have (hidden) companion implementation classes that > admit > > greater flexibility of implementation than modeling them directly with > records > > would permit. > > Further, these interfaces are unsealed. We compromise on the sealed sum > of > > products to enable > > alternative implementations, for example to support alternative formats > that > > encode the same information in a JSON document but in a more efficient > form than > > text. > > > > The API has static methods for parsing strings into a `JsonValue`, > conversion to > > and from purely untyped representations (lists and maps), and factory > methods > > for building JSON documents. We apply composition consistently, e.g, a > > JsonString has a string, a JsonObject has a map of string to JsonValue, > as > > opposed to extension for structural JSON values. > > > > It turns out that this simple API is almost all we need for traversal. > It gives > > us an immutable representation of a document, and we can use pattern > matching to > > answer the myriad questions that will come up (Does this object have key > X? Does > > it map to a number? Is that number representable as an integer?) when > going > > from an untyped format like JSON to a more strongly typed domain model. > > Given a simple document like: > > > > ``` > > { > > "name": "John?, > > "age": 30 > > } > > ``` > > > > we can parse and traverse the document as follows: > > > > ``` > > JsonValue doc = Json.parse(inputString); > > if (doc instanceof JsonObject o > > && o.members().get("name") instanceof JsonString s > > && s.value() instanceof String name > > && o.members().get("age") instanceof JsonNumber n > > && n.toNumber() instanceof Long l && l instanceof int age) { > > // use "name" and "age" > > } > > ``` > > > > Later, when the language acquires the ability to expose deconstruction > patterns > > for arbitrary interfaces (similar to today's record patterns, see > > > https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns > ), > > this will be simplifiable to: > > > > ``` > > JsonValue doc = Json.parse(inputString); > > if (doc instanceof JsonObject(var members) > > && members.get("name") instanceof JsonString(String name) > > && members.get("age") instanceof JsonNumber(int age)) { > > // use "name" and "age" > > } > > ``` > > > > So, overtime, as more pattern matching features are introduced we > anticipate > > improved use of the API. This is a primary reason why the API is so > minimal. > > Convenience methods we add today, such as a method that accesses a JSON > > object component as say a JSON string or throws an exception, will become > > redundant in the future. > > > > ## JSON numbers > > > > The specification of JSON number makes no explicit distinction between > integral > > and decimal numbers, nor specifies limits on the size of those numbers. > > This is a common source of interoperability issues when consuming JSON > > documents. Generally users cannot always but often do assume JSON > numbers are > > parsable, without loss of precision, to IEEE double-precision floating > point > > numbers or 32-bit signed integers. > > > > In this respect the API provides three means to operate on the JSON > number, > > giving the user full control: > > > > 1. Underlying string representation can be obtained, if preserving > syntactic > > details such as leading or trailing zeros is important. > > 2. The string representation can be parsed to an instance of > `BigDecimal`, using > > `toBigDecimal` if preserving decimal numbers is important. > > 3. The string representation can be parsed into an instance of `Long`, > `Double`, > > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this > method > > depends on how the representation can be parsed, possibly losing > precision, > > choosing a suitably convenient numeric type that can then be pattern > > matched on. > > > > Primitive pattern matching will help as will further pattern matching > features > > enabling the user to partially match. > > > > ## Prototype implementation > > > > The prototype implementation is currently located into the JDK sandbox > > repository > > under the `json` branch, see > > here > > > https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json > > The prototype API javadoc generated from the repository is also > available at > > > https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html > > > > ### Testing and conformance > > > > The prototype implementation passes all conformance test cases but two, > > available > > on https://github.com/nst/JSONTestSuite. The two exceptions are the > ones which > > the > > prototype specifically prohibits, i.e, duplicated names in JSON objects > > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35 > ). > > > > ### Performance > > > > Our main focus so far has been on the API design and a functional > > implementation. > > Hence, there has been less focus on performance even though we know > there are a > > number of performance enhancements we can make eventually. > > We are reasonably happy with the current performance. The > > implementation performs well when compared to other JSON implementations > > parsing from string instances and traversing documents. > > > > An example of where we may choose simplicity and usability over > performance > > is the rejection of JSON documents containing objects that in turn > contain > > members > > with duplicate names. That may increase the cost of parsing, but > simplifies the > > user > > experience for the majority of cases since if we reasonably assume > JsonObjects > > are > > map-like, what should the user do with such members, pick one the last > one? > > merge > > the values? or reject? > > > > ## A JSON JEP? > > > > We plan to draft JEP when we are ready. Attentive readers will observe > that > > a JEP already exists, JEP 198: Light-Weight JSON API > > (https://openjdk.org/jeps/198). We will > > either update this JEP, or withdraw it and draft a new one. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.org Thu May 15 23:52:53 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 15 May 2025 23:52:53 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:05:10 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > new algorithms in SunJCE Updates look good. Thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2845203782 From swen at openjdk.org Thu May 15 23:57:31 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 15 May 2025 23:57:31 GMT Subject: RFR: 8357081: Removed unused methods of HexDigits Message-ID: In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods ------------- Commit messages: - remove unused code Changes: https://git.openjdk.org/jdk/pull/25258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25258&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357081 Stats: 69 lines in 1 file changed: 0 ins; 69 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25258/head:pull/25258 PR: https://git.openjdk.org/jdk/pull/25258 From bchristi at openjdk.org Thu May 15 23:59:41 2025 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 15 May 2025 23:59:41 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2] In-Reply-To: References: Message-ID: <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com> > Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner. > > (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.) > > In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical. > > Details of note: > > 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state. > > The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same. > > Thanks. > > **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.** Brent Christian has updated the pull request incrementally with one additional commit since the last revision: update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25242/files - new: https://git.openjdk.org/jdk/pull/25242/files/e36cf5db..c3a94433 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25242&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25242&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25242/head:pull/25242 PR: https://git.openjdk.org/jdk/pull/25242 From bchristi at openjdk.org Thu May 15 23:59:41 2025 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 15 May 2025 23:59:41 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2] In-Reply-To: References: Message-ID: <-pQm_zdR4S8AnRj6ROFJxxTi1n6jTW1OlPTenwnuPm4=.50de719e-8fbc-46b8-b27f-e967e3ad8ee6@github.com> On Thu, 15 May 2025 21:35:14 GMT, Hendrik Schick wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright > > test/jdk/com/sun/jndi/ldap/CleanerTests/LdapEnumeration.ldap line 2: > >> 1: # >> 2: # Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > # Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > (?) Copyright updated, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2092116149 From almatvee at openjdk.org Fri May 16 01:53:01 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 May 2025 01:53:01 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4] In-Reply-To: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> Message-ID: <4GqhkY0xKEKx5h6p3aLH-1ooMcWVmWZksJyKsAdBdec=.41398343-bbf0-4e1a-b25e-378a359439f0@github.com> On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk wrote: >> Refactor jpackage to separate the configuration and execution phases. >> At the configuration phase, jpackage parses command-line arguments and validates them. >> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. >> >> There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. >> >> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. >> >> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". >> >> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. >> >> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html >> >> **Functional changes** >> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. >> >> - Minimize copying of the source app image when doing native packaging. >> >> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. >> >> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. >> >> post- and pre- install PKG scripts for SimplePackageTest package before and after the change: >> >> >> >>
      Scr... > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits: > > - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh > - Merge branch 'master' into JDK-8333664 > - Remove redundant StandardBundlerParam.createResource() > - Adapt JDK-8352480 fix > - Merge branch 'master' into JDK-8333664 > - Fix javadoc > - Merge branch 'master' into JDK-8333664 > - 8333568: Test that jpackage doesn't modify R/O files/directories > > Reviewed-by: almatvee > - 8356562: SigningAppImageTwoStepsTest test fails > > Reviewed-by: almatvee > - Remove clean_stashed_files.sh > - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710 Looks good with minor comments. src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java line 337: > 335: */ > 336: private InstallableFile createDesktopFile(String fileName) { > 337: var srcPath = pkg.asPackageApplicationLayout().orElseThrow().resolveAt(env.appImageDir()).destktopIntegrationDirectory().resolve(fileName); `destktop` -> `desktop` src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java line 477: > 475: return Optional.of(fa) > 476: .flatMap(FileAssociation::icon) > 477: .map(DesktopIntegration::getSquareSizeOfImage) `getSquareSizeOfImage` will return 0, if exception is thrown for invalid image. Should it return -1 or should we only accept icons if `getIconSize() > 0`? src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java line 33: > 31: import jdk.jpackage.internal.model.ApplicationLayout; > 32: > 33: record AppImageDesc(AppImageLayout appImageLyout, Path path) { `appImageLyout` -> `appImageLayout` src/jdk.jpackage/share/classes/jdk/jpackage/internal/BuildEnvBuilder.java line 51: > 49: } else if (!Files.isDirectory(root)) { > 50: throw exceptionBuilder.create(); > 51: } else { Maybe rewrite to: if (!Files.isDirectory(root)) { throw exceptionBuilder.create(); } else if (Files.exists(root)) { ... } src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackageBuilder.java line 65: > 63: installDirName = Optional.empty(); > 64: } > 65: case MAC_DMG,MAC_PKG -> { `MAC_DMG,MAC_PKG` -> `MAC_DMG, MAC_PKG` src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/package-info.java line 34: > 32: * All methods of all interfaces and classes in this package return non-null values unless stated otherwise. > 33: */ > 34: package jdk.jpackage.internal.model; Missing new line. src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CompositeProxy.java line 200: > 198: * static final CompositeProxyTunnel INSTANCE = new CompositeProxyTunnel(); > 199: * } > 200: * } Extra `}` src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java line 940: > 938: var launchers = Optional.ofNullable(pkg.app().launchers()).map( > 939: List::stream).orElseGet(Stream::of); > 940: return launchers.map(launcher -> { Extra space. ------------- PR Review: https://git.openjdk.org/jdk/pull/19668#pullrequestreview-2835056108 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2085771680 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2085785398 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2089916849 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2089955028 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2090064291 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2090100387 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2092111270 PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2092154401 From duke at openjdk.org Fri May 16 01:56:12 2025 From: duke at openjdk.org (ExE Boss) Date: Fri, 16 May 2025 01:56:12 GMT Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles [v25] In-Reply-To: References: Message-ID: <91AvxL2hdhCWd8lxr02P06XS4HxDNH_xXF7aOU1CX54=.2a8da24d-e3c5-4aae-9d91-b2656d50ac4f@github.com> On Wed, 19 Jun 2024 09:08:35 GMT, Adam Sotona wrote: >> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles. >> >> This patch converts ASM calls to Classfile API. >> >> This PR is continuation of https://github.com/openjdk/jdk/pull/12945 >> >> Any comments and suggestions are welcome. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: > > - removed empty line > - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java Changes requested by ExE-Boss at github.com (no known OpenJDK username). src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 562: > 560: private static byte[] generateCodeBytesForLFs(String className, String[] names, LambdaForm[] forms) { > 561: return ClassFile.of().build(ClassDesc.ofInternalName(className), clb -> { > 562: clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER) `ACC_PRIVATE` is?not a?valid access?flag for?a?class, those?only?allow public or?package?access[^1]: Suggestion: clb.withFlags(ACC_FINAL | ACC_SUPER) [^1]: See?**JVMS** [Table?4.1?B](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.1-200-E.1) ------------- PR Review: https://git.openjdk.org/jdk/pull/17108#pullrequestreview-2845315645 PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r2092193712 From liach at openjdk.org Fri May 16 02:05:11 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 02:05:11 GMT Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles [v25] In-Reply-To: <91AvxL2hdhCWd8lxr02P06XS4HxDNH_xXF7aOU1CX54=.2a8da24d-e3c5-4aae-9d91-b2656d50ac4f@github.com> References: <91AvxL2hdhCWd8lxr02P06XS4HxDNH_xXF7aOU1CX54=.2a8da24d-e3c5-4aae-9d91-b2656d50ac4f@github.com> Message-ID: On Fri, 16 May 2025 01:50:06 GMT, ExE Boss wrote: >> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: >> >> - removed empty line >> - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java > > src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 562: > >> 560: private static byte[] generateCodeBytesForLFs(String className, String[] names, LambdaForm[] forms) { >> 561: return ClassFile.of().build(ClassDesc.ofInternalName(className), clb -> { >> 562: clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER) > > `ACC_PRIVATE` is?not a?valid access?flag for?a?class, those?only?allow public or?package?access[^1]: > Suggestion: > > clb.withFlags(ACC_FINAL | ACC_SUPER) > > > [^1]: See?**JVMS** [Table?4.1?B](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.1-200-E.1) It has been there and also for injected invoker template. Can be safely ignored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r2092203326 From thomas.stuefe at gmail.com Fri May 16 04:10:31 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 16 May 2025 06:10:31 +0200 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> References: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> Message-ID: On Thu, May 15, 2025 at 8:00?PM Alan Bateman wrote: > > > On 15/05/2025 17:52, Thomas St?fe wrote: > > : > > > > However, we also could just get rid of vfork. That would simplify > > things alot. We have moved to posix_spawn-by-default with JDK 13 in > > 2019 (https://bugs.openjdk.org/browse/JDK-8213192). That is a long > > time ago; probably long enough to ween all customers off vfork use. > > > > What do people think? > > > > I haven't see any complaints or JBS issues since the change in JDK 13. > It's possible that there deployments running with > jdk.lang.Process.launchMechanism set to vfork but my guess is that this > configuration knob isn't widely known. If there are deployments doing > this then there must be some reason, and I think we would have heard > about it via a JBS issue by now. > > I checked the JDK release notes. The property was documented in the JDK > 12 release notes. The release note in JDK 13 about the move to > posix_spawn didn't name the property to go back to vfork. > > So my initial reaction is that removing vfork would not be disruptive. > > -Alan > > > Thank you, Alan. I will prepare a patch and a CSR. /Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From iklam at openjdk.org Fri May 16 04:38:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 16 May 2025 04:38:55 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand I have merged your PR with the latest repo and running tiers 1-4 in our CI. Waiting for the results now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2885610681 From alanb at openjdk.org Fri May 16 05:36:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 May 2025 05:36:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Changes based on review feedback. src/jdk.zipfs/share/classes/module-info.java line 299: > 297: *
    • > 298: * Any other values will cause an {@code IllegalArgumentException} > 299: * to be thrown. The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2092352639 From alan.bateman at oracle.com Fri May 16 05:56:03 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 16 May 2025 06:56:03 +0100 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: References: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> Message-ID: <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com> On 16/05/2025 05:10, Thomas St?fe wrote: > > > > Thank you, Alan. I will prepare a patch and a CSR. > Okay, and maybe something for early in JDK 26 to avoid touching this area close to the fork for JDK 25 RDP1. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Fri May 16 06:19:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 May 2025 06:19:54 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v4] In-Reply-To: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> References: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> Message-ID: On Thu, 15 May 2025 22:42:15 GMT, Brian Burkhalter wrote: >> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. > > Brian Burkhalter 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: > > - 8355954: Simplify test > - Merge > - 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set > - 8355954: Address comments on naming in the PR > - 8355954: File.delete removes read-only files (win) test/jdk/java/io/File/DeleteReadOnly.java line 47: > 45: > 46: private static final File DIR = new File(".", "dir"); > 47: private static final File FILE = new File(DIR, "file"); If one of the tests fails then it will impact the test(s) that execute later. It might be better to just isolate them. deleteReadOnlyDirectory creates a directory that is used solely for that test, and deleteReadOnlyRegularFile creates a file that is used solely for that test. test/jdk/java/io/File/DeleteReadOnly.java line 62: > 60: > 61: boolean deleted = FILE.delete(); > 62: boolean shouldBeDeleted = !Platform.isWindows() || DELETE_READ_ONLY; The behavior and system property is Windows specific and might make things simpler to make it a Windows only test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092398839 PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092395664 From bpb at openjdk.org Fri May 16 06:31:00 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 06:31:00 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v4] In-Reply-To: References: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> Message-ID: On Fri, 16 May 2025 06:17:32 GMT, Alan Bateman wrote: >> Brian Burkhalter 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: >> >> - 8355954: Simplify test >> - Merge >> - 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set >> - 8355954: Address comments on naming in the PR >> - 8355954: File.delete removes read-only files (win) > > test/jdk/java/io/File/DeleteReadOnly.java line 47: > >> 45: >> 46: private static final File DIR = new File(".", "dir"); >> 47: private static final File FILE = new File(DIR, "file"); > > If one of the tests fails then it will impact the test(s) that execute later. It might be better to just isolate them. deleteReadOnlyDirectory creates a directory that is used solely for that test, and deleteReadOnlyRegularFile creates a file that is used solely for that test. Agreed. That actually happened when negative testing against code without the fix. > test/jdk/java/io/File/DeleteReadOnly.java line 62: > >> 60: >> 61: boolean deleted = FILE.delete(); >> 62: boolean shouldBeDeleted = !Platform.isWindows() || DELETE_READ_ONLY; > > The behavior and system property is Windows specific and might make things simpler to make it a Windows only test. I guess collapsing the tests made them more ambiguous. Will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092413253 PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092412505 From ssarathi at openjdk.org Fri May 16 07:09:26 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Fri, 16 May 2025 07:09:26 GMT Subject: RFR: 8357106: Add missing classpath exception copyright headers Message-ID: This PR adds missing classpath exception ------------- Commit messages: - Adds missing classpath exception Changes: https://git.openjdk.org/jdk/pull/25261/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25261&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357106 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25261/head:pull/25261 PR: https://git.openjdk.org/jdk/pull/25261 From thomas.stuefe at gmail.com Fri May 16 07:26:12 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 16 May 2025 09:26:12 +0200 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com> References: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com> Message-ID: Okay, moved the release version to 26. Could one of you (you or @Roger Riggs ) review the CSR if you have the cycles to spare? https://bugs.openjdk.org/browse/JDK-8357090 Thanks! On Fri, May 16, 2025 at 7:56?AM Alan Bateman wrote: > On 16/05/2025 05:10, Thomas St?fe wrote: > > > >> > Thank you, Alan. I will prepare a patch and a CSR. > > Okay, and maybe something for early in JDK 26 to avoid touching this area > close to the fork for JDK 25 RDP1. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.org Fri May 16 07:28:29 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 16 May 2025 07:28:29 GMT Subject: RFR: 8357089: Remove VFORK launch mechanism from Process implementation (linux) Message-ID: See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal. Patch - removes all code handling the VFORK mode. - removes or rewrites comments explaining use of vfork by the JVM. - we now print out an error message to stderr if the user still specifies `-Djdk.lang.Process.launchMechanism=vfork`. ------------- Commit messages: - add warning message if user specifies VFORK - start Changes: https://git.openjdk.org/jdk/pull/25260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25260&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357089 Stats: 106 lines in 4 files changed: 0 ins; 84 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/25260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25260/head:pull/25260 PR: https://git.openjdk.org/jdk/pull/25260 From duke at openjdk.org Fri May 16 07:44:00 2025 From: duke at openjdk.org (erifan) Date: Fri, 16 May 2025 07:44:00 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v6] In-Reply-To: References: Message-ID: <9f_-MMP_SSYInzCTUc5scRzKOKN1jj4VcnGEYWoOF14=.2eca7e44-d1df-4e57-a513-d8ddaddc9ea2@github.com> On Wed, 14 May 2025 02:44:14 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan 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: > > - Refactor the JTReg tests for compare.xor(maskAll) > > Also made a bit change to support pattern `VectorMask.fromLong()`. > - Merge branch 'master' into JDK-8354242 > - Refactor code > > Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this > optimization, making the code more modular. > - Merge branch 'master' into JDK-8354242 > - Update the jtreg test > - Merge branch 'master' into JDK-8354242 > - Addressed some review comments > > 1. Call VectorNode::Ideal() only once in XorVNode::Ideal. > 2. Improve code comments. > - Merge branch 'master' into JDK-8354242 > - Merge branch 'master' into JDK-8354242 > - 8354242: VectorAPI: combine vector not operation with compare > > This patch optimizes the following patterns: > For integer types: > ``` > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > ``` > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the > negative comparison of cond. > > For float and double types: > ``` > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > ``` > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: > With option `-XX:UseSVE=2`: > ``` > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855... Hi, I have updated the code and I'll file the patch to convert `VectorMask.fromLong(SPECIES, -1)` to `maskAll()` soon, I'll cover this test case in that patch. Would you please help review the patch again, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2885913474 From rgiulietti at openjdk.org Fri May 16 07:46:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 16 May 2025 07:46:51 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods In-Reply-To: References: Message-ID: On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen wrote: > Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. The renaming is nice and useful. But #24982, in addition to renaming, emphasizes the expectations about correct usage with bold WARNINGs in the JavaDoc. That's the "document preconditions" in the title. Adding similar warnings in the JavaDoc, rather than in plain comments in the methods, would be clearer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2885920485 From vyazici at openjdk.org Fri May 16 08:01:22 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 16 May 2025 08:01:22 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods In-Reply-To: References: Message-ID: On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen wrote: > Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 297: > 295: */ > 296: public static int uncheckedGetCharsUTF16(long i, int index, byte[] buf) { > 297: // Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Regarding all methods that are prefixed with `unsynchronized` in this PR, IMHO: 1. Precondition warnings should better be moved to the JavaDoc (ala #24982) 2. We shall also consider implementing these preconditions using `assert` statements ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2092539634 From jpai at openjdk.org Fri May 16 08:04:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 08:04:00 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Replace getChars in previous commit with subSequence src/java.base/share/classes/java/io/Reader.java line 478: > 476: * > 477: *

      If an I/O error occurs reading from the stream, then it > 478: * may do so after some, but not all, characters have been read. Hello Brian, I read this sentence a couple of times but it wasn't clear to me what this meant. I am guessing that we want to state that if an I/O error occurs when some (but not all?) characters have been read then the stream may be in an inconsistent state? Should we reword this paragraph? I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2092538195 From stuefe at openjdk.org Fri May 16 08:42:50 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 16 May 2025 08:42:50 GMT Subject: RFR: 8357089: Remove VFORK launch mechanism from Process implementation (linux) In-Reply-To: References: Message-ID: On Fri, 16 May 2025 06:14:57 GMT, Thomas Stuefe wrote: > Not for JDK 25 > > See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal. > > Patch > > - removes all code handling the VFORK mode. > - removes or rewrites comments explaining use of vfork by the JVM. > - we now print out an error message to stderr if the user still specifies `-Djdk.lang.Process.launchMechanism=vfork`. I will delay this push for early JDK 26; hence back to draft state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25260#issuecomment-2886046022 From jpai at openjdk.org Fri May 16 09:26:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 09:26:57 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2] In-Reply-To: References: Message-ID: <3-h5cco6E3PRpslFiqAR913I_lJ8_c0tMHhREoHCkps=.a9ba0091-c77d-4dda-b7d0-53e83ac57ca3@github.com> On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks wrote: >> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: >> >> - overrides and adds locking to SequencedCollection methods; >> - performs instance management of reversed synchronized views; >> - adds test for race conditions and functional tests of synchronized wrappers. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Reversed view of SynchronizedRandomAccessList should also be RandomAccess. > Add tests to ensure RandomAccess is preserved when reversing. test/jdk/java/util/Collections/SyncListBash.java line 31: > 29: * @run main SyncListBash f > 30: * @run main SyncListBash r > 31: * @summary Test that List's new SequencedCollection methods are properly Nit - jtreg recommends `@summary` to be after `@bug` https://openjdk.org/jtreg/tag-spec.html#ORDER. It would be good to follow that for this new test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2092688878 From aph at openjdk.org Fri May 16 09:31:03 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 16 May 2025 09:31:03 GMT Subject: Integrated: 8354674: AArch64: Intrinsify Unsafe::setMemory In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote: > This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). > > > Benchmark (aligned) (size) Mode Cnt Score Error Units > MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op > MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op > MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op > MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op This pull request has now been integrated. Changeset: a6ebcf61 Author: Andrew Haley URL: https://git.openjdk.org/jdk/commit/a6ebcf61eb522a1bcfc9f2169d42974af3883b00 Stats: 127 lines in 3 files changed: 122 ins; 0 del; 5 mod 8354674: AArch64: Intrinsify Unsafe::setMemory Reviewed-by: adinn ------------- PR: https://git.openjdk.org/jdk/pull/25147 From jpai at openjdk.org Fri May 16 09:37:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 09:37:56 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks wrote: >> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: >> >> - overrides and adds locking to SequencedCollection methods; >> - performs instance management of reversed synchronized views; >> - adds test for race conditions and functional tests of synchronized wrappers. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Reversed view of SynchronizedRandomAccessList should also be RandomAccess. > Add tests to ensure RandomAccess is preserved when reversing. The fix and tests look good to me. I just have a nit that I've included as a review comment for the new test. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24990#pullrequestreview-2846098206 From swen at openjdk.org Fri May 16 09:45:43 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 16 May 2025 09:45:43 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v2] In-Reply-To: References: Message-ID: > Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - assert - document add warnings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25246/files - new: https://git.openjdk.org/jdk/pull/25246/files/66f71c58..ddb44aa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=00-01 Stats: 29 lines in 1 file changed: 24 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246 PR: https://git.openjdk.org/jdk/pull/25246 From jpai at openjdk.org Fri May 16 10:09:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 10:09:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). test/jdk/tools/launcher/Arrrghs.java line 607: > 605: //private method with parameter, usable method without parameter: > 606: createJar(new File("some.jar"), new File("Foo"), > 607: "private static void main(String[] args){}", Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case? test/jdk/tools/launcher/Arrrghs.java line 635: > 633: tr.contains("Error: abstract class Foo can not instantiated"); > 634: if (!tr.testStatus) > 635: System.out.println(tr); Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092758973 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092755321 From duke at openjdk.org Fri May 16 10:12:59 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 16 May 2025 10:12:59 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com> On Thu, 15 May 2025 22:03:40 GMT, Raffaello Giulietti wrote: > There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck? @rgiulietti It seems there is a slowdown in the creation of large pseudoprimes, maybe due to `BitSieve` methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2886284468 From jpai at openjdk.org Fri May 16 10:13:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 10:13:52 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: > 281: make inner class static or move inner class out to separate source file > 282: java.launcher.cls.error8=\ > 283: Error: abstract class {0} can not instantiated\n\ Nit - should this use a comma instead of the newline? src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties line 113: > 111: # 0: string > 112: launcher.err.cant.find.main.method=\ > 113: can''t find main(String[]) or main() method in class: {0} Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092763055 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092765139 From jpai at openjdk.org Fri May 16 10:30:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 10:30:51 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794: > 792: """ > 793: public class WrongMainPrivate { > 794: private static void main(String[] args) {} Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092789314 From thartmann at openjdk.org Fri May 16 10:35:09 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 10:35:09 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig wrote: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing Looks good to me but someone from core-libs should have a look as well. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2846233046 From azeller at openjdk.org Fri May 16 10:38:07 2025 From: azeller at openjdk.org (Arno Zeller) Date: Fri, 16 May 2025 10:38:07 GMT Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in exception Message-ID: When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones. ------------- Commit messages: - Use correct variables. Changes: https://git.openjdk.org/jdk/pull/25250/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25250&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357052 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25250.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25250/head:pull/25250 PR: https://git.openjdk.org/jdk/pull/25250 From duke at openjdk.org Fri May 16 10:41:34 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 16 May 2025 10:41:34 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v7] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Correct bug in shiftRight ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/642461fe..a434bfc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From dfuchs at openjdk.org Fri May 16 10:45:06 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 May 2025 10:45:06 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits: > > - merge latest changes from master branch > - Undo whitespace change > - Remove unnecessary import > - Merge remote-tracking branch 'origin/master' into http3 > - Fix test license > - Remove leftover file (test was moved to parent directory) > - Remove unnecessary import > - Update throws clauses > - Merge remote-tracking branch 'origin/master' into http3 > - 8354275: Add HTTP/3 tests to `EmptyAuthenticate` > - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c I spotted some inacuracy in QuicEndpoint. I will take care of these. src/java.net.http/share/classes/jdk/internal/net/http/Http3ClientImpl.java line 158: > 156: quicIdleMillis = h3Millis + 60000; // a minute more than h3 timeout > 157: } > 158: transportParameters.setIntParameter(max_idle_timeout, quicIdleMillis); I understand we don't want the QUIC Idle Timeout to kill idle connections before the HTTP/3 idle timeout has expired. But on the other hand, we should not let the HTTP/3 idle timeout set a quic idle timeout that is less than the default quic timeout. We should take into account the value of the default quic timeout that we use in QuicConnectionImpl here. src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737: > 735: // channel, and a single selector thread, so we can do > 736: // the reading directly in the selector thread and offload > 737: // the parsing (the readLoop) to the executor. This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold. src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822: > 820: if (this.buffered.get() >= MAX_BUFFERED_HIGH) { > 821: pauseReading(); > 822: readLoopScheduler.runOrSchedule(executor); This line should not be needed: we should already have kicked the read loop at line 797. ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-2846207620 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092779174 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092786818 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092805633 From jlahoda at openjdk.org Fri May 16 11:06:53 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:06:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 10:10:17 GMT, Jaikiran Pai wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: > >> 281: make inner class static or move inner class out to separate source file >> 282: java.launcher.cls.error8=\ >> 283: Error: abstract class {0} can not instantiated\n\ > > Nit - should this use a comma instead of the newline? The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional. > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties line 113: > >> 111: # 0: string >> 112: launcher.err.cant.find.main.method=\ >> 113: can''t find main(String[]) or main() method in class: {0} > > Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo. Pieces of text in `MessageFormat` can be quoted using `'...'`. So, a single `'` does not work, as that is considered to be part of quoting. Using `''` escapes that behavior. > test/jdk/tools/launcher/Arrrghs.java line 635: > >> 633: tr.contains("Error: abstract class Foo can not instantiated"); >> 634: if (!tr.testStatus) >> 635: System.out.println(tr); > > Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code? `tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092836696 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092838074 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092835532 From duke at openjdk.org Fri May 16 11:10:12 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 16 May 2025 11:10:12 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v8] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: An optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/a434bfc5..b151b7e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From jlahoda at openjdk.org Fri May 16 11:12:08 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:12:08 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adding tests as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25256/files - new: https://git.openjdk.org/jdk/pull/25256/files/1c6a0123..a351686d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=00-01 Stats: 48 lines in 2 files changed: 48 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From jlahoda at openjdk.org Fri May 16 11:12:08 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:12:08 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 10:07:36 GMT, Jaikiran Pai wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding tests as suggested. > > test/jdk/tools/launcher/Arrrghs.java line 607: > >> 605: //private method with parameter, usable method without parameter: >> 606: createJar(new File("some.jar"), new File("Foo"), >> 607: "private static void main(String[] args){}", > > Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case? Done: https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f > test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794: > >> 792: """ >> 793: public class WrongMainPrivate { >> 794: private static void main(String[] args) {} > > Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too? Done: https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844131 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844245 From vromero at openjdk.org Fri May 16 11:25:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 May 2025 11:25:51 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding tests as suggested. src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: > 281: make inner class static or move inner class out to separate source file > 282: java.launcher.cls.error8=\ > 283: Error: abstract class {0} can not instantiated\n\ typo: can not `be` instantiated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092862512 From michaelm at openjdk.org Fri May 16 11:42:08 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 16 May 2025 11:42:08 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v10] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - reduced number of new categories - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Review update - review update - Merge branch 'master' into 8348986-exceptions - update to minimise code changes - Merge branch 'master' into 8348986-exceptions - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0 ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=09 Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From duke at openjdk.org Fri May 16 11:47:53 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 16 May 2025 11:47:53 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > make magBitLength() an instance method src/java.base/share/classes/java/math/BigInteger.java line 3619: > 3617: int nzInts = numberOfTrailingZeroInts(); > 3618: if (nInts > nzInts || nInts == nzInts > 3619: && nBits > Integer.numberOfTrailingZeros(magLen - 1 - nzInts)) { @rgiulietti The bug was there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2092889185 From rgiulietti at openjdk.org Fri May 16 11:47:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 16 May 2025 11:47:54 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: <2xr3DFqEpcV-QgHdDujdEGf_GB3d2lGYAoMBtFrX4g0=.adcda9e7-bc7c-49fc-b486-89659dd2f346@github.com> On Fri, 16 May 2025 11:43:18 GMT, fabioromano1 wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> make magBitLength() an instance method > > src/java.base/share/classes/java/math/BigInteger.java line 3619: > >> 3617: int nzInts = numberOfTrailingZeroInts(); >> 3618: if (nInts > nzInts || nInts == nzInts >> 3619: && nBits > Integer.numberOfTrailingZeros(magLen - 1 - nzInts)) { > > @rgiulietti The bug was there. OK, good. We try to make sure that pushed commits pass all the relevant tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2092892266 From jpai at openjdk.org Fri May 16 11:49:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 11:49:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 11:02:54 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: >> >>> 281: make inner class static or move inner class out to separate source file >>> 282: java.launcher.cls.error8=\ >>> 283: Error: abstract class {0} can not instantiated\n\ >> >> Nit - should this use a comma instead of the newline? > > The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional. Sounds fine to me then. >> test/jdk/tools/launcher/Arrrghs.java line 635: >> >>> 633: tr.contains("Error: abstract class Foo can not instantiated"); >>> 634: if (!tr.testStatus) >>> 635: System.out.println(tr); >> >> Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code? > > `tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option. Thank you for that. I didn't even realize that this was a "main()" test. I saw that there was a `@Test` annotation on these test methods and assumed it was either a testng or junit test. Turns out it's just another internal annotation of the `TestHelper`. > It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option. What you have in the current PR is fine with me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092893716 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092892219 From jlahoda at openjdk.org Fri May 16 11:54:07 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:54:07 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v3] In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Review comment: correcting typo. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25256/files - new: https://git.openjdk.org/jdk/pull/25256/files/a351686d..f63dab37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From jpai at openjdk.org Fri May 16 11:54:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 11:54:07 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding tests as suggested. I went through the JLS updates linked in the CSR for JEP 512 https://bugs.openjdk.org/browse/JDK-8353437. The proposed changes in this PR looks good to me. The additional test coverage being added is good too. I am not completely sure if the `Arrrghs.java` test and the `test/jdk/tools/launcher/InstanceMainTest.java` test fully cover all the scenarios of the new rules of determining a main method, but that's something that can be looked into as a separate activity. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25256#issuecomment-2886504200 From jpai at openjdk.org Fri May 16 11:57:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 11:57:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v3] In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> Message-ID: On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Review comment: correcting typo. test/jdk/tools/launcher/Arrrghs.java line 649: > 647: """); > 648: tr = doExec(javaCmd, "-jar", "some.jar"); > 649: tr.contains("Error: abstract class Foo can not instantiated"); After the latest typo fix, this check would also need an update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092905785 From vromero at openjdk.org Fri May 16 12:01:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 May 2025 12:01:51 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v3] In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> Message-ID: <9nkgB8f4tHZhM5HWcaivVzI7ibIZ0DfWlwRykr_uYrY=.8a0198cb-f35f-42ed-948d-2110a4694ef1@github.com> On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Review comment: correcting typo. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2846416794 From forax at univ-mlv.fr Fri May 16 12:26:54 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 16 May 2025 14:26:54 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr> > From: "Ethan McCue" > To: "Remi Forax" > Cc: "Paul Sandoz" , "core-libs-dev" > > Sent: Friday, May 16, 2025 1:44:52 AM > Subject: Re: Towards a JSON API for the JDK > I present for your consideration the library I made when spiraling about this > problem space a few years ago > [ https://github.com/bowbahdoe/json | https://github.com/bowbahdoe/json ] > [ > https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html > | > https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html > ] > Notably missing during the design process here were patterns, hence the > JsonDecoder design. I haven't been able to evaluate how patterns affect that on > account of them not being out. > I will more thoroughly peruse the draft of java.util.json at a later date, but > my initial observations/comments: > * I am not sure having JsonValue be distinct from Json has value. > * toUntyped feels a little strange to me - the only type information presumably > lost is the sealed-ness of the hierarchy. The interplay between that and > toNumber is also a little unnerving. > * One notion that I found helpful was that a class could be "json encodable," > meaning there is a method to call to obtain a canonical json representation. > record Person(String name) implements JsonEncodable { > @Override > public Json toJson() { > return Json.objectBuilder() > .put("namen", name) > .build(); > } > } > Which helper methods like Json#of(List) could make use > of. Json itself ( JsonValue in your prototype) could then have a vacuous > implementation. > * Terminology wise - I went with reading/writing for the actual > parsing/generation of json and encoding/decoding for the mapping of those > representations to/from specific classes. The merits are not top of mind, just > noting the difference. read/write vs parse/toString+toDisplayString > * One thing I did was make the helper methods in Json null tolerant and the ones > in the specific subtypes like JsonString not. This was because from what I saw > of usages of javax.json/jakarta.json that nullability was a footgun and > correcting for it required changes to code structure (breaking up builder > chains with if (x != null) checks) > * The functionality you want from JsonNumber could be achieved by making it just > extend Number ( [ > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java > | > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java > ] ) instead of a bespoke toNumber . You need the extra methods to go to big > decimal and co, but it's just an extension to the behavior of Number at that > point. > * JsonObject and JsonArray could implement Map and List > respectively. This lowers the need for toUntyped() - since presumably one of > the use cases for that is turning the json tree into something that more > generic map/list traversal code can handle. It also complicates any lazy > loading somewhat. > * Assuming patterns can be placed on interfaces, you might want to consider > something similar to JsonDecoder , but with a pattern instead of a method that > throws an exception. > // Where here fromJson would box up the logic for testing and extracting from > each element in the array. > List people = array(json, Person::fromJson); > * I don't think there is sufficient cause for anything to be non-sealed at this > point. > * JsonBoolean and JsonNull do not have reasonable alternative implementations - > as far as I can imagine, maybe i'm wrong - so maybe those can just be final > classes? > * If you seal up the whole hierarchy then its pretty trivial to make it > serializable ( [ > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java > | > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java > ] ) Hello, I think your library is more high-level than java.util.json. Moreover, Paul proposes a design closer to DOP (Data Oriented Programming) than OOP. JsonNumber should not extend Number, JsonObject and JsonArray should not implements Map and List, the idea is to use delegation instead. (BTW extending Number will become an issue in the future if the VM tries to flatten filed typed with a value capable abstract class like Number) JSON is fundamentally untyped and recursive, but also describe data structures, for me, the proposed API exposes that structure (the subtypes of JsonValue) and make it easy to move from a JSON text to Java objects or vice-versa. The java.util.json API is very simple, - Json.fromUntyped() see a Java object to a structured JSON value (a JsonValue), - Json.toUntyped() unwrap a structured JSON value to extract the underlying Java object. - Json.parse() from String to a structured JSON value - Json.toDisplayString() (i would prefer "prettyString") goes from a structured JSON value to a pretty string. Having a JsonEncoder and JsonDecoder, JsonDecodable, etc is more high level than what is proposed here, so you can write objects like JsonEncoder/Decoder on top of it. Your example of JsonEncodable can be re-written to use the java.util.json API like this record Person(String name) implements JsonEncodable { @Override public JsonValue toJson() { return Json.fromUntyped(Map.of("name", name)); } } Compared to your code, java.util.json uses immutable data structures instead of a mutable builder (and yes, you lose the order, until SequenceMap.of() exists). regards, R?mi > On Thu, May 15, 2025 at 11:29 PM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> Hi Paul, >> yes, not having a simple JSON API in Java is an issue for beginners. >> It's not clear to me why JsonArray (for example) has to be an interface instead >> of a record ? >> I understand why Json.parse() only works on String and char[] but the API make >> it too easy to have many performance issues. >> I think you need versions using a Reader and a Path. >> Bonus point, if there is a method walk() that also returns a JsonValue but the >> List/Map inside JsonArray/JsonObject are populated lazily. >> Minor point: Json.toDisplayString() should takes a second parameters indicating >> the number of spaces used for the indentation (like JSON.stringify in JS). >> regards, >> R?mi >> ----- Original Message ----- >>> From: "Paul Sandoz" < [ mailto:paul.sandoz at oracle.com | paul.sandoz at oracle.com ] >> > > >>> To: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org | >> > core-libs-dev at openjdk.org ] > >> > Sent: Thursday, May 15, 2025 10:30:42 PM >> > Subject: Towards a JSON API for the JDK >> > Hi, >> > We would like to share with you our thoughts and plans towards a JSON API for >> > the JDK. >> > Please see the document below. >> > - >> > We have had the pleasure of using a clone of this API in some experiments we are >> > conducting with >> > ONNX and code reflection [1]. Using the API we were able to quickly write code >> > to ingest and convert >> > a JSON document representing ONNX operation schema into instances of records >> > modeling the schema >> > (see here [2]). >> > The overall out-of-box experience with such a minimal "batteries included? API >> > has so far been positive. >> > Thanks, >> > Paul. >>> [1] [ https://openjdk.org/projects/babylon/ | >> > https://openjdk.org/projects/babylon/ ] >> > [2] >>> [ >>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >>> | >>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >> > ] >> > # Towards a JSON API for the JDK >> > One of the most common requests for the JDK is an API for parsing and generating >> > JSON. While JSON originated as a text-based serialization format for JSON >> > objects ("JSON" stands for "JavaScript Object Notation"), because of its simple >> > and flexible syntax, it eventually found use outside the JavaScript ecosystem as >> > a general data interchange format, such as framework configuration files and web >> > service requests/response formats. >> > While the JDK cannot, and should not, provide libraries for every conceivable >> > file format or protocol, the JDK philosophy is one of "batteries included", >> > which is to say we should be able to write basic programs that use common >> > protocols such as HTTP, without having to appeal to third party libraries. >> > The Java ecosystem already has plenty of JSON libraries, so inclusion in >> > the JDK is largely meant to be a convenience, rather than needing to be the "one >> > true" JSON library to meet the needs of all users. Users with specific needs >> > are always free to select one of the existing third-party libraries. >> > ## Goals and requirements >> > Our primary goal is that the library be simple to use for parsing, traversing, >> > and generating conformant JSON documents. Advanced features, such as data >> > binding or path-based traversal should be possible to implement as layered >> > features, but for simplicity are not included in the core API. We adopt a goal >> > that the performance should be "good enough", but where performance >> > considerations conflict with simplicity and usability, we will choose in favor >> > of the latter. >> > ## API design approach >>> The description of JSON at `https::// [ http://json.org/ | json.org ] ` >> > describes a JSON document using >> > the familiar "railroad diagram": >>> ![image]( [ https://www.json.org/img/value.png | >> > https://www.json.org/img/value.png ] ) >> > This diagram describes an algebraic data type (a sum of products), which we >> > model directly with a set of Java interfaces: >> > ``` >> > interface JsonValue { } >> > interface JsonArray extends JsonValue { List values(); } >> > interface JsonObject extends JsonValue { Map members(); } >> > interface JsonNumber extends JsonValue { Number toNumber(); } >> > interface JsonString extends JsonValue { String value(); } >> > interface JsonBoolean extends JsonValue { boolean value(); } >> > interface JsonNull extends JsonValue { } >> > ``` >> > These interfaces have (hidden) companion implementation classes that admit >> > greater flexibility of implementation than modeling them directly with records >> > would permit. >> > Further, these interfaces are unsealed. We compromise on the sealed sum of >> > products to enable >> > alternative implementations, for example to support alternative formats that >> > encode the same information in a JSON document but in a more efficient form than >> > text. >> > The API has static methods for parsing strings into a `JsonValue`, conversion to >> > and from purely untyped representations (lists and maps), and factory methods >> > for building JSON documents. We apply composition consistently, e.g, a >> > JsonString has a string, a JsonObject has a map of string to JsonValue, as >> > opposed to extension for structural JSON values. >> > It turns out that this simple API is almost all we need for traversal. It gives >> > us an immutable representation of a document, and we can use pattern matching to >> > answer the myriad questions that will come up (Does this object have key X? Does >> > it map to a number? Is that number representable as an integer?) when going >> > from an untyped format like JSON to a more strongly typed domain model. >> > Given a simple document like: >> > ``` >> > { >> > "name": "John?, >> > "age": 30 >> > } >> > ``` >> > we can parse and traverse the document as follows: >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject o >> > && o.members().get("name") instanceof JsonString s >> > && s.value() instanceof String name >> > && o.members().get("age") instanceof JsonNumber n >> > && n.toNumber() instanceof Long l && l instanceof int age) { >> > // use "name" and "age" >> > } >> > ``` >> > Later, when the language acquires the ability to expose deconstruction patterns >> > for arbitrary interfaces (similar to today's record patterns, see >>> [ >>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns >>> | >>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns >> > ] ), >> > this will be simplifiable to: >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject(var members) >> > && members.get("name") instanceof JsonString(String name) >> > && members.get("age") instanceof JsonNumber(int age)) { >> > // use "name" and "age" >> > } >> > ``` >> > So, overtime, as more pattern matching features are introduced we anticipate >> > improved use of the API. This is a primary reason why the API is so minimal. >> > Convenience methods we add today, such as a method that accesses a JSON >> > object component as say a JSON string or throws an exception, will become >> > redundant in the future. >> > ## JSON numbers >> > The specification of JSON number makes no explicit distinction between integral >> > and decimal numbers, nor specifies limits on the size of those numbers. >> > This is a common source of interoperability issues when consuming JSON >> > documents. Generally users cannot always but often do assume JSON numbers are >> > parsable, without loss of precision, to IEEE double-precision floating point >> > numbers or 32-bit signed integers. >> > In this respect the API provides three means to operate on the JSON number, >> > giving the user full control: >> > 1. Underlying string representation can be obtained, if preserving syntactic >> > details such as leading or trailing zeros is important. >> > 2. The string representation can be parsed to an instance of `BigDecimal`, using >> > `toBigDecimal` if preserving decimal numbers is important. >> > 3. The string representation can be parsed into an instance of `Long`, `Double`, >> > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method >> > depends on how the representation can be parsed, possibly losing precision, >> > choosing a suitably convenient numeric type that can then be pattern >> > matched on. >> > Primitive pattern matching will help as will further pattern matching features >> > enabling the user to partially match. >> > ## Prototype implementation >> > The prototype implementation is currently located into the JDK sandbox >> > repository >> > under the `json` branch, see >> > here >>> [ >>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >>> | >>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >> > ] >> > The prototype API javadoc generated from the repository is also available at >>> [ >>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >>> | >>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >> > ] >> > ### Testing and conformance >> > The prototype implementation passes all conformance test cases but two, >> > available >>> on [ https://github.com/nst/JSONTestSuite | https://github.com/nst/JSONTestSuite >> > ] . The two exceptions are the ones which >> > the >> > prototype specifically prohibits, i.e, duplicated names in JSON objects >>> ( [ https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35 | >> > https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35 ] ). >> > ### Performance >> > Our main focus so far has been on the API design and a functional >> > implementation. >> > Hence, there has been less focus on performance even though we know there are a >> > number of performance enhancements we can make eventually. >> > We are reasonably happy with the current performance. The >> > implementation performs well when compared to other JSON implementations >> > parsing from string instances and traversing documents. >> > An example of where we may choose simplicity and usability over performance >> > is the rejection of JSON documents containing objects that in turn contain >> > members >> > with duplicate names. That may increase the cost of parsing, but simplifies the >> > user >> > experience for the majority of cases since if we reasonably assume JsonObjects >> > are >> > map-like, what should the user do with such members, pick one the last one? >> > merge >> > the values? or reject? >> > ## A JSON JEP? >> > We plan to draft JEP when we are ready. Attentive readers will observe that >> > a JEP already exists, JEP 198: Light-Weight JSON API >> > ( [ https://openjdk.org/jeps/198 | https://openjdk.org/jeps/198 ] ). We will >> > either update this JEP, or withdraw it and draft a new one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.org Fri May 16 12:28:06 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 May 2025 12:28:06 GMT Subject: Integrated: 8353888: Implement JEP 510: Key Derivation Function API In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang wrote: > Finalize the KDF API. This pull request has now been integrated. Changeset: 079fccfa Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/079fccfa9a03b890e698c52c689dea0f19f8fbee Stats: 209 lines in 18 files changed: 160 ins; 29 del; 20 mod 8353888: Implement JEP 510: Key Derivation Function API Reviewed-by: valeriep, mullan, liach ------------- PR: https://git.openjdk.org/jdk/pull/24520 From brian.goetz at oracle.com Fri May 16 12:53:18 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 May 2025 08:53:18 -0400 Subject: Towards a JSON API for the JDK In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On 5/15/2025 5:27 PM, Remi Forax wrote: > It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? Oh, you know the answer to this.? A record limits us to a single implementation with a rigid representation.? Behind an interface, we can hide lazy parsing and inflation, wrapping other representations to reduce copies, etc. From lbruun at apache.org Fri May 16 13:02:28 2025 From: lbruun at apache.org (Lars Bruun-Hansen) Date: Fri, 16 May 2025 15:02:28 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Great work. I feel the elephant in the room needs to addressed: JSON comments. I haven't tested the proposed lib but I cannot see it mentioned so I'm assuming that comments are not supported. For better or worse, the use of jsonc (JSON with comments) is everywhere in some ecosystems. Unsurprisingly this happens often when JSON is used as a config file format. Looking at you, Microsoft. It would be nice if the JDK's build-in JSON parser at least recognized this. I'm well aware that comments are frowned upon in JSON and not part of neither the spec at www.json.org nor the RFC-8259. Yet, I advocate the JDK JSON library should optionally allow comments to be ignored when PARSING. This should be an opt-in feature that would technically treat comments as whitespace during the parsing process. This would also be in line with what many other parsers do. For example, Jackson has "ALLOW_COMMENTS" feature [1]. Also, by comparison, the build-in parser in the .NET world, known as System.Text.Json, also supports this [2]. The "discoverer" of JSON, Douglas Crowford, had this to say [3] on the topic: [QUOTE] I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. ?[/QUOTE] By not having the ability to ignore comments when parsing we would effectively force users to use another parser first or a minifier. I doubt beginners would appreciate that. BTW: The test suite already has tests for comments. /Lars [1]: https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS [2]: https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties [3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr On 16/05/2025 01.44, Ethan McCue wrote: > I present for your consideration the library I made when spiraling > about this problem space a few years ago > > https://github.com/bowbahdoe/json > > https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html > > Notably missing during the design process here were patterns, hence > the JsonDecoder design. I haven't been able to evaluate how patterns > affect that on account of them not being out. > > I will more thoroughly peruse the draft of java.util.json at a later > date, but my initial observations/comments: > > * I am not sure having JsonValue be distinct from Json has value. > * toUntyped feels a little strange to me - the only type information > presumably lost is the sealed-ness of the hierarchy. The interplay > between that and toNumber is also a little unnerving. > * One notion that I found helpful was that a class could be "json > encodable," meaning there is a method to call to obtain a canonical > json representation. > > record Person(String name) implements JsonEncodable { > ? ??@Override > ? ? public Json toJson() { > ? ? ? ? return Json.objectBuilder() > ? ? ? ? ? ? .put("namen", name) > ? ? ? ? ? ? .build(); > ? ? } > } > > Which helper methods like Json#of(List)?could > make use of. Json?itself (JsonValue?in your prototype) could then have > a vacuous implementation. > > * Terminology wise - I went with reading/writing for the actual > parsing/generation of json and encoding/decoding for the mapping of > those representations to/from specific classes. The merits are not top > of mind, just noting the difference. read/write vs > parse/toString+toDisplayString > * One thing I did was make the helper methods in Json?null tolerant > and the ones in the specific subtypes like JsonString?not. This was > because from what I saw of usages of javax.json/jakarta.json that > nullability was a footgun and correcting for?it required changes to > code structure (breaking up builder chains with if (x != null)?checks) > * The functionality you want from JsonNumber could be achieved by > making it just extend Number > (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java) > instead of a bespoke toNumber. You need the extra methods to go to big > decimal and co, but it's just an extension to the behavior of Number > at that point. > * JsonObject and JsonArray could implement Map and > List respectively. This lowers the need for toUntyped() - since > presumably one of the use cases for that is turning the json tree into > something that more generic map/list traversal code can handle. It > also complicates any lazy loading somewhat. > * Assuming patterns can be placed on interfaces, you might want to > consider something similar to?JsonDecoder, but with a pattern instead > of a method that throws an exception. > > // Where here fromJson would box up the logic for testing and > extracting from each element in the array. > List people = array(json, Person::fromJson); > > * I don't think there is sufficient cause for anything to be > non-sealed at this point. > * JsonBoolean and JsonNull do not have reasonable alternative > implementations - as far as I can imagine, maybe i'm wrong - so maybe > those can just be final classes? > * If you seal up the whole hierarchy then its pretty trivial to make > it serializable > (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java) > > > > > On Thu, May 15, 2025 at 11:29?PM Remi Forax wrote: > > Hi Paul, > yes, not having a simple JSON API in Java is an issue for beginners. > > It's not clear to me why JsonArray (for example) has to be an > interface instead of a record ? > > I understand why Json.parse() only works on String and char[] but > the API make it too easy to have many performance issues. > I think you need versions using a Reader and a Path. > Bonus point, if there is a method walk() that also returns a > JsonValue but the List/Map inside JsonArray/JsonObject are > populated lazily. > > Minor point: Json.toDisplayString() should takes a second > parameters indicating the number of spaces used for the > indentation (like JSON.stringify in JS). > > regards, > R?mi > > ----- Original Message ----- > > From: "Paul Sandoz" > > To: "core-libs-dev" > > Sent: Thursday, May 15, 2025 10:30:42 PM > > Subject: Towards a JSON API for the JDK > > > Hi, > > > > We would like to share with you our thoughts and plans towards a > JSON API for > > the JDK. > > Please see the document below. > > > > - > > > > We have had the pleasure of using a clone of this API in some > experiments we are > > conducting with > > ONNX and code reflection [1]. Using the API we were able to > quickly write code > > to ingest and convert > > a JSON document representing ONNX operation schema into > instances of records > > modeling the schema > > (see here [2]). > > > > The overall out-of-box experience with such a minimal "batteries > included? API > > has so far been positive. > > > > Thanks, > > Paul. > > > > [1] https://openjdk.org/projects/babylon/ > > [2] > > > https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 > > > > # Towards a JSON API for the JDK > > > > One of the most common requests for the JDK is an API for > parsing and generating > > JSON. While JSON originated as a text-based serialization format > for JSON > > objects ("JSON" stands for "JavaScript Object Notation"), > because of its simple > > and flexible syntax, it eventually found use outside the > JavaScript ecosystem as > > a general data interchange format, such as framework > configuration files and web > > service requests/response formats. > > > > While the JDK cannot, and should not, provide libraries for > every conceivable > > file format or protocol, the JDK philosophy is one of "batteries > included", > > which is to say we should be able to write basic programs that > use common > > protocols such as HTTP, without having to appeal to third party > libraries. > > The Java ecosystem already has plenty of JSON libraries, so > inclusion in > > the JDK is largely meant to be a convenience, rather than > needing to be the "one > > true" JSON library to meet the needs of all users. Users with > specific needs > > are always free to select one of the existing third-party libraries. > > > > ## Goals and requirements > > > > Our primary goal is that the library be simple to use for > parsing, traversing, > > and generating conformant JSON documents. Advanced features, > such as data > > binding or path-based traversal should be possible to implement > as layered > > features, but for simplicity are not included in the core API. > We adopt a goal > > that the performance should be "good enough", but where performance > > considerations conflict with simplicity and usability, we will > choose in favor > > of the latter. > > > > ## API design approach > > > > The description of JSON at `https:://json.org ` > describes a JSON document using > > the familiar "railroad diagram": > > ![image](https://www.json.org/img/value.png) > > > > This diagram describes an algebraic data type (a sum of > products), which we > > model directly with a set of Java interfaces: > > > > ``` > > interface JsonValue { } > > interface JsonArray extends JsonValue { List values(); } > > interface JsonObject extends JsonValue { Map > members(); } > > interface JsonNumber extends JsonValue { Number toNumber(); } > > interface JsonString extends JsonValue { String value(); } > > interface JsonBoolean extends JsonValue? { boolean value(); } > > interface JsonNull extends JsonValue { } > > ``` > > > > These interfaces have (hidden) companion implementation classes > that admit > > greater flexibility of implementation than modeling them > directly with records > > would permit. > > Further, these interfaces are unsealed. We compromise on the > sealed sum of > > products to enable > > alternative implementations, for example to support alternative > formats that > > encode the same information in a JSON document but in a more > efficient form than > > text. > > > > The API has static methods for parsing strings into a > `JsonValue`, conversion to > > and from purely untyped representations (lists and maps), and > factory methods > > for building JSON documents. We apply composition consistently, > e.g, a > > JsonString has a string, a JsonObject has a map of string to > JsonValue, as > > opposed to extension for structural JSON values. > > > > It turns out that this simple API is almost all we need for > traversal. It gives > > us an immutable representation of a document, and we can use > pattern matching to > > answer the myriad questions that will come up (Does this object > have key X? Does > > it map to a number? Is that number representable as an integer?) > when going > > from an untyped format like JSON to a more strongly typed domain > model. > > Given a simple document like: > > > > ``` > >? ? { > >? ? ? ? "name": "John?, > >? ? ? ? "age": 30 > >? ? } > > ``` > > > > we can parse and traverse the document as follows: > > > > ``` > > JsonValue doc = Json.parse(inputString); > > if (doc instanceof JsonObject o > >? ? && o.members().get("name") instanceof JsonString s > >? ? && s.value() instanceof String name > >? ? && o.members().get("age") instanceof JsonNumber n > >? ? && n.toNumber() instanceof Long l && l instanceof int age) { > >? ? ? ? ? ? // use "name" and "age" > >? ? ? ? } > > ``` > > > > Later, when the language acquires the ability to expose > deconstruction patterns > > for arbitrary interfaces (similar to today's record patterns, see > > > https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), > > this will be simplifiable to: > > > > ``` > > JsonValue doc = Json.parse(inputString); > > if (doc instanceof JsonObject(var members) > >? ? && members.get("name") instanceof JsonString(String name) > >? ? && members.get("age") instanceof JsonNumber(int age)) { > >? ? ? ? ? ? // use "name" and "age" > >? ? ? ? } > > ``` > > > > So, overtime, as more pattern matching features are introduced > we anticipate > > improved use of the API. This is a primary reason why the API is > so minimal. > > Convenience methods we add today, such as a method that accesses > a JSON > > object component as say a JSON string or throws an exception, > will become > > redundant in the future. > > > > ## JSON numbers > > > > The specification of JSON number makes no explicit distinction > between integral > > and decimal numbers, nor specifies limits on the size of those > numbers. > > This is a common source of interoperability issues when > consuming JSON > > documents. Generally users cannot always but often do assume > JSON numbers are > > parsable, without loss of precision, to IEEE double-precision > floating point > > numbers or 32-bit signed integers. > > > > In this respect the API provides three means to operate on the > JSON number, > > giving the user full control: > > > > 1. Underlying string representation can be obtained, if > preserving syntactic > >? ?details such as leading or trailing zeros is important. > > 2. The string representation can be parsed to an instance of > `BigDecimal`, using > >? ?`toBigDecimal` if preserving decimal numbers is important. > > 3. The string representation can be parsed into an instance of > `Long`, `Double`, > >? ?`BigInteger`, or `BigDecimal`, using `toNumber`. The result of > this method > >? ?depends on how the representation can be parsed, possibly > losing precision, > >? ?choosing a suitably convenient numeric type that can then be > pattern > >? ?matched on. > > > > Primitive pattern matching will help as will further pattern > matching features > > enabling the user to partially match. > > > > ## Prototype implementation > > > > The prototype implementation is currently located into the JDK > sandbox > > repository > > under the `json` branch, see > > here > > > https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json > > The prototype API javadoc generated from the repository is also > available at > > > https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html > > > > ### Testing and conformance > > > > The prototype implementation passes all conformance test cases > but two, > > available > > on https://github.com/nst/JSONTestSuite. The two exceptions are > the ones which > > the > > prototype specifically prohibits, i.e, duplicated names in JSON > objects > > > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). > > > > ### Performance > > > > Our main focus so far has been on the API design and a functional > > implementation. > > Hence, there has been less focus on performance even though we > know there are a > > number of performance enhancements we can make eventually. > > We are reasonably happy with the current performance. The > > implementation performs well when compared to other JSON > implementations > > parsing from string instances and traversing documents. > > > > An example of where we may choose simplicity and usability over > performance > > is the rejection of JSON documents containing objects that in > turn contain > > members > > with duplicate names. That may increase the cost of parsing, but > simplifies the > > user > > experience for the majority of cases since if we reasonably > assume JsonObjects > > are > > map-like, what should the user do with such members, pick one > the last one? > > merge > > the values? or reject? > > > > ## A JSON JEP? > > > > We plan to draft JEP when we are ready. Attentive readers will > observe that > > a JEP already exists, JEP 198: Light-Weight JSON API > > (https://openjdk.org/jeps/198). We will > > either update this JEP, or withdraw it and draft a new one. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Fri May 16 13:17:16 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 May 2025 09:17:16 -0400 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: At first, we were hopeful that we could jump right to JSON5, which appears at first glance to be a strictly lexical, more permissive grammar for JSON (supporting comments, trailing commas, more flexible quoting, white space, etc.)? If that were actually true, this would have been a slam dunk, since all these lexical niceties don't have an impact on the parsed results.? And JSON5 has been gaining some traction, so it probably could have been a justifiable move to jump right to that. But then we discovered that JSON5 also sneaks in some semantics, by also supporting the exotic numeric values (NaN, infinities, signed zero), which now has consequences for "what is a number", the numeric representation, the API for unpacking numeric values, etc. (Having multiple parsers is one thing; having multiple parsers that produce different semantics is entirely another.)? And inventing a new "JSON5 but not quite" subset would be doing no one any favors. Jsonc seems to be entirely a MS-ecosystem thing; it does not have broad enough traction to be the "one grammar" we accept.? So pure JSON, as specification-challenged as it is, is the logical, though sad, conclusion (for now.) On 5/16/2025 9:02 AM, Lars Bruun-Hansen wrote: > > > Great work. > > > I feel the elephant in the room needs to addressed: JSON comments. I > haven't tested the proposed lib but I cannot see it mentioned so I'm > assuming that comments are not supported. > > For better or worse, the use of jsonc (JSON with comments) is > everywhere in some ecosystems. Unsurprisingly this happens often when > JSON is used as a config file format. Looking at you, Microsoft. > > It would be nice if the JDK's build-in JSON parser at least recognized > this. > > I'm well aware that comments are frowned upon in JSON and not part of > neither the spec at www.json.org nor the RFC-8259. > > Yet, I advocate the JDK JSON library should optionally allow comments > to be ignored when PARSING. This should be an opt-in feature that > would technically treat comments as whitespace during the parsing process. > > This would also be in line with what many other parsers do. For > example, Jackson has "ALLOW_COMMENTS" feature [1]. Also, by > comparison, the build-in parser in the .NET world, known as > System.Text.Json, also supports this [2]. > > > > The "discoverer" of JSON, Douglas Crowford, had this to say [3] on the > topic: > > > [QUOTE] > > I removed comments from JSON because I saw people were using them to > hold parsing directives, a practice which would have destroyed > interoperability. I know that the lack of comments makes some people > sad, but it shouldn't. > > Suppose you are using JSON to keep configuration files, which you > would like to annotate. Go ahead and insert all the comments you like. > Then pipe it through JSMin before handing it to your JSON parser. > > ?[/QUOTE] > > > By not having the ability to ignore comments when parsing we would > effectively force users to use another parser first or a minifier. I > doubt beginners would appreciate that. > > > BTW: The test suite already has tests for comments. > > > /Lars > > > [1]: > https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS > > [2]: > https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties > > [3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr > > > > > On 16/05/2025 01.44, Ethan McCue wrote: >> I present for your consideration the library I made when spiraling >> about this problem space a few years ago >> >> https://github.com/bowbahdoe/json >> >> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html >> >> Notably missing during the design process here were patterns, hence >> the JsonDecoder design. I haven't been able to evaluate how patterns >> affect that on account of them not being out. >> >> I will more thoroughly peruse the draft of java.util.json at a later >> date, but my initial observations/comments: >> >> * I am not sure having JsonValue be distinct from Json has value. >> * toUntyped feels a little strange to me - the only type information >> presumably lost is the sealed-ness of the hierarchy. The interplay >> between that and toNumber is also a little unnerving. >> * One notion that I found helpful was that a class could be "json >> encodable," meaning there is a method to call to obtain a canonical >> json representation. >> >> record Person(String name) implements JsonEncodable { >> @Override >> ? ? public Json toJson() { >> ? ? ? ? return Json.objectBuilder() >> ? ? ? ? ? ? .put("namen", name) >> ? ? ? ? ? ? .build(); >> ? ? } >> } >> >> Which helper methods like Json#of(List> JsonEncodable>)?could make use of. Json?itself (JsonValue?in your >> prototype) could then have a vacuous implementation. >> >> * Terminology wise - I went with reading/writing for the actual >> parsing/generation of json and encoding/decoding for the mapping of >> those representations to/from specific classes. The merits are not >> top of mind, just noting the difference. read/write vs >> parse/toString+toDisplayString >> * One thing I did was make the helper methods in Json?null tolerant >> and the ones in the specific subtypes like JsonString?not. This was >> because from what I saw of usages of javax.json/jakarta.json that >> nullability was a footgun and correcting for?it required changes to >> code structure (breaking up builder chains with if (x != null)?checks) >> * The functionality you want from JsonNumber could be achieved by >> making it just extend Number >> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java) >> instead of a bespoke toNumber. You need the extra methods to go to >> big decimal and co, but it's just an extension to the behavior of >> Number at that point. >> * JsonObject and JsonArray could implement Map and >> List respectively. This lowers the need for toUntyped() - since >> presumably one of the use cases for that is turning the json tree >> into something that more generic map/list traversal code can handle. >> It also complicates any lazy loading somewhat. >> * Assuming patterns can be placed on interfaces, you might want to >> consider something similar to JsonDecoder, but with a pattern instead >> of a method that throws an exception. >> >> // Where here fromJson would box up the logic for testing and >> extracting from each element in the array. >> List people = array(json, Person::fromJson); >> >> * I don't think there is sufficient cause for anything to be >> non-sealed at this point. >> * JsonBoolean and JsonNull do not have reasonable alternative >> implementations - as far as I can imagine, maybe i'm wrong - so maybe >> those can just be final classes? >> * If you seal up the whole hierarchy then its pretty trivial to make >> it serializable >> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java) >> >> >> >> >> On Thu, May 15, 2025 at 11:29?PM Remi Forax wrote: >> >> Hi Paul, >> yes, not having a simple JSON API in Java is an issue for beginners. >> >> It's not clear to me why JsonArray (for example) has to be an >> interface instead of a record ? >> >> I understand why Json.parse() only works on String and char[] but >> the API make it too easy to have many performance issues. >> I think you need versions using a Reader and a Path. >> Bonus point, if there is a method walk() that also returns a >> JsonValue but the List/Map inside JsonArray/JsonObject are >> populated lazily. >> >> Minor point: Json.toDisplayString() should takes a second >> parameters indicating the number of spaces used for the >> indentation (like JSON.stringify in JS). >> >> regards, >> R?mi >> >> ----- Original Message ----- >> > From: "Paul Sandoz" >> > To: "core-libs-dev" >> > Sent: Thursday, May 15, 2025 10:30:42 PM >> > Subject: Towards a JSON API for the JDK >> >> > Hi, >> > >> > We would like to share with you our thoughts and plans towards >> a JSON API for >> > the JDK. >> > Please see the document below. >> > >> > - >> > >> > We have had the pleasure of using a clone of this API in some >> experiments we are >> > conducting with >> > ONNX and code reflection [1]. Using the API we were able to >> quickly write code >> > to ingest and convert >> > a JSON document representing ONNX operation schema into >> instances of records >> > modeling the schema >> > (see here [2]). >> > >> > The overall out-of-box experience with such a minimal >> "batteries included? API >> > has so far been positive. >> > >> > Thanks, >> > Paul. >> > >> > [1] https://openjdk.org/projects/babylon/ >> > [2] >> > >> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >> > >> > # Towards a JSON API for the JDK >> > >> > One of the most common requests for the JDK is an API for >> parsing and generating >> > JSON. While JSON originated as a text-based serialization >> format for JSON >> > objects ("JSON" stands for "JavaScript Object Notation"), >> because of its simple >> > and flexible syntax, it eventually found use outside the >> JavaScript ecosystem as >> > a general data interchange format, such as framework >> configuration files and web >> > service requests/response formats. >> > >> > While the JDK cannot, and should not, provide libraries for >> every conceivable >> > file format or protocol, the JDK philosophy is one of >> "batteries included", >> > which is to say we should be able to write basic programs that >> use common >> > protocols such as HTTP, without having to appeal to third party >> libraries. >> > The Java ecosystem already has plenty of JSON libraries, so >> inclusion in >> > the JDK is largely meant to be a convenience, rather than >> needing to be the "one >> > true" JSON library to meet the needs of all users. Users with >> specific needs >> > are always free to select one of the existing third-party >> libraries. >> > >> > ## Goals and requirements >> > >> > Our primary goal is that the library be simple to use for >> parsing, traversing, >> > and generating conformant JSON documents. Advanced features, >> such as data >> > binding or path-based traversal should be possible to implement >> as layered >> > features, but for simplicity are not included in the core API. >> We adopt a goal >> > that the performance should be "good enough", but where performance >> > considerations conflict with simplicity and usability, we will >> choose in favor >> > of the latter. >> > >> > ## API design approach >> > >> > The description of JSON at `https:://json.org >> ` describes a JSON document using >> > the familiar "railroad diagram": >> > ![image](https://www.json.org/img/value.png) >> > >> > This diagram describes an algebraic data type (a sum of >> products), which we >> > model directly with a set of Java interfaces: >> > >> > ``` >> > interface JsonValue { } >> > interface JsonArray extends JsonValue { List values(); } >> > interface JsonObject extends JsonValue { Map >> members(); } >> > interface JsonNumber extends JsonValue { Number toNumber(); } >> > interface JsonString extends JsonValue { String value(); } >> > interface JsonBoolean extends JsonValue? { boolean value(); } >> > interface JsonNull extends JsonValue { } >> > ``` >> > >> > These interfaces have (hidden) companion implementation classes >> that admit >> > greater flexibility of implementation than modeling them >> directly with records >> > would permit. >> > Further, these interfaces are unsealed. We compromise on the >> sealed sum of >> > products to enable >> > alternative implementations, for example to support alternative >> formats that >> > encode the same information in a JSON document but in a more >> efficient form than >> > text. >> > >> > The API has static methods for parsing strings into a >> `JsonValue`, conversion to >> > and from purely untyped representations (lists and maps), and >> factory methods >> > for building JSON documents. We apply composition consistently, >> e.g, a >> > JsonString has a string, a JsonObject has a map of string to >> JsonValue, as >> > opposed to extension for structural JSON values. >> > >> > It turns out that this simple API is almost all we need for >> traversal. It gives >> > us an immutable representation of a document, and we can use >> pattern matching to >> > answer the myriad questions that will come up (Does this object >> have key X? Does >> > it map to a number? Is that number representable as an >> integer?) when going >> > from an untyped format like JSON to a more strongly typed >> domain model. >> > Given a simple document like: >> > >> > ``` >> >? ? { >> >? ? ? ? "name": "John?, >> >? ? ? ? "age": 30 >> >? ? } >> > ``` >> > >> > we can parse and traverse the document as follows: >> > >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject o >> >? ? && o.members().get("name") instanceof JsonString s >> >? ? && s.value() instanceof String name >> >? ? && o.members().get("age") instanceof JsonNumber n >> >? ? && n.toNumber() instanceof Long l && l instanceof int age) { >> >? ? ? ? ? ? // use "name" and "age" >> >? ? ? ? } >> > ``` >> > >> > Later, when the language acquires the ability to expose >> deconstruction patterns >> > for arbitrary interfaces (similar to today's record patterns, see >> > >> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), >> > this will be simplifiable to: >> > >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject(var members) >> >? ? && members.get("name") instanceof JsonString(String name) >> >? ? && members.get("age") instanceof JsonNumber(int age)) { >> >? ? ? ? ? ? // use "name" and "age" >> >? ? ? ? } >> > ``` >> > >> > So, overtime, as more pattern matching features are introduced >> we anticipate >> > improved use of the API. This is a primary reason why the API >> is so minimal. >> > Convenience methods we add today, such as a method that >> accesses a JSON >> > object component as say a JSON string or throws an exception, >> will become >> > redundant in the future. >> > >> > ## JSON numbers >> > >> > The specification of JSON number makes no explicit distinction >> between integral >> > and decimal numbers, nor specifies limits on the size of those >> numbers. >> > This is a common source of interoperability issues when >> consuming JSON >> > documents. Generally users cannot always but often do assume >> JSON numbers are >> > parsable, without loss of precision, to IEEE double-precision >> floating point >> > numbers or 32-bit signed integers. >> > >> > In this respect the API provides three means to operate on the >> JSON number, >> > giving the user full control: >> > >> > 1. Underlying string representation can be obtained, if >> preserving syntactic >> >? ?details such as leading or trailing zeros is important. >> > 2. The string representation can be parsed to an instance of >> `BigDecimal`, using >> >? ?`toBigDecimal` if preserving decimal numbers is important. >> > 3. The string representation can be parsed into an instance of >> `Long`, `Double`, >> >? ?`BigInteger`, or `BigDecimal`, using `toNumber`. The result >> of this method >> >? ?depends on how the representation can be parsed, possibly >> losing precision, >> >? ?choosing a suitably convenient numeric type that can then be >> pattern >> >? ?matched on. >> > >> > Primitive pattern matching will help as will further pattern >> matching features >> > enabling the user to partially match. >> > >> > ## Prototype implementation >> > >> > The prototype implementation is currently located into the JDK >> sandbox >> > repository >> > under the `json` branch, see >> > here >> > >> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >> > The prototype API javadoc generated from the repository is also >> available at >> > >> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >> > >> > ### Testing and conformance >> > >> > The prototype implementation passes all conformance test cases >> but two, >> > available >> > on https://github.com/nst/JSONTestSuite. The two exceptions are >> the ones which >> > the >> > prototype specifically prohibits, i.e, duplicated names in JSON >> objects >> > >> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). >> > >> > ### Performance >> > >> > Our main focus so far has been on the API design and a functional >> > implementation. >> > Hence, there has been less focus on performance even though we >> know there are a >> > number of performance enhancements we can make eventually. >> > We are reasonably happy with the current performance. The >> > implementation performs well when compared to other JSON >> implementations >> > parsing from string instances and traversing documents. >> > >> > An example of where we may choose simplicity and usability over >> performance >> > is the rejection of JSON documents containing objects that in >> turn contain >> > members >> > with duplicate names. That may increase the cost of parsing, >> but simplifies the >> > user >> > experience for the majority of cases since if we reasonably >> assume JsonObjects >> > are >> > map-like, what should the user do with such members, pick one >> the last one? >> > merge >> > the values? or reject? >> > >> > ## A JSON JEP? >> > >> > We plan to draft JEP when we are ready. Attentive readers will >> observe that >> > a JEP already exists, JEP 198: Light-Weight JSON API >> > (https://openjdk.org/jeps/198). We will >> > either update this JEP, or withdraw it and draft a new one. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyazici at openjdk.org Fri May 16 13:29:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 16 May 2025 13:29:55 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v2] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 09:45:43 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - assert > - document add warnings @wenshao, thanks for the kind effort ? dropped suggestions to match the messages with the ones in JLA. I prefer *all*1 `public`, `unchecked`-prefixed `DecimalDigits` methods to start with a sufficient `assert` preamble, to fail as early as possible. Though I don't want to create redundant extra work, hence double checking: @jaikiran, @minborg, @liach, WDYT? 1 Currently, only two `private` methods are introduced `assert`s, which are fine. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 147: > 145: * integer. > 146: *

      > 147: * WARNING: Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Suggestion: * WARNING: This method does not perform any bound checks. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 198: > 196: * long. > 197: *

      > 198: * WARNING: Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Suggestion: * WARNING: This method does not perform any bound checks. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 251: > 249: * UTF-16 coder. > 250: *

      > 251: * WARNING: Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Suggestion: * WARNING: This method does not perform any bound checks. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 294: > 292: * UTF-16 coder. > 293: *

      > 294: * WARNING: Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Suggestion: * WARNING: This method does not perform any bound checks. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 409: > 407: * only least significant 16 bits of {@code v} are used. > 408: *

      > 409: * WARNING: Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Suggestion: * WARNING: This method does not perform any bound checks. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 440: > 438: *

      > 439: * WARNING: Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. > 440: */ No need for this level of verbosity for private methods. Suggestion: src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 449: > 447: *

      > 448: * WARNING: Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. > 449: */ No need for this level of verbosity for private methods. Suggestion: ------------- PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2846561005 PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093002611 PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093005955 PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093006521 PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093007264 PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093009890 PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093014576 PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093015088 From duke at openjdk.org Fri May 16 13:32:54 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 16 May 2025 13:32:54 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Thu, 15 May 2025 22:43:54 GMT, Shaojin Wen wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> make magBitLength() an instance method > > src/java.base/share/classes/java/math/BigInteger.java line 3860: > >> 3858: && Integer.lowestOneBit(mag[0]) == mag[0] >> 3859: && numberOfTrailingZeroInts() == mag.length - 1 >> 3860: ? magBitLength() - 1 : magBitLength(); > > Suggestion: > > int[] mag = this.mag; > return magBitLength() > - (signum < 0 > // Check if magnitude is a power of two > && Integer.lowestOneBit(mag[0]) == mag[0] > && numberOfTrailingZeroInts() == mag.length - 1 > ? 1 : 0); > > > In this way, codeSize will drop from 52 to 45 What is the usefulness of doing `int[] mag = this.mag;` at line 3856? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2093057326 From iklam at openjdk.org Fri May 16 13:55:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 16 May 2025 13:55:01 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Tests passed. Thank you @TimPushkin for contributing this fix to OpenJDK! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2886788769 From tpushkin at openjdk.org Fri May 16 13:55:02 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 16 May 2025 13:55:02 GMT Subject: Integrated: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive In-Reply-To: References: Message-ID: <02V6k1T_kM2Aq8FAjh_iNUBd0XOytqkaR1Bk_g38iNc=.6abbc194-f49d-42de-9c96-3baf2857429f@github.com> On Tue, 25 Mar 2025 11:08:24 GMT, Timofei Pushkin wrote: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. This pull request has now been integrated. Changeset: 46a12e78 Author: Timofei Pushkin Committer: Ioi Lam URL: https://git.openjdk.org/jdk/commit/46a12e781edcbe9da7bd39eb9e101fc680053cef Stats: 671 lines in 13 files changed: 486 ins; 122 del; 63 mod 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/24223 From rotanolexandr842 at gmail.com Fri May 16 14:06:06 2025 From: rotanolexandr842 at gmail.com (Olexandr Rotan) Date: Fri, 16 May 2025 17:06:06 +0300 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I would like to add JSON comments from my perspective. I had a requirement of working with JSON in java multiple times during working on the university assignments recently. Since those are small, often one-time-open projects, I did not want (or, often, it was forbidden by assignment) to pull in whole jackson with modules and staff, along with gradle and rocket launchers, so i had to work out my own small parser for the JSON, since this is a pretty trivial task in its core. I want to note that none of the times I had the necessity to write comments in the JSON or parse input with them.That is why I think that for the cases when you would use raw jdk JSON API, comments in the JSON are extremely exotic. On the other hand, If you are working on the full-blown enterprise-grade project, and want the JSON to facilitate your configs, then use yaml you will most likely already have your JSON parser with comments support included by your framework, whether it is jackson, gson or something else. I think the key point here is that jdk JSON API, as it seems to me, does not aim to obsolete any of the existing (de)serialization libraries, and is rather intended to be the core, backbone of those, along with the direct JSON support for the simplest cases, much like virtually no one uses security mechanisms of the JDK directly instead of relying on libraries/frameworks aka spring security. I think voice on whether to add some non-standard syntax support for JSON here belongs to maintainers of such libraries. To me, at least, it seems like this libs will be able to use this API with some required preprocessing done on the raw strings before, via regex or any other more performant/comfortable method Best regards On Fri, May 16, 2025 at 4:17?PM Brian Goetz wrote: > At first, we were hopeful that we could jump right to JSON5, which appears > at first glance to be a strictly lexical, more permissive grammar for JSON > (supporting comments, trailing commas, more flexible quoting, white space, > etc.) If that were actually true, this would have been a slam dunk, since > all these lexical niceties don't have an impact on the parsed results. And > JSON5 has been gaining some traction, so it probably could have been a > justifiable move to jump right to that. > > But then we discovered that JSON5 also sneaks in some semantics, by also > supporting the exotic numeric values (NaN, infinities, signed zero), which > now has consequences for "what is a number", the numeric representation, > the API for unpacking numeric values, etc. (Having multiple parsers is one > thing; having multiple parsers that produce different semantics is entirely > another.) And inventing a new "JSON5 but not quite" subset would be doing > no one any favors. > > Jsonc seems to be entirely a MS-ecosystem thing; it does not have broad > enough traction to be the "one grammar" we accept. So pure JSON, as > specification-challenged as it is, is the logical, though sad, conclusion > (for now.) > > > > On 5/16/2025 9:02 AM, Lars Bruun-Hansen wrote: > > > Great work. > > > I feel the elephant in the room needs to addressed: JSON comments. I > haven't tested the proposed lib but I cannot see it mentioned so I'm > assuming that comments are not supported. > > For better or worse, the use of jsonc (JSON with comments) is everywhere > in some ecosystems. Unsurprisingly this happens often when JSON is used as > a config file format. Looking at you, Microsoft. > > It would be nice if the JDK's build-in JSON parser at least recognized > this. > > I'm well aware that comments are frowned upon in JSON and not part of > neither the spec at www.json.org nor the RFC-8259. > > Yet, I advocate the JDK JSON library should optionally allow comments to > be ignored when PARSING. This should be an opt-in feature that would > technically treat comments as whitespace during the parsing process. > > This would also be in line with what many other parsers do. For example, > Jackson has "ALLOW_COMMENTS" feature [1]. Also, by comparison, the build-in > parser in the .NET world, known as System.Text.Json, also supports this > [2]. > > > > The "discoverer" of JSON, Douglas Crowford, had this to say [3] on the > topic: > > > [QUOTE] > > I removed comments from JSON because I saw people were using them to hold > parsing directives, a practice which would have destroyed interoperability. > I know that the lack of comments makes some people sad, but it shouldn't. > > Suppose you are using JSON to keep configuration files, which you would > like to annotate. Go ahead and insert all the comments you like. Then pipe > it through JSMin before handing it to your JSON parser. > > [/QUOTE] > > > By not having the ability to ignore comments when parsing we would > effectively force users to use another parser first or a minifier. I doubt > beginners would appreciate that. > > > BTW: The test suite already has tests for comments. > > > /Lars > > > [1]: > https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS > > [2]: > https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties > > [3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr > > > > > On 16/05/2025 01.44, Ethan McCue wrote: > > I present for your consideration the library I made when spiraling about > this problem space a few years ago > > https://github.com/bowbahdoe/json > > > https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html > > Notably missing during the design process here were patterns, hence the > JsonDecoder design. I haven't been able to evaluate how patterns affect > that on account of them not being out. > > I will more thoroughly peruse the draft of java.util.json at a later date, > but my initial observations/comments: > > * I am not sure having JsonValue be distinct from Json has value. > * toUntyped feels a little strange to me - the only type information > presumably lost is the sealed-ness of the hierarchy. The interplay between > that and toNumber is also a little unnerving. > * One notion that I found helpful was that a class could be "json > encodable," meaning there is a method to call to obtain a canonical json > representation. > > record Person(String name) implements JsonEncodable { > @Override > public Json toJson() { > return Json.objectBuilder() > .put("namen", name) > .build(); > } > } > > Which helper methods like Json#of(List) could > make use of. Json itself (JsonValue in your prototype) could then have a > vacuous implementation. > > * Terminology wise - I went with reading/writing for the actual > parsing/generation of json and encoding/decoding for the mapping of those > representations to/from specific classes. The merits are not top of mind, > just noting the difference. read/write vs parse/toString+toDisplayString > * One thing I did was make the helper methods in Json null tolerant and > the ones in the specific subtypes like JsonString not. This was because > from what I saw of usages of javax.json/jakarta.json that nullability was a > footgun and correcting for it required changes to code structure (breaking > up builder chains with if (x != null) checks) > * The functionality you want from JsonNumber could be achieved by making > it just extend Number ( > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java) > instead of a bespoke toNumber. You need the extra methods to go to big > decimal and co, but it's just an extension to the behavior of Number at > that point. > * JsonObject and JsonArray could implement Map and > List respectively. This lowers the need for toUntyped() - since > presumably one of the use cases for that is turning the json tree into > something that more generic map/list traversal code can handle. It also > complicates any lazy loading somewhat. > * Assuming patterns can be placed on interfaces, you might want to > consider something similar to JsonDecoder, but with a pattern instead of > a method that throws an exception. > > // Where here fromJson would box up the logic for testing and extracting > from each element in the array. > List people = array(json, Person::fromJson); > > * I don't think there is sufficient cause for anything to be non-sealed at > this point. > * JsonBoolean and JsonNull do not have reasonable alternative > implementations - as far as I can imagine, maybe i'm wrong - so maybe those > can just be final classes? > * If you seal up the whole hierarchy then its pretty trivial to make it > serializable ( > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java > ) > > > > > On Thu, May 15, 2025 at 11:29?PM Remi Forax wrote: > >> Hi Paul, >> yes, not having a simple JSON API in Java is an issue for beginners. >> >> It's not clear to me why JsonArray (for example) has to be an interface >> instead of a record ? >> >> I understand why Json.parse() only works on String and char[] but the API >> make it too easy to have many performance issues. >> I think you need versions using a Reader and a Path. >> Bonus point, if there is a method walk() that also returns a JsonValue >> but the List/Map inside JsonArray/JsonObject are populated lazily. >> >> Minor point: Json.toDisplayString() should takes a second parameters >> indicating the number of spaces used for the indentation (like >> JSON.stringify in JS). >> >> regards, >> R?mi >> >> ----- Original Message ----- >> > From: "Paul Sandoz" >> > To: "core-libs-dev" >> > Sent: Thursday, May 15, 2025 10:30:42 PM >> > Subject: Towards a JSON API for the JDK >> >> > Hi, >> > >> > We would like to share with you our thoughts and plans towards a JSON >> API for >> > the JDK. >> > Please see the document below. >> > >> > - >> > >> > We have had the pleasure of using a clone of this API in some >> experiments we are >> > conducting with >> > ONNX and code reflection [1]. Using the API we were able to quickly >> write code >> > to ingest and convert >> > a JSON document representing ONNX operation schema into instances of >> records >> > modeling the schema >> > (see here [2]). >> > >> > The overall out-of-box experience with such a minimal "batteries >> included? API >> > has so far been positive. >> > >> > Thanks, >> > Paul. >> > >> > [1] https://openjdk.org/projects/babylon/ >> > [2] >> > >> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >> > >> > # Towards a JSON API for the JDK >> > >> > One of the most common requests for the JDK is an API for parsing and >> generating >> > JSON. While JSON originated as a text-based serialization format for >> JSON >> > objects ("JSON" stands for "JavaScript Object Notation"), because of >> its simple >> > and flexible syntax, it eventually found use outside the JavaScript >> ecosystem as >> > a general data interchange format, such as framework configuration >> files and web >> > service requests/response formats. >> > >> > While the JDK cannot, and should not, provide libraries for every >> conceivable >> > file format or protocol, the JDK philosophy is one of "batteries >> included", >> > which is to say we should be able to write basic programs that use >> common >> > protocols such as HTTP, without having to appeal to third party >> libraries. >> > The Java ecosystem already has plenty of JSON libraries, so inclusion in >> > the JDK is largely meant to be a convenience, rather than needing to be >> the "one >> > true" JSON library to meet the needs of all users. Users with specific >> needs >> > are always free to select one of the existing third-party libraries. >> > >> > ## Goals and requirements >> > >> > Our primary goal is that the library be simple to use for parsing, >> traversing, >> > and generating conformant JSON documents. Advanced features, such as >> data >> > binding or path-based traversal should be possible to implement as >> layered >> > features, but for simplicity are not included in the core API. We adopt >> a goal >> > that the performance should be "good enough", but where performance >> > considerations conflict with simplicity and usability, we will choose >> in favor >> > of the latter. >> > >> > ## API design approach >> > >> > The description of JSON at `https:://json.org` describes a JSON >> document using >> > the familiar "railroad diagram": >> > ![image](https://www.json.org/img/value.png) >> > >> > This diagram describes an algebraic data type (a sum of products), >> which we >> > model directly with a set of Java interfaces: >> > >> > ``` >> > interface JsonValue { } >> > interface JsonArray extends JsonValue { List values(); } >> > interface JsonObject extends JsonValue { Map >> members(); } >> > interface JsonNumber extends JsonValue { Number toNumber(); } >> > interface JsonString extends JsonValue { String value(); } >> > interface JsonBoolean extends JsonValue { boolean value(); } >> > interface JsonNull extends JsonValue { } >> > ``` >> > >> > These interfaces have (hidden) companion implementation classes that >> admit >> > greater flexibility of implementation than modeling them directly with >> records >> > would permit. >> > Further, these interfaces are unsealed. We compromise on the sealed sum >> of >> > products to enable >> > alternative implementations, for example to support alternative formats >> that >> > encode the same information in a JSON document but in a more efficient >> form than >> > text. >> > >> > The API has static methods for parsing strings into a `JsonValue`, >> conversion to >> > and from purely untyped representations (lists and maps), and factory >> methods >> > for building JSON documents. We apply composition consistently, e.g, a >> > JsonString has a string, a JsonObject has a map of string to JsonValue, >> as >> > opposed to extension for structural JSON values. >> > >> > It turns out that this simple API is almost all we need for traversal. >> It gives >> > us an immutable representation of a document, and we can use pattern >> matching to >> > answer the myriad questions that will come up (Does this object have >> key X? Does >> > it map to a number? Is that number representable as an integer?) when >> going >> > from an untyped format like JSON to a more strongly typed domain model. >> > Given a simple document like: >> > >> > ``` >> > { >> > "name": "John?, >> > "age": 30 >> > } >> > ``` >> > >> > we can parse and traverse the document as follows: >> > >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject o >> > && o.members().get("name") instanceof JsonString s >> > && s.value() instanceof String name >> > && o.members().get("age") instanceof JsonNumber n >> > && n.toNumber() instanceof Long l && l instanceof int age) { >> > // use "name" and "age" >> > } >> > ``` >> > >> > Later, when the language acquires the ability to expose deconstruction >> patterns >> > for arbitrary interfaces (similar to today's record patterns, see >> > >> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns >> ), >> > this will be simplifiable to: >> > >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject(var members) >> > && members.get("name") instanceof JsonString(String name) >> > && members.get("age") instanceof JsonNumber(int age)) { >> > // use "name" and "age" >> > } >> > ``` >> > >> > So, overtime, as more pattern matching features are introduced we >> anticipate >> > improved use of the API. This is a primary reason why the API is so >> minimal. >> > Convenience methods we add today, such as a method that accesses a JSON >> > object component as say a JSON string or throws an exception, will >> become >> > redundant in the future. >> > >> > ## JSON numbers >> > >> > The specification of JSON number makes no explicit distinction between >> integral >> > and decimal numbers, nor specifies limits on the size of those numbers. >> > This is a common source of interoperability issues when consuming JSON >> > documents. Generally users cannot always but often do assume JSON >> numbers are >> > parsable, without loss of precision, to IEEE double-precision floating >> point >> > numbers or 32-bit signed integers. >> > >> > In this respect the API provides three means to operate on the JSON >> number, >> > giving the user full control: >> > >> > 1. Underlying string representation can be obtained, if preserving >> syntactic >> > details such as leading or trailing zeros is important. >> > 2. The string representation can be parsed to an instance of >> `BigDecimal`, using >> > `toBigDecimal` if preserving decimal numbers is important. >> > 3. The string representation can be parsed into an instance of `Long`, >> `Double`, >> > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this >> method >> > depends on how the representation can be parsed, possibly losing >> precision, >> > choosing a suitably convenient numeric type that can then be pattern >> > matched on. >> > >> > Primitive pattern matching will help as will further pattern matching >> features >> > enabling the user to partially match. >> > >> > ## Prototype implementation >> > >> > The prototype implementation is currently located into the JDK sandbox >> > repository >> > under the `json` branch, see >> > here >> > >> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >> > The prototype API javadoc generated from the repository is also >> available at >> > >> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >> > >> > ### Testing and conformance >> > >> > The prototype implementation passes all conformance test cases but two, >> > available >> > on https://github.com/nst/JSONTestSuite. The two exceptions are the >> ones which >> > the >> > prototype specifically prohibits, i.e, duplicated names in JSON objects >> > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35 >> ). >> > >> > ### Performance >> > >> > Our main focus so far has been on the API design and a functional >> > implementation. >> > Hence, there has been less focus on performance even though we know >> there are a >> > number of performance enhancements we can make eventually. >> > We are reasonably happy with the current performance. The >> > implementation performs well when compared to other JSON implementations >> > parsing from string instances and traversing documents. >> > >> > An example of where we may choose simplicity and usability over >> performance >> > is the rejection of JSON documents containing objects that in turn >> contain >> > members >> > with duplicate names. That may increase the cost of parsing, but >> simplifies the >> > user >> > experience for the majority of cases since if we reasonably assume >> JsonObjects >> > are >> > map-like, what should the user do with such members, pick one the last >> one? >> > merge >> > the values? or reject? >> > >> > ## A JSON JEP? >> > >> > We plan to draft JEP when we are ready. Attentive readers will observe >> that >> > a JEP already exists, JEP 198: Light-Weight JSON API >> > (https://openjdk.org/jeps/198). We will >> > either update this JEP, or withdraw it and draft a new one. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Fri May 16 14:13:51 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 14:13:51 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v2] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 09:45:43 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - assert > - document add warnings Re assert preamble for public methods: Unfortunately this is not possible. The algorithm requires the chars to be written on demand, and it is very costly to precompute the length, aside from the fact that you can easily mess up on precomputation. The uncheckedness is from the 2 private methods, so I think safeguarding the 2 private methods with assertions is sufficient. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2886837958 From abarashev at openjdk.org Fri May 16 14:18:04 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 16 May 2025 14:18:04 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits: > > - merge latest changes from master branch > - Undo whitespace change > - Remove unnecessary import > - Merge remote-tracking branch 'origin/master' into http3 > - Fix test license > - Remove leftover file (test was moved to parent directory) > - Remove unnecessary import > - Update throws clauses > - Merge remote-tracking branch 'origin/master' into http3 > - 8354275: Add HTTP/3 tests to `EmptyAuthenticate` > - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c @seanjmullan @djelinski We should probably re-evaluate the priority of `TLS Certificate Compression` JEP: https://bugs.openjdk.org/browse/JDK-8281710 Certificate compression seems to be [particularly important for QUIC performance](https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study), the work has been started already in #7599 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2886849963 From jpai at openjdk.org Fri May 16 14:25:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 14:25:59 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Changes based on review feedback. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114: > 112: private final ZipPath rootdir; > 113: // Starts in readOnly (safe mode), but might be reset at the end of initialization. > 114: private boolean readOnly = true; If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093154523 From lbruun at apache.org Fri May 16 14:28:38 2025 From: lbruun at apache.org (Lars Bruun-Hansen) Date: Fri, 16 May 2025 16:28:38 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <2bae7231-7d5d-47d0-8eea-1ef1b4030b6b@apache.org> Ahh, as expected some great thoughts have gone into this. :-) Allowing the ignore of comments when parsing is not "inventing a new format", IMO. More so because the RFC allows it (section 9) and because it would be strictly opt-in. So the parser can still be said to be strictly RFC-8259 while optionally supporting such feature. I'm speculating the authors of the RFC has thought of it as a form a pre-processing when they used the word "extension" and that is indeed a good way to think about it. In any case my goal was purely comments in the JSON, not about allowing other forms of leniency, like trailing commas, flexible quotes, etc. I feel those are in another category and not something that should (ever) be supported. I can see why someone might ask for that if comments where allowed to be ignored by the lib. The argument about slippery slope can be made. I just fear that newbies will try to build their own pre-processor, using regexp or whatever .. and get it wrong. I agree with you that JSON5 sneaks in too many odd things. Keep up the good work. /Lars On 16/05/2025 15.17, Brian Goetz wrote: > At first, we were hopeful that we could jump right to JSON5, which > appears at first glance to be a strictly lexical, more permissive > grammar for JSON (supporting comments, trailing commas, more flexible > quoting, white space, etc.)? If that were actually true, this would > have been a slam dunk, since all these lexical niceties don't have an > impact on the parsed results.? And JSON5 has been gaining some > traction, so it probably could have been a justifiable move to jump > right to that.? > > But then we discovered that JSON5 also sneaks in some semantics, by > also supporting the exotic numeric values (NaN, infinities, signed > zero), which now has consequences for "what is a number", the numeric > representation, the API for unpacking numeric values, etc.? (Having > multiple parsers is one thing; having multiple parsers that produce > different semantics is entirely another.)? And inventing a new "JSON5 > but not quite" subset would be doing no one any favors.? > > Jsonc seems to be entirely a MS-ecosystem thing; it does not have > broad enough traction to be the "one grammar" we accept.? So pure > JSON, as specification-challenged as it is, is the logical, though > sad, conclusion (for now.) > > > > On 5/16/2025 9:02 AM, Lars Bruun-Hansen wrote: >> >> >> Great work. >> >> >> I feel the elephant in the room needs to addressed: JSON comments. I >> haven't tested the proposed lib but I cannot see it mentioned so I'm >> assuming that comments are not supported. >> >> For better or worse, the use of jsonc (JSON with comments) is >> everywhere in some ecosystems. Unsurprisingly this happens often when >> JSON is used as a config file format. Looking at you, Microsoft. >> >> It would be nice if the JDK's build-in JSON parser at least >> recognized this. >> >> I'm well aware that comments are frowned upon in JSON and not part of >> neither the spec at www.json.org nor the RFC-8259. >> >> Yet, I advocate the JDK JSON library should optionally allow comments >> to be ignored when PARSING. This should be an opt-in feature that >> would technically treat comments as whitespace during the parsing >> process. >> >> This would also be in line with what many other parsers do. For >> example, Jackson has "ALLOW_COMMENTS" feature [1]. Also, by >> comparison, the build-in parser in the .NET world, known as >> System.Text.Json, also supports this [2]. >> >> >> >> The "discoverer" of JSON, Douglas Crowford, had this to say [3] on >> the topic: >> >> >> [QUOTE] >> >> I removed comments from JSON because I saw people were using them to >> hold parsing directives, a practice which would have destroyed >> interoperability. I know that the lack of comments makes some people >> sad, but it shouldn't. >> >> Suppose you are using JSON to keep configuration files, which you >> would like to annotate. Go ahead and insert all the comments you >> like. Then pipe it through JSMin before handing it to your JSON parser. >> >> ?[/QUOTE] >> >> >> By not having the ability to ignore comments when parsing we would >> effectively force users to use another parser first or a minifier. I >> doubt beginners would appreciate that. >> >> >> BTW: The test suite already has tests for comments. >> >> >> /Lars >> >> >> [1]: >> https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS >> >> [2]: >> https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties >> >> [3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr >> >> >> >> >> On 16/05/2025 01.44, Ethan McCue wrote: >>> I present for your consideration the library I made when spiraling >>> about this problem space a few years ago >>> >>> https://github.com/bowbahdoe/json >>> >>> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html >>> >>> Notably missing during the design process here were patterns, hence >>> the JsonDecoder design. I haven't been able to evaluate how patterns >>> affect that on account of them not being out. >>> >>> I will more thoroughly peruse the draft of java.util.json at a later >>> date, but my initial observations/comments: >>> >>> * I am not sure having JsonValue be distinct from Json has value. >>> * toUntyped feels a little strange to me - the only type information >>> presumably lost is the sealed-ness of the hierarchy. The interplay >>> between that and toNumber is also a little unnerving. >>> * One notion that I found helpful was that a class could be "json >>> encodable," meaning there is a method to call to obtain a canonical >>> json representation. >>> >>> record Person(String name) implements JsonEncodable { >>> ? ??@Override >>> ? ? public Json toJson() { >>> ? ? ? ? return Json.objectBuilder() >>> ? ? ? ? ? ? .put("namen", name) >>> ? ? ? ? ? ? .build(); >>> ? ? } >>> } >>> >>> Which helper methods like Json#of(List>> JsonEncodable>)?could make use of. Json?itself (JsonValue?in your >>> prototype) could then have a vacuous implementation. >>> >>> * Terminology wise - I went with reading/writing for the actual >>> parsing/generation of json and encoding/decoding for the mapping of >>> those representations to/from specific classes. The merits are not >>> top of mind, just noting the difference. read/write vs >>> parse/toString+toDisplayString >>> * One thing I did was make the helper methods in Json?null tolerant >>> and the ones in the specific subtypes like JsonString?not. This was >>> because from what I saw of usages of javax.json/jakarta.json that >>> nullability was a footgun and correcting for?it required changes to >>> code structure (breaking up builder chains with if (x != null)?checks) >>> * The functionality you want from JsonNumber could be achieved by >>> making it just extend Number >>> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java) >>> instead of a bespoke toNumber. You need the extra methods to go to >>> big decimal and co, but it's just an extension to the behavior of >>> Number at that point. >>> * JsonObject and JsonArray could implement Map and >>> List respectively. This lowers the need for toUntyped() - >>> since presumably one of the use cases for that is turning the json >>> tree into something that more generic map/list traversal code can >>> handle. It also complicates any lazy loading somewhat. >>> * Assuming patterns can be placed on interfaces, you might want to >>> consider something similar to?JsonDecoder, but with a pattern >>> instead of a method that throws an exception. >>> >>> // Where here fromJson would box up the logic for testing and >>> extracting from each element in the array. >>> List people = array(json, Person::fromJson); >>> >>> * I don't think there is sufficient cause for anything to be >>> non-sealed at this point. >>> * JsonBoolean and JsonNull do not have reasonable alternative >>> implementations - as far as I can imagine, maybe i'm wrong - so >>> maybe those can just be final classes? >>> * If you seal up the whole hierarchy then its pretty trivial to make >>> it serializable >>> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java) >>> >>> >>> >>> >>> On Thu, May 15, 2025 at 11:29?PM Remi Forax wrote: >>> >>> Hi Paul, >>> yes, not having a simple JSON API in Java is an issue for beginners. >>> >>> It's not clear to me why JsonArray (for example) has to be an >>> interface instead of a record ? >>> >>> I understand why Json.parse() only works on String and char[] >>> but the API make it too easy to have many performance issues. >>> I think you need versions using a Reader and a Path. >>> Bonus point, if there is a method walk() that also returns a >>> JsonValue but the List/Map inside JsonArray/JsonObject are >>> populated lazily. >>> >>> Minor point: Json.toDisplayString() should takes a second >>> parameters indicating the number of spaces used for the >>> indentation (like JSON.stringify in JS). >>> >>> regards, >>> R?mi >>> >>> ----- Original Message ----- >>> > From: "Paul Sandoz" >>> > To: "core-libs-dev" >>> > Sent: Thursday, May 15, 2025 10:30:42 PM >>> > Subject: Towards a JSON API for the JDK >>> >>> > Hi, >>> > >>> > We would like to share with you our thoughts and plans towards >>> a JSON API for >>> > the JDK. >>> > Please see the document below. >>> > >>> > - >>> > >>> > We have had the pleasure of using a clone of this API in some >>> experiments we are >>> > conducting with >>> > ONNX and code reflection [1]. Using the API we were able to >>> quickly write code >>> > to ingest and convert >>> > a JSON document representing ONNX operation schema into >>> instances of records >>> > modeling the schema >>> > (see here [2]). >>> > >>> > The overall out-of-box experience with such a minimal >>> "batteries included? API >>> > has so far been positive. >>> > >>> > Thanks, >>> > Paul. >>> > >>> > [1] https://openjdk.org/projects/babylon/ >>> > [2] >>> > >>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >>> > >>> > # Towards a JSON API for the JDK >>> > >>> > One of the most common requests for the JDK is an API for >>> parsing and generating >>> > JSON. While JSON originated as a text-based serialization >>> format for JSON >>> > objects ("JSON" stands for "JavaScript Object Notation"), >>> because of its simple >>> > and flexible syntax, it eventually found use outside the >>> JavaScript ecosystem as >>> > a general data interchange format, such as framework >>> configuration files and web >>> > service requests/response formats. >>> > >>> > While the JDK cannot, and should not, provide libraries for >>> every conceivable >>> > file format or protocol, the JDK philosophy is one of >>> "batteries included", >>> > which is to say we should be able to write basic programs that >>> use common >>> > protocols such as HTTP, without having to appeal to third >>> party libraries. >>> > The Java ecosystem already has plenty of JSON libraries, so >>> inclusion in >>> > the JDK is largely meant to be a convenience, rather than >>> needing to be the "one >>> > true" JSON library to meet the needs of all users. Users with >>> specific needs >>> > are always free to select one of the existing third-party >>> libraries. >>> > >>> > ## Goals and requirements >>> > >>> > Our primary goal is that the library be simple to use for >>> parsing, traversing, >>> > and generating conformant JSON documents. Advanced features, >>> such as data >>> > binding or path-based traversal should be possible to >>> implement as layered >>> > features, but for simplicity are not included in the core API. >>> We adopt a goal >>> > that the performance should be "good enough", but where >>> performance >>> > considerations conflict with simplicity and usability, we will >>> choose in favor >>> > of the latter. >>> > >>> > ## API design approach >>> > >>> > The description of JSON at `https:://json.org >>> ` describes a JSON document using >>> > the familiar "railroad diagram": >>> > ![image](https://www.json.org/img/value.png) >>> > >>> > This diagram describes an algebraic data type (a sum of >>> products), which we >>> > model directly with a set of Java interfaces: >>> > >>> > ``` >>> > interface JsonValue { } >>> > interface JsonArray extends JsonValue { List >>> values(); } >>> > interface JsonObject extends JsonValue { Map>> JsonValue> members(); } >>> > interface JsonNumber extends JsonValue { Number toNumber(); } >>> > interface JsonString extends JsonValue { String value(); } >>> > interface JsonBoolean extends JsonValue? { boolean value(); } >>> > interface JsonNull extends JsonValue { } >>> > ``` >>> > >>> > These interfaces have (hidden) companion implementation >>> classes that admit >>> > greater flexibility of implementation than modeling them >>> directly with records >>> > would permit. >>> > Further, these interfaces are unsealed. We compromise on the >>> sealed sum of >>> > products to enable >>> > alternative implementations, for example to support >>> alternative formats that >>> > encode the same information in a JSON document but in a more >>> efficient form than >>> > text. >>> > >>> > The API has static methods for parsing strings into a >>> `JsonValue`, conversion to >>> > and from purely untyped representations (lists and maps), and >>> factory methods >>> > for building JSON documents. We apply composition >>> consistently, e.g, a >>> > JsonString has a string, a JsonObject has a map of string to >>> JsonValue, as >>> > opposed to extension for structural JSON values. >>> > >>> > It turns out that this simple API is almost all we need for >>> traversal. It gives >>> > us an immutable representation of a document, and we can use >>> pattern matching to >>> > answer the myriad questions that will come up (Does this >>> object have key X? Does >>> > it map to a number? Is that number representable as an >>> integer?) when going >>> > from an untyped format like JSON to a more strongly typed >>> domain model. >>> > Given a simple document like: >>> > >>> > ``` >>> >? ? { >>> >? ? ? ? "name": "John?, >>> >? ? ? ? "age": 30 >>> >? ? } >>> > ``` >>> > >>> > we can parse and traverse the document as follows: >>> > >>> > ``` >>> > JsonValue doc = Json.parse(inputString); >>> > if (doc instanceof JsonObject o >>> >? ? && o.members().get("name") instanceof JsonString s >>> >? ? && s.value() instanceof String name >>> >? ? && o.members().get("age") instanceof JsonNumber n >>> >? ? && n.toNumber() instanceof Long l && l instanceof int age) { >>> >? ? ? ? ? ? // use "name" and "age" >>> >? ? ? ? } >>> > ``` >>> > >>> > Later, when the language acquires the ability to expose >>> deconstruction patterns >>> > for arbitrary interfaces (similar to today's record patterns, see >>> > >>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), >>> > this will be simplifiable to: >>> > >>> > ``` >>> > JsonValue doc = Json.parse(inputString); >>> > if (doc instanceof JsonObject(var members) >>> >? ? && members.get("name") instanceof JsonString(String name) >>> >? ? && members.get("age") instanceof JsonNumber(int age)) { >>> >? ? ? ? ? ? // use "name" and "age" >>> >? ? ? ? } >>> > ``` >>> > >>> > So, overtime, as more pattern matching features are introduced >>> we anticipate >>> > improved use of the API. This is a primary reason why the API >>> is so minimal. >>> > Convenience methods we add today, such as a method that >>> accesses a JSON >>> > object component as say a JSON string or throws an exception, >>> will become >>> > redundant in the future. >>> > >>> > ## JSON numbers >>> > >>> > The specification of JSON number makes no explicit distinction >>> between integral >>> > and decimal numbers, nor specifies limits on the size of those >>> numbers. >>> > This is a common source of interoperability issues when >>> consuming JSON >>> > documents. Generally users cannot always but often do assume >>> JSON numbers are >>> > parsable, without loss of precision, to IEEE double-precision >>> floating point >>> > numbers or 32-bit signed integers. >>> > >>> > In this respect the API provides three means to operate on the >>> JSON number, >>> > giving the user full control: >>> > >>> > 1. Underlying string representation can be obtained, if >>> preserving syntactic >>> >? ?details such as leading or trailing zeros is important. >>> > 2. The string representation can be parsed to an instance of >>> `BigDecimal`, using >>> >? ?`toBigDecimal` if preserving decimal numbers is important. >>> > 3. The string representation can be parsed into an instance of >>> `Long`, `Double`, >>> >? ?`BigInteger`, or `BigDecimal`, using `toNumber`. The result >>> of this method >>> >? ?depends on how the representation can be parsed, possibly >>> losing precision, >>> >? ?choosing a suitably convenient numeric type that can then be >>> pattern >>> >? ?matched on. >>> > >>> > Primitive pattern matching will help as will further pattern >>> matching features >>> > enabling the user to partially match. >>> > >>> > ## Prototype implementation >>> > >>> > The prototype implementation is currently located into the JDK >>> sandbox >>> > repository >>> > under the `json` branch, see >>> > here >>> > >>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >>> > The prototype API javadoc generated from the repository is >>> also available at >>> > >>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >>> > >>> > ### Testing and conformance >>> > >>> > The prototype implementation passes all conformance test cases >>> but two, >>> > available >>> > on https://github.com/nst/JSONTestSuite. The two exceptions >>> are the ones which >>> > the >>> > prototype specifically prohibits, i.e, duplicated names in >>> JSON objects >>> > >>> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). >>> > >>> > ### Performance >>> > >>> > Our main focus so far has been on the API design and a functional >>> > implementation. >>> > Hence, there has been less focus on performance even though we >>> know there are a >>> > number of performance enhancements we can make eventually. >>> > We are reasonably happy with the current performance. The >>> > implementation performs well when compared to other JSON >>> implementations >>> > parsing from string instances and traversing documents. >>> > >>> > An example of where we may choose simplicity and usability >>> over performance >>> > is the rejection of JSON documents containing objects that in >>> turn contain >>> > members >>> > with duplicate names. That may increase the cost of parsing, >>> but simplifies the >>> > user >>> > experience for the majority of cases since if we reasonably >>> assume JsonObjects >>> > are >>> > map-like, what should the user do with such members, pick one >>> the last one? >>> > merge >>> > the values? or reject? >>> > >>> > ## A JSON JEP? >>> > >>> > We plan to draft JEP when we are ready. Attentive readers will >>> observe that >>> > a JEP already exists, JEP 198: Light-Weight JSON API >>> > (https://openjdk.org/jeps/198). We will >>> > either update this JEP, or withdraw it and draft a new one. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Fri May 16 14:32:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 14:32:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Changes based on review feedback. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230: > 228: // It requires 'entryLookup' and 'readOnly' to have safe defaults (which > 229: // is why they are the only non-final fields), and it requires that the > 230: // inode map has been initialized. It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults. Perhaps something like: > determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093167748 From forax at univ-mlv.fr Fri May 16 14:35:09 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 16 May 2025 16:35:09 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "Remi Forax" , "Paul Sandoz" > Cc: "core-libs-dev" > Sent: Friday, May 16, 2025 2:53:18 PM > Subject: Re: Towards a JSON API for the JDK > On 5/15/2025 5:27 PM, Remi Forax wrote: >> It's not clear to me why JsonArray (for example) has to be an interface instead >> of a record ? > > Oh, you know the answer to this.? A record limits us to a single > implementation with a rigid representation.? Behind an interface, we can > hide lazy parsing and inflation, wrapping other representations to > reduce copies, etc. First, let me refine the question. There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number. For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces. So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing. But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later. Now, for me, this library is more about being simple and safe than fast. If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces. regards, R?mi From jpai at openjdk.org Fri May 16 14:39:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 14:39:54 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Changes based on review feedback. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241: > 239: this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); > 240: if (readOnly && accessMode == AccessMode.READ_WRITE) { > 241: String reason = Files.isWritable(zfpath) Nit - this additional call to Files.isWritable(...) can be avoided if we store the value of the previous call (a couple of lines above). I realize that the previous `Files.isWritable` is stashed at the end of the `||` conditionals to prevent it from being invoked in certain situations. So maybe a better change would be something like: String reason = multiReleaseVersion.isPresent() ? "A multi-release JAR file opened with a specified version is not writable" : "The underlying ZIP file is not writable"; which would then avoid any additional calls to `Files.isWritable`. But I think this point may not be relevant for the reason I note below as a separate comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093180117 From jpai at openjdk.org Fri May 16 14:46:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 14:46:53 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Changes based on review feedback. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 245: > 243: : "The underlying ZIP file is not writable"; > 244: throw new IOException( > 245: "A writable ZIP file system could not be opened for: " + zfpath + "\n" + reason); The JDK coding guidelines recommend excluding file paths from exception messages. So in this case the `zfpath` should be left out from the exception message. Additionally, I haven't seen us using newline characters in exception messages that we construct in the JDK code. So I think we should leave that out too. Given this, I think it might be simpler to just change this `if` block to something like: if (...) { String reason = multiReleaseVersion.isPresent() ? "the multi-release JAR file is not writable" : "the ZIP file is not writable"; throw new IOException(reason); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093192898 From lancea at openjdk.org Fri May 16 15:44:55 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 16 May 2025 15:44:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 09:49:12 GMT, David Beaumont wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221: > >> 219: } >> 220: // sm and existence check >> 221: zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ); > > Type name clash with existing AccessMode class. Since new enum is private, happy to rename. So perhaps change the name of the newly added enum > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259: > >> 257: >> 258: // Pass "this" as a parameter after everything else is set up. >> 259: this.rootdir = new ZipPath(this, new byte[]{'/'}); > > This could probably be set above release version etc. but it's a choice of either: > 1. waiting until everything is set up before passing "this" > 2. letting an incomplete "this" instance get passed to another class (possible escape risk?) > > Though in this case the "incompleteness" is limited to it not being set up for multi-jar reading yet, which absolutely shouldn't affect the root path. It feels safer to me to leave it to the end, or perhaps we should dig in to ZipPath, figure out what it really wants here, and just call a different constructor? I think it was fine where it was originally given how rootdir is used ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093248468 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093276490 From lancea at openjdk.org Fri May 16 15:44:56 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 16 May 2025 15:44:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 14:30:38 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230: > >> 228: // It requires 'entryLookup' and 'readOnly' to have safe defaults (which >> 229: // is why they are the only non-final fields), and it requires that the >> 230: // inode map has been initialized. > > It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults. > > Perhaps something like: > >> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed. Not sure I see a need for the last sentence regarding the inode map having to be initialized in addition to Jai's comments above ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093251313 From lancea at openjdk.org Fri May 16 15:44:57 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 16 May 2025 15:44:57 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 05:34:09 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/module-info.java line 299: > >> 297: *

    • >> 298: * Any other values will cause an {@code IllegalArgumentException} >> 299: * to be thrown. > > The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too. The IAE message would be best to standardize around the wording that the compressMethod property uses (same for releaseVersion while we are at it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093281557 From duke at openjdk.org Fri May 16 16:02:56 2025 From: duke at openjdk.org (Markus KARG) Date: Fri, 16 May 2025 16:02:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19] In-Reply-To: <6R_dYDxxb9DRXAYBzENkNbRAn4rzQvNJmhd5KQPRj_g=.306a738b-b82b-4da4-a762-b7bd0cbe2f47@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com> <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com> <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com> <6R_dYDxxb9DRXAYBzENkNbRAn4rzQvNJmhd5KQPRj_g=.306a738b-b82b-4da4-a762-b7bd0cbe2f47@github.com> Message-ID: On Thu, 15 May 2025 22:07:05 GMT, Brian Burkhalter wrote: >> It is **impossible** to "invest some lines" to solve this in JAX-RS, and JAX-RS as a standard technology on tens of thousands of servers. Enforcing `String` prevents these useful optimizations, but brings *no actual benefit*, as *only few* callers actually care for *constant* objects, but would be satisfied with `CharSequence`'s lack of mutation methods. > >> Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object. > > What relation does such a "heap object" have to character streams? With "heap object" I meant something that is kept on the Java heap, like a `CharSequence` or `String`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093313964 From swen at openjdk.org Fri May 16 16:04:32 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 16 May 2025 16:04:32 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v3] In-Reply-To: References: Message-ID: <1sSVnfBoVGJLOlNuWRG0xGA0MQtRvG6y4b2u7A3XYps=.10d86316-f649-406b-974a-e65a04534ea5@github.com> > Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. Shaojin Wen has updated the pull request incrementally with seven additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Volkan Yaz?c? - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Volkan Yaz?c? - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Volkan Yaz?c? - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Volkan Yaz?c? - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Volkan Yaz?c? - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Volkan Yaz?c? - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Volkan Yaz?c? ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25246/files - new: https://git.openjdk.org/jdk/pull/25246/files/ddb44aa8..bcb9af27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=01-02 Stats: 13 lines in 1 file changed: 0 ins; 8 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246 PR: https://git.openjdk.org/jdk/pull/25246 From swen at openjdk.org Fri May 16 16:10:29 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 16 May 2025 16:10:29 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v4] In-Reply-To: References: Message-ID: > Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: warning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25246/files - new: https://git.openjdk.org/jdk/pull/25246/files/bcb9af27..da865e42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246 PR: https://git.openjdk.org/jdk/pull/25246 From bpb at openjdk.org Fri May 16 16:13:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 16:13:34 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v5] In-Reply-To: References: Message-ID: > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355954: Split deleteReadOnlyRegularFile into Unix and Windows versions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24977/files - new: https://git.openjdk.org/jdk/pull/24977/files/352c54dd..fa2273ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=03-04 Stats: 32 lines in 1 file changed: 14 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977 PR: https://git.openjdk.org/jdk/pull/24977 From joe.darcy at oracle.com Fri May 16 16:20:23 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 16 May 2025 09:20:23 -0700 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: References: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com> Message-ID: I concur that this work is better down early in JDK 26. Thanks, -Joe On 5/16/2025 12:26 AM, Thomas St?fe wrote: > Okay, moved the release version to 26. > > Could one of you (you or @Roger Riggs > ) review the CSR if you have the cycles to spare? > > https://bugs.openjdk.org/browse/JDK-8357090 > > Thanks! > > On Fri, May 16, 2025 at 7:56?AM Alan Bateman > wrote: > > On 16/05/2025 05:10, Thomas St?fe wrote: >> >> >> >> Thank you, Alan. I will prepare a patch and a CSR. >> > Okay, and maybe something for early in JDK 26 to avoid touching > this area close to the fork for JDK 25 RDP1. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Fri May 16 16:26:50 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 16:26:50 GMT Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in exception In-Reply-To: References: Message-ID: On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller wrote: > When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones. Looks correct. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25250#pullrequestreview-2847102959 From naoto.sato at oracle.com Fri May 16 16:35:50 2025 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 16 May 2025 09:35:50 -0700 Subject: Towards a JSON API for the JDK In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hi R?mi, On 5/15/25 2:27 PM, Remi Forax wrote: > Hi Paul, > yes, not having a simple JSON API in Java is an issue for beginners. > > It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? > > I understand why Json.parse() only works on String and char[] but the API make it too easy to have many performance issues. > I think you need versions using a Reader and a Path. > Bonus point, if there is a method walk() that also returns a JsonValue but the List/Map inside JsonArray/JsonObject are populated lazily. > > Minor point: Json.toDisplayString() should takes a second parameters indicating the number of spaces used for the indentation (like JSON.stringify in JS). That would be better. Will implement it soon. Naoto > > regards, > R?mi > > ----- Original Message ----- >> From: "Paul Sandoz" >> To: "core-libs-dev" >> Sent: Thursday, May 15, 2025 10:30:42 PM >> Subject: Towards a JSON API for the JDK > >> Hi, >> >> We would like to share with you our thoughts and plans towards a JSON API for >> the JDK. >> Please see the document below. >> >> - >> >> We have had the pleasure of using a clone of this API in some experiments we are >> conducting with >> ONNX and code reflection [1]. Using the API we were able to quickly write code >> to ingest and convert >> a JSON document representing ONNX operation schema into instances of records >> modeling the schema >> (see here [2]). >> >> The overall out-of-box experience with such a minimal "batteries included? API >> has so far been positive. >> >> Thanks, >> Paul. >> >> [1] https://openjdk.org/projects/babylon/ >> [2] >> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >> >> # Towards a JSON API for the JDK >> >> One of the most common requests for the JDK is an API for parsing and generating >> JSON. While JSON originated as a text-based serialization format for JSON >> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple >> and flexible syntax, it eventually found use outside the JavaScript ecosystem as >> a general data interchange format, such as framework configuration files and web >> service requests/response formats. >> >> While the JDK cannot, and should not, provide libraries for every conceivable >> file format or protocol, the JDK philosophy is one of "batteries included", >> which is to say we should be able to write basic programs that use common >> protocols such as HTTP, without having to appeal to third party libraries. >> The Java ecosystem already has plenty of JSON libraries, so inclusion in >> the JDK is largely meant to be a convenience, rather than needing to be the "one >> true" JSON library to meet the needs of all users. Users with specific needs >> are always free to select one of the existing third-party libraries. >> >> ## Goals and requirements >> >> Our primary goal is that the library be simple to use for parsing, traversing, >> and generating conformant JSON documents. Advanced features, such as data >> binding or path-based traversal should be possible to implement as layered >> features, but for simplicity are not included in the core API. We adopt a goal >> that the performance should be "good enough", but where performance >> considerations conflict with simplicity and usability, we will choose in favor >> of the latter. >> >> ## API design approach >> >> The description of JSON at `https:://json.org` describes a JSON document using >> the familiar "railroad diagram": >> ![image](https://www.json.org/img/value.png) >> >> This diagram describes an algebraic data type (a sum of products), which we >> model directly with a set of Java interfaces: >> >> ``` >> interface JsonValue { } >> interface JsonArray extends JsonValue { List values(); } >> interface JsonObject extends JsonValue { Map members(); } >> interface JsonNumber extends JsonValue { Number toNumber(); } >> interface JsonString extends JsonValue { String value(); } >> interface JsonBoolean extends JsonValue { boolean value(); } >> interface JsonNull extends JsonValue { } >> ``` >> >> These interfaces have (hidden) companion implementation classes that admit >> greater flexibility of implementation than modeling them directly with records >> would permit. >> Further, these interfaces are unsealed. We compromise on the sealed sum of >> products to enable >> alternative implementations, for example to support alternative formats that >> encode the same information in a JSON document but in a more efficient form than >> text. >> >> The API has static methods for parsing strings into a `JsonValue`, conversion to >> and from purely untyped representations (lists and maps), and factory methods >> for building JSON documents. We apply composition consistently, e.g, a >> JsonString has a string, a JsonObject has a map of string to JsonValue, as >> opposed to extension for structural JSON values. >> >> It turns out that this simple API is almost all we need for traversal. It gives >> us an immutable representation of a document, and we can use pattern matching to >> answer the myriad questions that will come up (Does this object have key X? Does >> it map to a number? Is that number representable as an integer?) when going >> from an untyped format like JSON to a more strongly typed domain model. >> Given a simple document like: >> >> ``` >> { >> "name": "John?, >> "age": 30 >> } >> ``` >> >> we can parse and traverse the document as follows: >> >> ``` >> JsonValue doc = Json.parse(inputString); >> if (doc instanceof JsonObject o >> && o.members().get("name") instanceof JsonString s >> && s.value() instanceof String name >> && o.members().get("age") instanceof JsonNumber n >> && n.toNumber() instanceof Long l && l instanceof int age) { >> // use "name" and "age" >> } >> ``` >> >> Later, when the language acquires the ability to expose deconstruction patterns >> for arbitrary interfaces (similar to today's record patterns, see >> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), >> this will be simplifiable to: >> >> ``` >> JsonValue doc = Json.parse(inputString); >> if (doc instanceof JsonObject(var members) >> && members.get("name") instanceof JsonString(String name) >> && members.get("age") instanceof JsonNumber(int age)) { >> // use "name" and "age" >> } >> ``` >> >> So, overtime, as more pattern matching features are introduced we anticipate >> improved use of the API. This is a primary reason why the API is so minimal. >> Convenience methods we add today, such as a method that accesses a JSON >> object component as say a JSON string or throws an exception, will become >> redundant in the future. >> >> ## JSON numbers >> >> The specification of JSON number makes no explicit distinction between integral >> and decimal numbers, nor specifies limits on the size of those numbers. >> This is a common source of interoperability issues when consuming JSON >> documents. Generally users cannot always but often do assume JSON numbers are >> parsable, without loss of precision, to IEEE double-precision floating point >> numbers or 32-bit signed integers. >> >> In this respect the API provides three means to operate on the JSON number, >> giving the user full control: >> >> 1. Underlying string representation can be obtained, if preserving syntactic >> details such as leading or trailing zeros is important. >> 2. The string representation can be parsed to an instance of `BigDecimal`, using >> `toBigDecimal` if preserving decimal numbers is important. >> 3. The string representation can be parsed into an instance of `Long`, `Double`, >> `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method >> depends on how the representation can be parsed, possibly losing precision, >> choosing a suitably convenient numeric type that can then be pattern >> matched on. >> >> Primitive pattern matching will help as will further pattern matching features >> enabling the user to partially match. >> >> ## Prototype implementation >> >> The prototype implementation is currently located into the JDK sandbox >> repository >> under the `json` branch, see >> here >> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >> The prototype API javadoc generated from the repository is also available at >> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >> >> ### Testing and conformance >> >> The prototype implementation passes all conformance test cases but two, >> available >> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which >> the >> prototype specifically prohibits, i.e, duplicated names in JSON objects >> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). >> >> ### Performance >> >> Our main focus so far has been on the API design and a functional >> implementation. >> Hence, there has been less focus on performance even though we know there are a >> number of performance enhancements we can make eventually. >> We are reasonably happy with the current performance. The >> implementation performs well when compared to other JSON implementations >> parsing from string instances and traversing documents. >> >> An example of where we may choose simplicity and usability over performance >> is the rejection of JSON documents containing objects that in turn contain >> members >> with duplicate names. That may increase the cost of parsing, but simplifies the >> user >> experience for the majority of cases since if we reasonably assume JsonObjects >> are >> map-like, what should the user do with such members, pick one the last one? >> merge >> the values? or reject? >> >> ## A JSON JEP? >> >> We plan to draft JEP when we are ready. Attentive readers will observe that >> a JEP already exists, JEP 198: Light-Weight JSON API >> (https://openjdk.org/jeps/198). We will >> either update this JEP, or withdraw it and draft a new one. From joehw at openjdk.org Fri May 16 16:42:53 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 16 May 2025 16:42:53 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2] In-Reply-To: References: Message-ID: <3tVtRDVNeYwN4Hf6OB-3gYM44GrqPAxWfWfptNQolnM=.dcf79f5b-a7c9-43bd-8af4-c542caed0a33@github.com> On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato wrote: >> Removing now-defunct COMPAT locale provider tests. > > Naoto Sato has updated the pull request incrementally with three additional commits since the last revision: > > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2847142525 From liach at openjdk.org Fri May 16 16:44:53 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 16:44:53 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v4] In-Reply-To: References: Message-ID: <0xb967N0tNnJUqohfrI-zu-jmZsdxfoUIahEwTOBUgo=.0f88e5e6-c938-4086-a28a-5da6f7d8d148@github.com> On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > warning This version looks good to me. Please wait for a second confirmation. (Allowing authors like @vy to review too) ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2847147545 From markus at headcrashing.eu Fri May 16 16:52:36 2025 From: markus at headcrashing.eu (Markus KARG) Date: Fri, 16 May 2025 18:52:36 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu> As the API intentionally uses interfaces to open the ability to optimize the implementation, it would be also just straightforward to not limit the text source to the explicit class String. When instead allowing the general interface CharSequence, *any* kind of text source can be parsed, for example, an off-heap located direct CharBuffer, without the need to explicitly copy its content into a temporary in-memory String representation, upfront to parsing. More flexible, more speed, less memory, less GC. :-) Am 15.05.2025 um 23:27 schrieb Remi Forax: > Hi Paul, > yes, not having a simple JSON API in Java is an issue for beginners. > > It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? > > I understand why Json.parse() only works on String and char[] but the API make it too easy to have many performance issues. > I think you need versions using a Reader and a Path. > Bonus point, if there is a method walk() that also returns a JsonValue but the List/Map inside JsonArray/JsonObject are populated lazily. > > Minor point: Json.toDisplayString() should takes a second parameters indicating the number of spaces used for the indentation (like JSON.stringify in JS). > > regards, > R?mi > > ----- Original Message ----- >> From: "Paul Sandoz" >> To: "core-libs-dev" >> Sent: Thursday, May 15, 2025 10:30:42 PM >> Subject: Towards a JSON API for the JDK >> Hi, >> >> We would like to share with you our thoughts and plans towards a JSON API for >> the JDK. >> Please see the document below. >> >> - >> >> We have had the pleasure of using a clone of this API in some experiments we are >> conducting with >> ONNX and code reflection [1]. Using the API we were able to quickly write code >> to ingest and convert >> a JSON document representing ONNX operation schema into instances of records >> modeling the schema >> (see here [2]). >> >> The overall out-of-box experience with such a minimal "batteries included? API >> has so far been positive. >> >> Thanks, >> Paul. >> >> [1] https://openjdk.org/projects/babylon/ >> [2] >> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >> >> # Towards a JSON API for the JDK >> >> One of the most common requests for the JDK is an API for parsing and generating >> JSON. While JSON originated as a text-based serialization format for JSON >> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple >> and flexible syntax, it eventually found use outside the JavaScript ecosystem as >> a general data interchange format, such as framework configuration files and web >> service requests/response formats. >> >> While the JDK cannot, and should not, provide libraries for every conceivable >> file format or protocol, the JDK philosophy is one of "batteries included", >> which is to say we should be able to write basic programs that use common >> protocols such as HTTP, without having to appeal to third party libraries. >> The Java ecosystem already has plenty of JSON libraries, so inclusion in >> the JDK is largely meant to be a convenience, rather than needing to be the "one >> true" JSON library to meet the needs of all users. Users with specific needs >> are always free to select one of the existing third-party libraries. >> >> ## Goals and requirements >> >> Our primary goal is that the library be simple to use for parsing, traversing, >> and generating conformant JSON documents. Advanced features, such as data >> binding or path-based traversal should be possible to implement as layered >> features, but for simplicity are not included in the core API. We adopt a goal >> that the performance should be "good enough", but where performance >> considerations conflict with simplicity and usability, we will choose in favor >> of the latter. >> >> ## API design approach >> >> The description of JSON at `https:://json.org` describes a JSON document using >> the familiar "railroad diagram": >> ![image](https://www.json.org/img/value.png) >> >> This diagram describes an algebraic data type (a sum of products), which we >> model directly with a set of Java interfaces: >> >> ``` >> interface JsonValue { } >> interface JsonArray extends JsonValue { List values(); } >> interface JsonObject extends JsonValue { Map members(); } >> interface JsonNumber extends JsonValue { Number toNumber(); } >> interface JsonString extends JsonValue { String value(); } >> interface JsonBoolean extends JsonValue { boolean value(); } >> interface JsonNull extends JsonValue { } >> ``` >> >> These interfaces have (hidden) companion implementation classes that admit >> greater flexibility of implementation than modeling them directly with records >> would permit. >> Further, these interfaces are unsealed. We compromise on the sealed sum of >> products to enable >> alternative implementations, for example to support alternative formats that >> encode the same information in a JSON document but in a more efficient form than >> text. >> >> The API has static methods for parsing strings into a `JsonValue`, conversion to >> and from purely untyped representations (lists and maps), and factory methods >> for building JSON documents. We apply composition consistently, e.g, a >> JsonString has a string, a JsonObject has a map of string to JsonValue, as >> opposed to extension for structural JSON values. >> >> It turns out that this simple API is almost all we need for traversal. It gives >> us an immutable representation of a document, and we can use pattern matching to >> answer the myriad questions that will come up (Does this object have key X? Does >> it map to a number? Is that number representable as an integer?) when going >> from an untyped format like JSON to a more strongly typed domain model. >> Given a simple document like: >> >> ``` >> { >> "name": "John?, >> "age": 30 >> } >> ``` >> >> we can parse and traverse the document as follows: >> >> ``` >> JsonValue doc = Json.parse(inputString); >> if (doc instanceof JsonObject o >> && o.members().get("name") instanceof JsonString s >> && s.value() instanceof String name >> && o.members().get("age") instanceof JsonNumber n >> && n.toNumber() instanceof Long l && l instanceof int age) { >> // use "name" and "age" >> } >> ``` >> >> Later, when the language acquires the ability to expose deconstruction patterns >> for arbitrary interfaces (similar to today's record patterns, see >> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), >> this will be simplifiable to: >> >> ``` >> JsonValue doc = Json.parse(inputString); >> if (doc instanceof JsonObject(var members) >> && members.get("name") instanceof JsonString(String name) >> && members.get("age") instanceof JsonNumber(int age)) { >> // use "name" and "age" >> } >> ``` >> >> So, overtime, as more pattern matching features are introduced we anticipate >> improved use of the API. This is a primary reason why the API is so minimal. >> Convenience methods we add today, such as a method that accesses a JSON >> object component as say a JSON string or throws an exception, will become >> redundant in the future. >> >> ## JSON numbers >> >> The specification of JSON number makes no explicit distinction between integral >> and decimal numbers, nor specifies limits on the size of those numbers. >> This is a common source of interoperability issues when consuming JSON >> documents. Generally users cannot always but often do assume JSON numbers are >> parsable, without loss of precision, to IEEE double-precision floating point >> numbers or 32-bit signed integers. >> >> In this respect the API provides three means to operate on the JSON number, >> giving the user full control: >> >> 1. Underlying string representation can be obtained, if preserving syntactic >> details such as leading or trailing zeros is important. >> 2. The string representation can be parsed to an instance of `BigDecimal`, using >> `toBigDecimal` if preserving decimal numbers is important. >> 3. The string representation can be parsed into an instance of `Long`, `Double`, >> `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method >> depends on how the representation can be parsed, possibly losing precision, >> choosing a suitably convenient numeric type that can then be pattern >> matched on. >> >> Primitive pattern matching will help as will further pattern matching features >> enabling the user to partially match. >> >> ## Prototype implementation >> >> The prototype implementation is currently located into the JDK sandbox >> repository >> under the `json` branch, see >> here >> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >> The prototype API javadoc generated from the repository is also available at >> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >> >> ### Testing and conformance >> >> The prototype implementation passes all conformance test cases but two, >> available >> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which >> the >> prototype specifically prohibits, i.e, duplicated names in JSON objects >> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). >> >> ### Performance >> >> Our main focus so far has been on the API design and a functional >> implementation. >> Hence, there has been less focus on performance even though we know there are a >> number of performance enhancements we can make eventually. >> We are reasonably happy with the current performance. The >> implementation performs well when compared to other JSON implementations >> parsing from string instances and traversing documents. >> >> An example of where we may choose simplicity and usability over performance >> is the rejection of JSON documents containing objects that in turn contain >> members >> with duplicate names. That may increase the cost of parsing, but simplifies the >> user >> experience for the majority of cases since if we reasonably assume JsonObjects >> are >> map-like, what should the user do with such members, pick one the last one? >> merge >> the values? or reject? >> >> ## A JSON JEP? >> >> We plan to draft JEP when we are ready. Attentive readers will observe that >> a JEP already exists, JEP 198: Light-Weight JSON API >> (https://openjdk.org/jeps/198). We will >> either update this JEP, or withdraw it and draft a new one. From thomas.stuefe at gmail.com Fri May 16 16:59:47 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 16 May 2025 18:59:47 +0200 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: References: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com> Message-ID: I am fine with waiting past 25, though the continued existence of this mode makes me apprehensive. Back at SAP I have seen real customer issues from these kind of problems, and we only catched those out of accident. A separate deprecation for JDK 25 may be a good first step (a warning, but continued acceptance, of the VFORK mode) On Fri, May 16, 2025 at 6:20?PM Joseph D. Darcy wrote: > I concur that this work is better down early in JDK 26. > > Thanks, > > -Joe > > On 5/16/2025 12:26 AM, Thomas St?fe wrote: > > Okay, moved the release version to 26. > > Could one of you (you or @Roger Riggs ) review > the CSR if you have the cycles to spare? > > https://bugs.openjdk.org/browse/JDK-8357090 > > Thanks! > > On Fri, May 16, 2025 at 7:56?AM Alan Bateman > wrote: > >> On 16/05/2025 05:10, Thomas St?fe wrote: >> >> >> >>> >> Thank you, Alan. I will prepare a patch and a CSR. >> >> Okay, and maybe something for early in JDK 26 to avoid touching this area >> close to the fork for JDK 25 RDP1. >> >> -Alan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Fri May 16 17:25:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 17:25:54 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v4] In-Reply-To: References: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> Message-ID: On Fri, 16 May 2025 06:28:14 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/DeleteReadOnly.java line 47: >> >>> 45: >>> 46: private static final File DIR = new File(".", "dir"); >>> 47: private static final File FILE = new File(DIR, "file"); >> >> If one of the tests fails then it will impact the test(s) that execute later. It might be better to just isolate them. deleteReadOnlyDirectory creates a directory that is used solely for that test, and deleteReadOnlyRegularFile creates a file that is used solely for that test. > > Agreed. That actually happened when negative testing against code without the fix. Made directory and file creation local to each test in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427). >> test/jdk/java/io/File/DeleteReadOnly.java line 62: >> >>> 60: >>> 61: boolean deleted = FILE.delete(); >>> 62: boolean shouldBeDeleted = !Platform.isWindows() || DELETE_READ_ONLY; >> >> The behavior and system property is Windows specific and might make things simpler to make it a Windows only test. > > I guess collapsing the tests made them more ambiguous. Will fix. Split the test method in half for Unix and Windows in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2093430454 PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2093429650 From raffaello.giulietti at oracle.com Fri May 16 17:26:04 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Fri, 16 May 2025 19:26:04 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu> Message-ID: <0e959a40-9471-477a-9635-19324d14a0fa@oracle.com> Since the parser is specified to be lazy, the backing store needs to be immutable. On 2025-05-16 18:52, Markus KARG wrote: > When instead allowing the > general interface CharSequence, *any* kind of text source can be parsed, > for example, an off-heap located direct CharBuffer, without the need to > explicitly copy its content into a temporary in-memory String > representation, upfront to parsing. More flexible, more speed, less > memory, less GC. :-) > From iris at openjdk.org Fri May 16 17:28:51 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 16 May 2025 17:28:51 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2] In-Reply-To: References: Message-ID: <6MMtxe9V1vRVN-dAVHwMveNro15HG5zvy7cFyYI4yJM=.68ed2245-db5f-4ddf-b8eb-d26840e2def1@github.com> On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato wrote: >> Removing now-defunct COMPAT locale provider tests. > > Naoto Sato has updated the pull request incrementally with three additional commits since the last revision: > > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2847242934 From bpb at openjdk.org Fri May 16 17:42:09 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 17:42:09 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v6] In-Reply-To: References: Message-ID: <7yNAdBKQFZ1NMDokRoeb3Iw_0bWvV-chWnYGufjI9R8=.e6192d07-2a05-4d0a-bcac-6017dcf8de30@github.com> > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355954: Delete deleteReadOnlyFile method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24977/files - new: https://git.openjdk.org/jdk/pull/24977/files/fa2273ed..9fa45418 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=04-05 Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977 PR: https://git.openjdk.org/jdk/pull/24977 From djgredler at gmail.com Fri May 16 17:42:41 2025 From: djgredler at gmail.com (Daniel Gredler) Date: Fri, 16 May 2025 19:42:41 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <0e959a40-9471-477a-9635-19324d14a0fa@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu> <0e959a40-9471-477a-9635-19324d14a0fa@oracle.com> Message-ID: Thanks for the sneak peek. I'd suggest adding a security section to the JEP, when the time comes. Most input to this JSON parsing API will probably be untrusted, and this is an area where "last mover advantage" can be helpful. As a user, the progression I've seen in other JSON parsers was a first wave of "serialization gadget" exploits providing RCE, followed by a wave of denial-of-service vulnerabilities. As a user, I'd love to know that these issues have all been considered up front: - Serialization gadgets (no object mapping, so not an issue?) - Sane limits (and maybe configurability) for: - Max object / array nesting depth - Max key (field name) length - Max value length (strings) - Max value length (numbers) - Max overall document size (maybe less of a problem if there are no Json.parse() methods for streams or files?) If you want to avoid the configurability aspect, it should be possible to find defaults which are relatively safe and do not impact 99% of users (e.g. who realistically uses JSON nested over 1k levels deep?). On Fri, May 16, 2025 at 7:26?PM Raffaello Giulietti < raffaello.giulietti at oracle.com> wrote: > Since the parser is specified to be lazy, the backing store needs to be > immutable. > > > On 2025-05-16 18:52, Markus KARG wrote: > > When instead allowing the > > general interface CharSequence, *any* kind of text source can be parsed, > > for example, an off-heap located direct CharBuffer, without the need to > > explicitly copy its content into a temporary in-memory String > > representation, upfront to parsing. More flexible, more speed, less > > memory, less GC. :-) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Fri May 16 17:46:09 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 May 2025 13:46:09 -0400 Subject: Towards a JSON API for the JDK In-Reply-To: <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> If you read the implementation, you'll see that significant laziness is indeed possible for JsonObject and JsonArray, even while doing eager validation.? (Of course, one can shift the balance to achieve various other tradeoffs.) On 5/16/2025 10:35 AM, forax at univ-mlv.fr wrote: > ----- Original Message ----- >> From: "Brian Goetz" >> To: "Remi Forax", "Paul Sandoz" >> Cc: "core-libs-dev" >> Sent: Friday, May 16, 2025 2:53:18 PM >> Subject: Re: Towards a JSON API for the JDK >> On 5/15/2025 5:27 PM, Remi Forax wrote: >>> It's not clear to me why JsonArray (for example) has to be an interface instead >>> of a record ? >> Oh, you know the answer to this.? A record limits us to a single >> implementation with a rigid representation.? Behind an interface, we can >> hide lazy parsing and inflation, wrapping other representations to >> reduce copies, etc. > First, let me refine the question. > There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number. > For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces. > > So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing. > > But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later. > > Now, for me, this library is more about being simple and safe than fast. > If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces. > > regards, > R?mi > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Fri May 16 18:05:56 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 May 2025 18:05:56 GMT Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato wrote: >> Removing now-defunct COMPAT locale provider tests. > > Naoto Sato has updated the pull request incrementally with three additional commits since the last revision: > > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu > - Update test/jdk/sun/text/resources/LocaleDataTest.java > > Co-authored-by: Justin Lu Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25257#issuecomment-2887364827 From naoto at openjdk.org Fri May 16 18:05:56 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 May 2025 18:05:56 GMT Subject: Integrated: 8357075: Remove leftover COMPAT locale data tests In-Reply-To: References: Message-ID: On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato wrote: > Removing now-defunct COMPAT locale provider tests. This pull request has now been integrated. Changeset: 3dd34517 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/3dd34517000e4ce1a21619922c62c025f98aad44 Stats: 8496 lines in 2 files changed: 0 ins; 8484 del; 12 mod 8357075: Remove leftover COMPAT locale data tests Reviewed-by: joehw, iris, jlu ------------- PR: https://git.openjdk.org/jdk/pull/25257 From rriggs at openjdk.org Fri May 16 18:16:57 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 May 2025 18:16:57 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354724: Replace getChars in previous commit with subSequence src/java.base/share/classes/java/io/Reader.java line 478: > 476: * > 477: *

      If an I/O error occurs reading from the stream, then it > 478: * may do so after some, but not all, characters have been read. Is this better? Suggestion: *

      If an I/O error occurs reading from the stream, then some characters, but not all, may have been read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093493065 From bpb at openjdk.org Fri May 16 18:23:59 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 18:23:59 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Fri, 16 May 2025 18:13:45 GMT, Roger Riggs wrote: > Is this better? I think it is clearer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093501372 From forax at univ-mlv.fr Fri May 16 18:37:52 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 16 May 2025 20:37:52 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <897655549.267921263.1747420672400.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "naoto sato" > To: "Remi Forax" , "Paul Sandoz" > Cc: "core-libs-dev" > Sent: Friday, May 16, 2025 6:35:50 PM > Subject: Re: Towards a JSON API for the JDK > Hi R?mi, > > On 5/15/25 2:27 PM, Remi Forax wrote: >> Hi Paul, >> yes, not having a simple JSON API in Java is an issue for beginners. >> >> It's not clear to me why JsonArray (for example) has to be an interface instead >> of a record ? >> >> I understand why Json.parse() only works on String and char[] but the API make >> it too easy to have many performance issues. >> I think you need versions using a Reader and a Path. >> Bonus point, if there is a method walk() that also returns a JsonValue but the >> List/Map inside JsonArray/JsonObject are populated lazily. >> >> Minor point: Json.toDisplayString() should takes a second parameters indicating >> the number of spaces used for the indentation (like JSON.stringify in JS). > > That would be better. Will implement it soon. Thank you ! > > Naoto R?mi > >> >> regards, >> R?mi >> >> ----- Original Message ----- >>> From: "Paul Sandoz" >>> To: "core-libs-dev" >>> Sent: Thursday, May 15, 2025 10:30:42 PM >>> Subject: Towards a JSON API for the JDK >> >>> Hi, >>> >>> We would like to share with you our thoughts and plans towards a JSON API for >>> the JDK. >>> Please see the document below. >>> >>> - >>> >>> We have had the pleasure of using a clone of this API in some experiments we are >>> conducting with >>> ONNX and code reflection [1]. Using the API we were able to quickly write code >>> to ingest and convert >>> a JSON document representing ONNX operation schema into instances of records >>> modeling the schema >>> (see here [2]). >>> >>> The overall out-of-box experience with such a minimal "batteries included? API >>> has so far been positive. >>> >>> Thanks, >>> Paul. >>> >>> [1] https://openjdk.org/projects/babylon/ >>> [2] >>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >>> >>> # Towards a JSON API for the JDK >>> >>> One of the most common requests for the JDK is an API for parsing and generating >>> JSON. While JSON originated as a text-based serialization format for JSON >>> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple >>> and flexible syntax, it eventually found use outside the JavaScript ecosystem as >>> a general data interchange format, such as framework configuration files and web >>> service requests/response formats. >>> >>> While the JDK cannot, and should not, provide libraries for every conceivable >>> file format or protocol, the JDK philosophy is one of "batteries included", >>> which is to say we should be able to write basic programs that use common >>> protocols such as HTTP, without having to appeal to third party libraries. >>> The Java ecosystem already has plenty of JSON libraries, so inclusion in >>> the JDK is largely meant to be a convenience, rather than needing to be the "one >>> true" JSON library to meet the needs of all users. Users with specific needs >>> are always free to select one of the existing third-party libraries. >>> >>> ## Goals and requirements >>> >>> Our primary goal is that the library be simple to use for parsing, traversing, >>> and generating conformant JSON documents. Advanced features, such as data >>> binding or path-based traversal should be possible to implement as layered >>> features, but for simplicity are not included in the core API. We adopt a goal >>> that the performance should be "good enough", but where performance >>> considerations conflict with simplicity and usability, we will choose in favor >>> of the latter. >>> >>> ## API design approach >>> >>> The description of JSON at `https:://json.org` describes a JSON document using >>> the familiar "railroad diagram": >>> ![image](https://www.json.org/img/value.png) >>> >>> This diagram describes an algebraic data type (a sum of products), which we >>> model directly with a set of Java interfaces: >>> >>> ``` >>> interface JsonValue { } >>> interface JsonArray extends JsonValue { List values(); } >>> interface JsonObject extends JsonValue { Map members(); } >>> interface JsonNumber extends JsonValue { Number toNumber(); } >>> interface JsonString extends JsonValue { String value(); } >>> interface JsonBoolean extends JsonValue { boolean value(); } >>> interface JsonNull extends JsonValue { } >>> ``` >>> >>> These interfaces have (hidden) companion implementation classes that admit >>> greater flexibility of implementation than modeling them directly with records >>> would permit. >>> Further, these interfaces are unsealed. We compromise on the sealed sum of >>> products to enable >>> alternative implementations, for example to support alternative formats that >>> encode the same information in a JSON document but in a more efficient form than >>> text. >>> >>> The API has static methods for parsing strings into a `JsonValue`, conversion to >>> and from purely untyped representations (lists and maps), and factory methods >>> for building JSON documents. We apply composition consistently, e.g, a >>> JsonString has a string, a JsonObject has a map of string to JsonValue, as >>> opposed to extension for structural JSON values. >>> >>> It turns out that this simple API is almost all we need for traversal. It gives >>> us an immutable representation of a document, and we can use pattern matching to >>> answer the myriad questions that will come up (Does this object have key X? Does >>> it map to a number? Is that number representable as an integer?) when going >>> from an untyped format like JSON to a more strongly typed domain model. >>> Given a simple document like: >>> >>> ``` >>> { >>> "name": "John?, >>> "age": 30 >>> } >>> ``` >>> >>> we can parse and traverse the document as follows: >>> >>> ``` >>> JsonValue doc = Json.parse(inputString); >>> if (doc instanceof JsonObject o >>> && o.members().get("name") instanceof JsonString s >>> && s.value() instanceof String name >>> && o.members().get("age") instanceof JsonNumber n >>> && n.toNumber() instanceof Long l && l instanceof int age) { >>> // use "name" and "age" >>> } >>> ``` >>> >>> Later, when the language acquires the ability to expose deconstruction patterns >>> for arbitrary interfaces (similar to today's record patterns, see >>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), >>> this will be simplifiable to: >>> >>> ``` >>> JsonValue doc = Json.parse(inputString); >>> if (doc instanceof JsonObject(var members) >>> && members.get("name") instanceof JsonString(String name) >>> && members.get("age") instanceof JsonNumber(int age)) { >>> // use "name" and "age" >>> } >>> ``` >>> >>> So, overtime, as more pattern matching features are introduced we anticipate >>> improved use of the API. This is a primary reason why the API is so minimal. >>> Convenience methods we add today, such as a method that accesses a JSON >>> object component as say a JSON string or throws an exception, will become >>> redundant in the future. >>> >>> ## JSON numbers >>> >>> The specification of JSON number makes no explicit distinction between integral >>> and decimal numbers, nor specifies limits on the size of those numbers. >>> This is a common source of interoperability issues when consuming JSON >>> documents. Generally users cannot always but often do assume JSON numbers are >>> parsable, without loss of precision, to IEEE double-precision floating point >>> numbers or 32-bit signed integers. >>> >>> In this respect the API provides three means to operate on the JSON number, >>> giving the user full control: >>> >>> 1. Underlying string representation can be obtained, if preserving syntactic >>> details such as leading or trailing zeros is important. >>> 2. The string representation can be parsed to an instance of `BigDecimal`, using >>> `toBigDecimal` if preserving decimal numbers is important. >>> 3. The string representation can be parsed into an instance of `Long`, `Double`, >>> `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method >>> depends on how the representation can be parsed, possibly losing precision, >>> choosing a suitably convenient numeric type that can then be pattern >>> matched on. >>> >>> Primitive pattern matching will help as will further pattern matching features >>> enabling the user to partially match. >>> >>> ## Prototype implementation >>> >>> The prototype implementation is currently located into the JDK sandbox >>> repository >>> under the `json` branch, see >>> here >>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >>> The prototype API javadoc generated from the repository is also available at >>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >>> >>> ### Testing and conformance >>> >>> The prototype implementation passes all conformance test cases but two, >>> available >>> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which >>> the >>> prototype specifically prohibits, i.e, duplicated names in JSON objects >>> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). >>> >>> ### Performance >>> >>> Our main focus so far has been on the API design and a functional >>> implementation. >>> Hence, there has been less focus on performance even though we know there are a >>> number of performance enhancements we can make eventually. >>> We are reasonably happy with the current performance. The >>> implementation performs well when compared to other JSON implementations >>> parsing from string instances and traversing documents. >>> >>> An example of where we may choose simplicity and usability over performance >>> is the rejection of JSON documents containing objects that in turn contain >>> members >>> with duplicate names. That may increase the cost of parsing, but simplifies the >>> user >>> experience for the majority of cases since if we reasonably assume JsonObjects >>> are >>> map-like, what should the user do with such members, pick one the last one? >>> merge >>> the values? or reject? >>> >>> ## A JSON JEP? >>> >>> We plan to draft JEP when we are ready. Attentive readers will observe that >>> a JEP already exists, JEP 198: Light-Weight JSON API >>> (https://openjdk.org/jeps/198). We will > >> either update this JEP, or withdraw it and draft a new one. From bpb at openjdk.org Fri May 16 18:40:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 18:40:38 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v23] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Improve verbiage about I/O errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/1afba6e6..a86610d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=21-22 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From bpb at openjdk.org Fri May 16 18:40:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 18:40:38 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <6ETSuONme1PBf9nNbzO2K54_AsmNTTKSmti_NJqq4Qg=.627bd84e-67f1-445b-b226-51f5d51ad369@github.com> On Fri, 16 May 2025 18:21:10 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 478: >> >>> 476: * >>> 477: *

      If an I/O error occurs reading from the stream, then it >>> 478: * may do so after some, but not all, characters have been read. >> >> Is this better? >> Suggestion: >> >> *

      If an I/O error occurs reading from the stream, then some characters, but not all, may have been read. > >> Is this better? > > I think it is clearer. Thanks. Applied in [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093518217 From bpb at openjdk.org Fri May 16 18:40:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 May 2025 18:40:38 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Fri, 16 May 2025 07:57:01 GMT, Jaikiran Pai wrote: > I read this sentence a couple of times [...] Please see [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045). > I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing. If you think it worthwhile, please file an issue to improve that verbiage as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093519255 From forax at univ-mlv.fr Fri May 16 18:42:47 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 16 May 2025 20:42:47 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> Message-ID: <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> > From: "Brian Goetz" > To: "Remi Forax" > Cc: "Paul Sandoz" , "core-libs-dev" > > Sent: Friday, May 16, 2025 7:46:09 PM > Subject: Re: Towards a JSON API for the JDK > If you read the implementation, you'll see that significant laziness is indeed > possible for JsonObject and JsonArray, even while doing eager validation. (Of > course, one can shift the balance to achieve various other tradeoffs.) Reading the implementation is on my TODO list :) R?mi > On 5/16/2025 10:35 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >> ----- Original Message ----- >>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | ] >>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | ] , "Paul >>> Sandoz" [ mailto:paul.sandoz at oracle.com | ] Cc: >>> "core-libs-dev" [ mailto:core-libs-dev at openjdk.org | >>> ] Sent: Friday, May 16, 2025 2:53:18 PM >>> Subject: Re: Towards a JSON API for the JDK >>> On 5/15/2025 5:27 PM, Remi Forax wrote: >>>> It's not clear to me why JsonArray (for example) has to be an interface instead >>>> of a record ? >>> Oh, you know the answer to this.? A record limits us to a single >>> implementation with a rigid representation.? Behind an interface, we can >>> hide lazy parsing and inflation, wrapping other representations to >>> reduce copies, etc. >> First, let me refine the question. >> There are only 4 kinds of JSON values that benefit from having different >> representations, object, array, string and number. >> For object and array, both takes an interface as parameter (Map or List) so >> JsonArray and JSonObject do not need to be themselves interfaces. >> So the only values where it may be worth to be modeled using an interface are >> JsonString and JsonNumber, because as you said, you can do "lazy" parsing. >> But delaying the parsing of the content has the side effect that even if >> Json.parse() did not throw an exception, it does not mean that the JSON text is >> valid, an exception may be thrown later. >> Now, for me, this library is more about being simple and safe than fast. >> If you agree with that, delaying the parsing is not a good idea, thus JSON >> values should be modeled using records and not interfaces. >> regards, >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.org Fri May 16 19:00:00 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 16 May 2025 19:00:00 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v8] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 21:57:17 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Adjust message based on review feedback Hi Henry, A few comments based on an initial pass through last update src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 65: > 63: * - does not contain a backslash, '\' > 64: * - does not contain a drive letter > 65: * - path element does not include '..' change to > * - path element does not include '.' or '..' src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 117: > 115: * and UNIX file systems etc. > 116: * Also validate that the file name is not "." and that any name element is > 117: * not equal to ".." Also validate that the file name is not "." or ".." and that any name element is * not equal to ".." or "." src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 132: > 130: * - CEN and LOC should have same entries, in the same order > 131: * NOTE: This implementation assumes CEN entries are to be added before > 132: * add any LOC entries. I think you should probably expand this comment a bit with the expected work flow as it takes a while to grasp your intent otherwise src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 155: > 153: } > 154: > 155: boolean isPlaceHolder() { A comment would be helpful here for future maintainers src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 287: > 285: \ or invalid file names that could lead to unintended effects.\n\ > 286: \ Check with the developer to ensure the jar archive integrity\n\ > 287: \ when warnings observed after using this option. I think this could be improved perhaps something like: main.help.opt.main.validate=\ \ --validate Validate the contents of the jar archive. This option will:\n\ \ + validate that the API exported by a multi-release\n\ \ jar archive is consistent across all different release\n\ \ versions.\n\ \ + warn if there are duplicate or invalid file names\n\ I think you can remove the verbiage WRT "Check with..." from the help message src/jdk.jartool/share/man/jar.md line 111: > 109: `--validate` > 110: : Validate the contents of the jar archive. > 111: Check with the developer to ensure the jar archive integrity You can remove here and add a suggestion in the "integrity of a Jar Archive" section as to what to do. src/jdk.jartool/share/man/jar.md line 223: > 221: > 222: ## Integrity of a jar Archive > 223: As a jar archive is based on ZIP format, it is possible to manufacture a jar archive using tools manufacture -> create src/jdk.jartool/share/man/jar.md line 224: > 222: ## Integrity of a jar Archive > 223: As a jar archive is based on ZIP format, it is possible to manufacture a jar archive using tools > 224: other than the `jar` command. The `--validate` options checks a jar archive for some integrity `The '--validate' option performs the following integrity checks:` src/jdk.jartool/share/man/jar.md line 237: > 235: - The API exported by a multi-release jar archive is consistent across all different release > 236: versions. > 237: I would consider something similar to: - That there are no duplicate Zip Entry file names - Verify that the Zip Entry file name: - is not an absolute path - the file name is not '.' or '..' - does not contain a backslash, '' - does not contain a drive letter - path element does not include '.' or '.. - The API exported by a multi-release jar archive is consistent across all different release versions. The jar tool will return a status code of 0 if there were no integrity issues encountered and a status code of 1 an issue was found. When an integrity issue is reported, it will often require that the jar file is re-created by the original source of the jar file ```. test/jdk/tools/jar/ValidatorTest.java line 325: > 323: } > 324: > 325: private void rm(String cmdline) { Maybe I missed it, but is this method used? ------------- PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2847026334 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093296698 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093300176 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093421481 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093422620 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093445110 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093448844 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093450314 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093452262 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093475451 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093537089 From asemenyuk at openjdk.org Fri May 16 19:02:03 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 May 2025 19:02:03 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4] In-Reply-To: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> Message-ID: <3QTgvW106VE7nzle7N_Sm4EaSMZRdmaBn_OUpakYNLE=.65e1028c-7305-48bb-9274-3df5d77ce284@github.com> On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk wrote: >> Refactor jpackage to separate the configuration and execution phases. >> At the configuration phase, jpackage parses command-line arguments and validates them. >> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. >> >> There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. >> >> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. >> >> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". >> >> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. >> >> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html >> >> **Functional changes** >> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. >> >> - Minimize copying of the source app image when doing native packaging. >> >> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. >> >> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. >> >> post- and pre- install PKG scripts for SimplePackageTest package before and after the change: >> >> >> >>
      Scr... > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits: > > - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh > - Merge branch 'master' into JDK-8333664 > - Remove redundant StandardBundlerParam.createResource() > - Adapt JDK-8352480 fix > - Merge branch 'master' into JDK-8333664 > - Fix javadoc > - Merge branch 'master' into JDK-8333664 > - 8333568: Test that jpackage doesn't modify R/O files/directories > > Reviewed-by: almatvee > - 8356562: SigningAppImageTwoStepsTest test fails > > Reviewed-by: almatvee > - Remove clean_stashed_files.sh > - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710 Thank you for the review! I'll address the findings. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2887469234 From asemenyuk at openjdk.org Fri May 16 19:23:59 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 May 2025 19:23:59 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4] In-Reply-To: <4GqhkY0xKEKx5h6p3aLH-1ooMcWVmWZksJyKsAdBdec=.41398343-bbf0-4e1a-b25e-378a359439f0@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> <4GqhkY0xKEKx5h6p3aLH-1ooMcWVmWZksJyKsAdBdec=.41398343-bbf0-4e1a-b25e-378a359439f0@github.com> Message-ID: On Tue, 13 May 2025 01:55:19 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits: >> >> - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh >> - Merge branch 'master' into JDK-8333664 >> - Remove redundant StandardBundlerParam.createResource() >> - Adapt JDK-8352480 fix >> - Merge branch 'master' into JDK-8333664 >> - Fix javadoc >> - Merge branch 'master' into JDK-8333664 >> - 8333568: Test that jpackage doesn't modify R/O files/directories >> >> Reviewed-by: almatvee >> - 8356562: SigningAppImageTwoStepsTest test fails >> >> Reviewed-by: almatvee >> - Remove clean_stashed_files.sh >> - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710 > > src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java line 477: > >> 475: return Optional.of(fa) >> 476: .flatMap(FileAssociation::icon) >> 477: .map(DesktopIntegration::getSquareSizeOfImage) > > `getSquareSizeOfImage` will return 0, if exception is thrown for invalid image. Should it return -1 or should we only accept icons if `getIconSize() > 0`? `getIconSize()` returns the value returned by `getSquareSizeOfImage()` call or -1 if icon is not specified. This way the return value of `getIconSize()` falls into three categories: - <0 - failed to get dimensions of the given icon; - 0 - no icon file specified; - \>0 - icon size; If we change `getSquareSizeOfImage()` as you suggest, the return value of `getIconSize()` will fall into two categories: - <0 - failed to get dimensions of the given icon, or the icon was not specified; - \>0 - icon size; This change will make it impossible to tell if the icon was given or if an error occurred reading it from the return value of `getIconSize()`. The caller code accepts an icon for the file association only if its size >0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2093568135 From jrose at openjdk.org Fri May 16 19:49:56 2025 From: jrose at openjdk.org (John R Rose) Date: Fri, 16 May 2025 19:49:56 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Move intrinsic to be a subsection; just one most common function of the annotation > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java > > Co-authored-by: Raffaello Giulietti > - Shorter first sentence > - Updates, thanks to John > - Refine validation and defensive copying > - 8355223: Improve documentation on @IntrinsicCandidate src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 33: > 31: * The {@code @IntrinsicCandidate} indicates that an annotated method is > 32: * recognized by {@code vmIntrinsics.hpp} for special treatment by the HotSpot > 33: * VM, unlike the other methods. The HotSpot VM checks, when loading a class, /, unlike the other methods/s/the other/other/ If you want something at the top that teaches about "the other methods", maybe say something like: > Normally, the VM executes methods using only their bytecodes (or JNI definitions), but the VM is (in addition) allowed to use specialized code or analysis logic for methods marked as intrinsics. Thus, intrinsic calls can be replaced or modified or specially optimized by the VM. But those points will be covered further down, so maybe not. More concisely: s/, unlike the other methods/, unlike normal methods, which depend only on bytecodes or native entry points for their meaning to the VM/ Or just: s/, unlike the other methods// Also, s/The HotSpot VM checks, when loading a class,/When loading a class, the HotSpot VM checks/ (fewer commas, better logical flow) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093593792 From weijun at openjdk.org Fri May 16 19:59:26 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 May 2025 19:59:26 GMT Subject: RFR: 8357062: Update Public Suffix List to 823beb1 Message-ID: This is a routine update to synchronize with the [Mozilla Public Suffix List](https://github.com/publicsuffix/list) for JDK 25, matching commit 823beb1 from 2025-05-12. The test has been updated to reflect corresponding changes. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/25273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357062 Stats: 3563 lines in 5 files changed: 1500 ins; 1442 del; 621 mod Patch: https://git.openjdk.org/jdk/pull/25273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25273/head:pull/25273 PR: https://git.openjdk.org/jdk/pull/25273 From duke at openjdk.org Fri May 16 20:02:02 2025 From: duke at openjdk.org (duke) Date: Fri, 16 May 2025 20:02:02 GMT Subject: Withdrawn: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote: > Alternative approach to #24012 > > This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. > > I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24057 From rriggs at openjdk.org Fri May 16 20:03:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 May 2025 20:03:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com> Message-ID: On Thu, 15 May 2025 20:34:13 GMT, Brian Burkhalter wrote: >> @stuart-marks Sorry, didn't want to pull you in here, that's why I said, I am just *paraphrasing*. >> >> That is correct, it is a different case, but the *final effect* for the caller is the same: If he needs to now whether a copy is made *or not*, he needs to have JavaDocs telling him *how* the new method works inside (whether it calls `subSequence` or whether it calls `getChars`). Otherwise he might make false assumptions about the result. > > This API is concerned with the "what" and not so much the "how." The purpose of Reader and subclasses is to normalize characters in various forms (char arrays, byte streams, char buffers, etc) into a coherent stream of characters and be able to read it incrementally. If the caller is going to use the entire CharSequence, as in the case of `Reader.of(cs)`, there is no reason to have a reader at all. Both String and CharSequence have more useful APIs than Reader for parsing. The motivation for reading all characters and reading lines came from use cases around input from sub-processes where the input is decoded from a byte stream, but that's not `Reader.of(cs).` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093611355 From jrose at openjdk.org Fri May 16 20:23:57 2025 From: jrose at openjdk.org (John R Rose) Date: Fri, 16 May 2025 20:23:57 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Move intrinsic to be a subsection; just one most common function of the annotation > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java > > Co-authored-by: Raffaello Giulietti > - Shorter first sentence > - Updates, thanks to John > - Refine validation and defensive copying > - 8355223: Improve documentation on @IntrinsicCandidate Marked as reviewed by jrose (Reviewer). src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 38: > 36: * > 37: *

      Intrinsification

      > 38: * The most frequently special treatment is intrinsification, which replaces a > The most frequently special treatment is intrinsification, which Better: > Most frequently, the special treatment of an intrinsic is intrinsification, which src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 47: > 45: * intrinsics necessary. > 46: *

      > 47: * Intrinsification may never happen, or happen at any moment during execution. s/or happen/or may happen/ (easier to parse) src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 53: > 51: * intrinsic implementors must ensure that non-bytecode execution has the same > 52: * results as execution of the actual Java code in all application contexts > 53: * (given the assumptions on the arguments hold). s/given the/given that the/ src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 57: > 55: * A candidate method should contain a minimal piece of Java code that should be > 56: * replaced by an intrinsic wholesale. The backing intrinsic is (in the common > 57: * case) unsafe - they do not perform checks, but have s/they do not perform/it may omit safety/ s/but have/but instead makes/ s/their/its/ s/that can ensure type safety/that type safety is ensured elsewhere/ src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 67: > 65: * accessing a field or method on an object which does not possess that field or > 66: * method; accessing an element of an array not actually present in the array; > 67: * and manipulating managed references in a way that prevents the GC from ? s/managed references/object references/ ("manage" is mentioned a moment later) src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 90: > 88: * intrinsic.) For example, the documentation can simply say that the result is > 89: * undefined if a race happens. However, race conditions must not lead to > 90: * program failures or type safety breaches, as listed above. Maybe add a teaching paragraph: > Reasoning about such race conditions is difficult, but it is a necessary skill when working with intrinsics that can observe racing shared variables. One example of a tolerable race is a repeated read of a shared reference. This only works if the algorithm takes no action based on the first read, other than deciding to perform the second read; it must "forget what it saw" in the first read. This is why the array-mismatch intrinsics can sometimes report a tentative search hit (maybe using vectorized code), which can then be confirmed (by scalar code) as the caller makes a fresh and independent observation. (This is done when the array mismatch logic performs NaN-folding. I just noticed that the NaN-folding code in ArraysSupport is slightly incorrect with respect to races!) ------------- PR Review: https://git.openjdk.org/jdk/pull/24777#pullrequestreview-2847502871 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093599254 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605455 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605395 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605356 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605323 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093632716 From shaojin.wensj at alibaba-inc.com Fri May 16 21:41:30 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Sat, 17 May 2025 05:41:30 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaVG93YXJkcyBhIEpTT04gQVBJIGZvciB0aGUgSkRL?= In-Reply-To: <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>, <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <3c9d37e7-fb38-40cb-ab95-5d7ad3e56019.shaojin.wensj@alibaba-inc.com> As the author of a popular json library (fastjson/fastjson2), I think the current design is not good, not easy to use, and the performance is not good. The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed like this, which will cause trouble to users and affect performance. For simple types of JSON, you can directly use Java type mapping, such as: null -> null string -> string number -> integer/long/bigint/float/double, select the mapping type through configuration, or according to a rule we set. Array and Object types should also support more flexible mapping: object -> JsonObject or Map (HashMap/LinkedHashMap/ConcurrentHashMap...) array -> JsonArray or List(ArrayList/LinkedList/...) or typed-array Lazy parsing should not be used because it will degrade performance. If we need to support partial parsing, we can provide a skip api, and later we can provide a jsonpath api, or support passing in type/JsonSchema information and parsing according to the schema. Also, if we want better performance, both Parser and Generator should provide both UTF16 and UTF8 implementations. ------------------------------------------------------------------ ????forax ?????2025?5?17?(??) 02:43 ????Brian Goetz ????Paul Sandoz; "core-libs-dev" ????Re: Towards a JSON API for the JDK From: "Brian Goetz" To: "Remi Forax" Cc: "Paul Sandoz" , "core-libs-dev" Sent: Friday, May 16, 2025 7:46:09 PM Subject: Re: Towards a JSON API for the JDK If you read the implementation, you'll see that significant laziness is indeed possible for JsonObject and JsonArray, even while doing eager validation. (Of course, one can shift the balance to achieve various other tradeoffs.) Reading the implementation is on my TODO list :) R?mi On 5/16/2025 10:35 AM, forax at univ-mlv.fr wrote: ----- Original Message ----- From: "Brian Goetz" To: "Remi Forax" , "Paul Sandoz" Cc: "core-libs-dev" Sent: Friday, May 16, 2025 2:53:18 PM Subject: Re: Towards a JSON API for the JDK On 5/15/2025 5:27 PM, Remi Forax wrote: It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? Oh, you know the answer to this. A record limits us to a single implementation with a rigid representation. Behind an interface, we can hide lazy parsing and inflation, wrapping other representations to reduce copies, etc. First, let me refine the question. There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number. For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces. So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing. But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later. Now, for me, this library is more about being simple and safe than fast. If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces. regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Fri May 16 23:43:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 May 2025 23:43:48 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v5] In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> Message-ID: <9Dt1iXbcsd6PQVdANTY-8mhGFYoszrfVxUsEHnkOXIs=.b16637aa-7320-404b-bee6-29fadc99ed4b@github.com> > Refactor jpackage to separate the configuration and execution phases. > At the configuration phase, jpackage parses command-line arguments and validates them. > At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. > > There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. > > This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. > > The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". > > Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. > > jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html > > **Functional changes** > jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. > > - Minimize copying of the source app image when doing native packaging. > > Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. > > - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. > > post- and pre- install PKG scripts for SimplePackageTest package before and after the change: > > > > > > > > > appImageLayout - destktop -> desktop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19668/files - new: https://git.openjdk.org/jdk/pull/19668/files/011eb710..8447a3e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=03-04 Stats: 42 lines in 15 files changed: 4 ins; 6 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/19668.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668 PR: https://git.openjdk.org/jdk/pull/19668 From asemenyuk at openjdk.org Fri May 16 23:47:07 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 May 2025 23:47:07 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4] In-Reply-To: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com> Message-ID: On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk wrote: >> Refactor jpackage to separate the configuration and execution phases. >> At the configuration phase, jpackage parses command-line arguments and validates them. >> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. >> >> There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. >> >> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. >> >> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". >> >> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. >> >> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html >> >> **Functional changes** >> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. >> >> - Minimize copying of the source app image when doing native packaging. >> >> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. >> >> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. >> >> post- and pre- install PKG scripts for SimplePackageTest package before and after the change: >>
      ScriptNewOld
      >> >> >>
      Scr... > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits: > > - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh > - Merge branch 'master' into JDK-8333664 > - Remove redundant StandardBundlerParam.createResource() > - Adapt JDK-8352480 fix > - Merge branch 'master' into JDK-8333664 > - Fix javadoc > - Merge branch 'master' into JDK-8333664 > - 8333568: Test that jpackage doesn't modify R/O files/directories > > Reviewed-by: almatvee > - 8356562: SigningAppImageTwoStepsTest test fails > > Reviewed-by: almatvee > - Remove clean_stashed_files.sh > - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710 All findings fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2887850571 From acobbs at openjdk.org Fri May 16 23:55:57 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 16 May 2025 23:55:57 GMT Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v3] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 21:04:40 GMT, Archie Cobbs wrote: >> Please review this small performance tweak `ArrayDeque`. >> >> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Blackhole ArrayDeque to ensure it's not ignored by the compiler. I'm closing the PR because it's gone into low-level optimization details that are beyond me. However I'm still unclear on whether bulk memory set operations are being fully optimized. By that I mean doing [something like this](https://git.zx2c4.com/glibc/commit/?id=cec3aef32412779e207f825db0d057ebb4628ae8) on arm64 at least. Any insights from the experts would be appreciated. Thanks for the interesting discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2887858521 From acobbs at openjdk.org Fri May 16 23:55:57 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 16 May 2025 23:55:57 GMT Subject: Withdrawn: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops In-Reply-To: References: Message-ID: <4yLc7hJ5iTo4C1dRixGE6m-icwHq1WK1cTBga_ztCi0=.8d08547f-008f-4540-8a3f-992ab2dc92f7@github.com> On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs wrote: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25237 From naoto at openjdk.org Sat May 17 00:13:05 2025 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 17 May 2025 00:13:05 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods Message-ID: `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. ------------- Commit messages: - Tests read* method variations - Merge branch 'master' into JDK-8356985-Use-stdin-encoding-in-Console - initial commit Changes: https://git.openjdk.org/jdk/pull/25271/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356985 Stats: 270 lines in 11 files changed: 241 ins; 3 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/25271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271 PR: https://git.openjdk.org/jdk/pull/25271 From smarks at openjdk.org Sat May 17 01:02:03 2025 From: smarks at openjdk.org (Stuart Marks) Date: Sat, 17 May 2025 01:02:03 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2] In-Reply-To: <3-h5cco6E3PRpslFiqAR913I_lJ8_c0tMHhREoHCkps=.a9ba0091-c77d-4dda-b7d0-53e83ac57ca3@github.com> References: <3-h5cco6E3PRpslFiqAR913I_lJ8_c0tMHhREoHCkps=.a9ba0091-c77d-4dda-b7d0-53e83ac57ca3@github.com> Message-ID: On Fri, 16 May 2025 09:24:13 GMT, Jaikiran Pai wrote: >> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: >> >> Reversed view of SynchronizedRandomAccessList should also be RandomAccess. >> Add tests to ensure RandomAccess is preserved when reversing. > > test/jdk/java/util/Collections/SyncListBash.java line 31: > >> 29: * @run main SyncListBash f >> 30: * @run main SyncListBash r >> 31: * @summary Test that List's new SequencedCollection methods are properly > > Nit - jtreg recommends `@summary` to be after `@bug` https://openjdk.org/jtreg/tag-spec.html#ORDER. It would be good to follow that for this new test. Oh, thanks for pointing this out. I'll fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2093806293 From almatvee at openjdk.org Sat May 17 01:09:00 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 17 May 2025 01:09:00 GMT Subject: RFR: 8333664: Decouple command line parsing and package building in jpackage [v5] In-Reply-To: <9Dt1iXbcsd6PQVdANTY-8mhGFYoszrfVxUsEHnkOXIs=.b16637aa-7320-404b-bee6-29fadc99ed4b@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> <9Dt1iXbcsd6PQVdANTY-8mhGFYoszrfVxUsEHnkOXIs=.b16637aa-7320-404b-bee6-29fadc99ed4b@github.com> Message-ID: On Fri, 16 May 2025 23:43:48 GMT, Alexey Semenyuk wrote: >> Refactor jpackage to separate the configuration and execution phases. >> At the configuration phase, jpackage parses command-line arguments and validates them. >> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. >> >> There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. >> >> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. >> >> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". >> >> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. >> >> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html >> >> **Functional changes** >> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. >> >> - Minimize copying of the source app image when doing native packaging. >> >> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. >> >> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. >> >> post- and pre- install PKG scripts for SimplePackageTest package before and after the change: >> >> >> >>
      Scr... > > Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision: > > - Cleanup > - appImageLyout -> appImageLayout > - destktop -> desktop Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19668#pullrequestreview-2847819117 From smarks at openjdk.org Sat May 17 01:14:01 2025 From: smarks at openjdk.org (Stuart Marks) Date: Sat, 17 May 2025 01:14:01 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2] In-Reply-To: References: Message-ID: <5Kk4sYns2VWuHD1MLEVCP96dfxCMt3mecJ1xhdUv6bA=.4720bdaf-a943-496d-b7ec-7f0d89369a3d@github.com> On Thu, 15 May 2025 12:17:14 GMT, Per Minborg wrote: >> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: >> >> Reversed view of SynchronizedRandomAccessList should also be RandomAccess. >> Add tests to ensure RandomAccess is preserved when reversing. > > src/java.base/share/classes/java/util/Collections.java line 2782: > >> 2780: synchronized (mutex) {list.sort(c);} >> 2781: } >> 2782: public void addFirst(E element) { > > Are these overloads strictly needed as the `default` implementations will delegate to `get` and `set`, which, in turn, are thread safe? (I think you mean overrides?) Good question. It might be possible to get away without overriding and delegating every method. However, these wrapper classes have historically had bugs that arose from failing to override some methods. This isn't the first time this has happened. Thus I'm inclined to add the overrides even if they aren't strictly necessary. I added this note to the bug report just now: > It's clear that the getFirst(), getLast(), removeFirst(), and removeLast() default methods must be overridden and synchronized in order to guarantee proper operation. The addFirst() and addLast() methods each resolve to a single call to 'this' and so we could probably get away without overriding them. However, it's possible, though unlikely, that the default method implementations could change, making them unsafe. In addition, it's a bit nicer to the backing list to have all the methods on the wrapper delegate to the corresponding methods of the backing list. This might be helpful if the backing list has some optimizations for particular methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2093809289 From smarks at openjdk.org Sat May 17 01:25:14 2025 From: smarks at openjdk.org (Stuart Marks) Date: Sat, 17 May 2025 01:25:14 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v3] In-Reply-To: References: Message-ID: <4roAjSkqEbwwAk5GsfRSGAPTXZLBcXwzdxXa9SqTyLg=.5974684e-fbce-4cee-8ad2-cb5098bac213@github.com> > Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: > > - overrides and adds locking to SequencedCollection methods; > - performs instance management of reversed synchronized views; > - adds test for race conditions and functional tests of synchronized wrappers. Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into JDK-8351230-synchronized-list - Adjust @summary line in test. - Reversed view of SynchronizedRandomAccessList should also be RandomAccess. Add tests to ensure RandomAccess is preserved when reversing. - moar comments - Various tweaks. - fix for synch list - fix copyright line - tests for synch list ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24990/files - new: https://git.openjdk.org/jdk/pull/24990/files/1750bb20..0ad5d080 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=01-02 Stats: 58374 lines in 1704 files changed: 29902 ins; 19676 del; 8796 mod Patch: https://git.openjdk.org/jdk/pull/24990.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24990/head:pull/24990 PR: https://git.openjdk.org/jdk/pull/24990 From henryjen at openjdk.org Sat May 17 01:27:38 2025 From: henryjen at openjdk.org (Henry Jen) Date: Sat, 17 May 2025 01:27:38 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: References: Message-ID: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen 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/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/1bc1f8cb..da4a9139 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=07-08 Stats: 53 lines in 4 files changed: 12 ins; 20 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From jpai at openjdk.org Sat May 17 02:20:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 17 May 2025 02:20:00 GMT Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v3] In-Reply-To: <4roAjSkqEbwwAk5GsfRSGAPTXZLBcXwzdxXa9SqTyLg=.5974684e-fbce-4cee-8ad2-cb5098bac213@github.com> References: <4roAjSkqEbwwAk5GsfRSGAPTXZLBcXwzdxXa9SqTyLg=.5974684e-fbce-4cee-8ad2-cb5098bac213@github.com> Message-ID: On Sat, 17 May 2025 01:25:14 GMT, Stuart Marks wrote: >> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: >> >> - overrides and adds locking to SequencedCollection methods; >> - performs instance management of reversed synchronized views; >> - adds test for race conditions and functional tests of synchronized wrappers. > > Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8351230-synchronized-list > - Adjust @summary line in test. > - Reversed view of SynchronizedRandomAccessList should also be RandomAccess. > Add tests to ensure RandomAccess is preserved when reversing. > - moar comments > - Various tweaks. > - fix for synch list > - fix copyright line > - tests for synch list Thank you for the update, Stuart. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24990#pullrequestreview-2847863986 From liach at openjdk.org Sat May 17 02:21:36 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 17 May 2025 02:21:36 GMT Subject: RFR: 8357178: Simplify Class::componentType Message-ID: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> `isArray` and null return is now redundant when `componentType` is changed to an explicit field. ------------- Commit messages: - 8357178: Simplify Class::componentType Changes: https://git.openjdk.org/jdk/pull/25280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357178 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25280/head:pull/25280 PR: https://git.openjdk.org/jdk/pull/25280 From ethan at mccue.dev Sat May 17 05:58:37 2025 From: ethan at mccue.dev (Ethan McCue) Date: Sat, 17 May 2025 07:58:37 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I fail to see a fundamental difference in level (high vs. low) - we should consider extensibility, ergonomics, and how people are likely to use the API. "It gets in the way of laziness" is a valid reason to have JsonObject not be a Map (though I still want to interrogate it), "the idea is to use delegation" and a desire for "DOP over OOP" is not. This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing one particular encoding of JSON and making it central to the API. Is that really the most important encoding? And I get a lot of mileage out of Json extending JsonEncodable - both in terms of ergonomics for constructing Json structures (being able to turn a List into Json using the same overload as you would a List, etc.) as well as an extension point for interacting with other json libraries (easy to teach jackson and co. to treat something implementing an interface differently). On Fri, May 16, 2025 at 2:26?PM wrote: > > > ------------------------------ > > *From: *"Ethan McCue" > *To: *"Remi Forax" > *Cc: *"Paul Sandoz" , "core-libs-dev" < > core-libs-dev at openjdk.org> > *Sent: *Friday, May 16, 2025 1:44:52 AM > *Subject: *Re: Towards a JSON API for the JDK > > I present for your consideration the library I made when spiraling about > this problem space a few years ago > > https://github.com/bowbahdoe/json > > > https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html > > Notably missing during the design process here were patterns, hence the > JsonDecoder design. I haven't been able to evaluate how patterns affect > that on account of them not being out. > > I will more thoroughly peruse the draft of java.util.json at a later date, > but my initial observations/comments: > > * I am not sure having JsonValue be distinct from Json has value. > * toUntyped feels a little strange to me - the only type information > presumably lost is the sealed-ness of the hierarchy. The interplay between > that and toNumber is also a little unnerving. > * One notion that I found helpful was that a class could be "json > encodable," meaning there is a method to call to obtain a canonical json > representation. > > record Person(String name) implements JsonEncodable { > @Override > public Json toJson() { > return Json.objectBuilder() > .put("namen", name) > .build(); > } > } > > Which helper methods like Json#of(List) could > make use of. Json itself (JsonValue in your prototype) could then have a > vacuous implementation. > > * Terminology wise - I went with reading/writing for the actual > parsing/generation of json and encoding/decoding for the mapping of those > representations to/from specific classes. The merits are not top of mind, > just noting the difference. read/write vs parse/toString+toDisplayString > * One thing I did was make the helper methods in Json null tolerant and > the ones in the specific subtypes like JsonString not. This was because > from what I saw of usages of javax.json/jakarta.json that nullability was a > footgun and correcting for it required changes to code structure (breaking > up builder chains with if (x != null) checks) > * The functionality you want from JsonNumber could be achieved by making > it just extend Number ( > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java) > instead of a bespoke toNumber. You need the extra methods to go to big > decimal and co, but it's just an extension to the behavior of Number at > that point. > * JsonObject and JsonArray could implement Map and > List respectively. This lowers the need for toUntyped() - since > presumably one of the use cases for that is turning the json tree into > something that more generic map/list traversal code can handle. It also > complicates any lazy loading somewhat. > * Assuming patterns can be placed on interfaces, you might want to > consider something similar to JsonDecoder, but with a pattern instead of > a method that throws an exception. > > // Where here fromJson would box up the logic for testing and extracting > from each element in the array. > List people = array(json, Person::fromJson); > > * I don't think there is sufficient cause for anything to be non-sealed at > this point. > * JsonBoolean and JsonNull do not have reasonable alternative > implementations - as far as I can imagine, maybe i'm wrong - so maybe those > can just be final classes? > * If you seal up the whole hierarchy then its pretty trivial to make it > serializable ( > https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java > ) > > > Hello, > I think your library is more high-level than java.util.json. > Moreover, Paul proposes a design closer to DOP (Data Oriented Programming) > than OOP. > > JsonNumber should not extend Number, JsonObject and JsonArray should not > implements Map and List, the idea is to use delegation instead. > (BTW extending Number will become an issue in the future if the VM tries > to flatten filed typed with a value capable abstract class like Number) > > JSON is fundamentally untyped and recursive, but also describe data > structures, for me, the proposed API exposes that structure (the subtypes > of JsonValue) and make it easy to move from a JSON text to Java objects or > vice-versa. > The java.util.json API is very simple, > - Json.fromUntyped() see a Java object to a structured JSON value (a > JsonValue), > - Json.toUntyped() unwrap a structured JSON value to extract the > underlying Java object. > - Json.parse() from String to a structured JSON value > - Json.toDisplayString() (i would prefer "prettyString") goes from a > structured JSON value to a pretty string. > > Having a JsonEncoder and JsonDecoder, JsonDecodable, etc is more high > level than what is proposed here, so you can write objects like > JsonEncoder/Decoder on top of it. > Your example of JsonEncodable can be re-written to use the java.util.json > API like this > > record Person(String name) implements JsonEncodable { > @Override > public JsonValue toJson() { > return Json.fromUntyped(Map.of("name", name)); > } > } > > Compared to your code, java.util.json uses immutable data structures > instead of a mutable builder (and yes, you lose the order, until > SequenceMap.of() exists). > > regards, > R?mi > > > > > On Thu, May 15, 2025 at 11:29?PM Remi Forax wrote: > >> Hi Paul, >> yes, not having a simple JSON API in Java is an issue for beginners. >> >> It's not clear to me why JsonArray (for example) has to be an interface >> instead of a record ? >> >> I understand why Json.parse() only works on String and char[] but the API >> make it too easy to have many performance issues. >> I think you need versions using a Reader and a Path. >> Bonus point, if there is a method walk() that also returns a JsonValue >> but the List/Map inside JsonArray/JsonObject are populated lazily. >> >> Minor point: Json.toDisplayString() should takes a second parameters >> indicating the number of spaces used for the indentation (like >> JSON.stringify in JS). >> >> regards, >> R?mi >> >> ----- Original Message ----- >> > From: "Paul Sandoz" >> > To: "core-libs-dev" >> > Sent: Thursday, May 15, 2025 10:30:42 PM >> > Subject: Towards a JSON API for the JDK >> >> > Hi, >> > >> > We would like to share with you our thoughts and plans towards a JSON >> API for >> > the JDK. >> > Please see the document below. >> > >> > - >> > >> > We have had the pleasure of using a clone of this API in some >> experiments we are >> > conducting with >> > ONNX and code reflection [1]. Using the API we were able to quickly >> write code >> > to ingest and convert >> > a JSON document representing ONNX operation schema into instances of >> records >> > modeling the schema >> > (see here [2]). >> > >> > The overall out-of-box experience with such a minimal "batteries >> included? API >> > has so far been positive. >> > >> > Thanks, >> > Paul. >> > >> > [1] https://openjdk.org/projects/babylon/ >> > [2] >> > >> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 >> > >> > # Towards a JSON API for the JDK >> > >> > One of the most common requests for the JDK is an API for parsing and >> generating >> > JSON. While JSON originated as a text-based serialization format for >> JSON >> > objects ("JSON" stands for "JavaScript Object Notation"), because of >> its simple >> > and flexible syntax, it eventually found use outside the JavaScript >> ecosystem as >> > a general data interchange format, such as framework configuration >> files and web >> > service requests/response formats. >> > >> > While the JDK cannot, and should not, provide libraries for every >> conceivable >> > file format or protocol, the JDK philosophy is one of "batteries >> included", >> > which is to say we should be able to write basic programs that use >> common >> > protocols such as HTTP, without having to appeal to third party >> libraries. >> > The Java ecosystem already has plenty of JSON libraries, so inclusion in >> > the JDK is largely meant to be a convenience, rather than needing to be >> the "one >> > true" JSON library to meet the needs of all users. Users with specific >> needs >> > are always free to select one of the existing third-party libraries. >> > >> > ## Goals and requirements >> > >> > Our primary goal is that the library be simple to use for parsing, >> traversing, >> > and generating conformant JSON documents. Advanced features, such as >> data >> > binding or path-based traversal should be possible to implement as >> layered >> > features, but for simplicity are not included in the core API. We adopt >> a goal >> > that the performance should be "good enough", but where performance >> > considerations conflict with simplicity and usability, we will choose >> in favor >> > of the latter. >> > >> > ## API design approach >> > >> > The description of JSON at `https:://json.org` describes a JSON >> document using >> > the familiar "railroad diagram": >> > ![image](https://www.json.org/img/value.png) >> > >> > This diagram describes an algebraic data type (a sum of products), >> which we >> > model directly with a set of Java interfaces: >> > >> > ``` >> > interface JsonValue { } >> > interface JsonArray extends JsonValue { List values(); } >> > interface JsonObject extends JsonValue { Map >> members(); } >> > interface JsonNumber extends JsonValue { Number toNumber(); } >> > interface JsonString extends JsonValue { String value(); } >> > interface JsonBoolean extends JsonValue { boolean value(); } >> > interface JsonNull extends JsonValue { } >> > ``` >> > >> > These interfaces have (hidden) companion implementation classes that >> admit >> > greater flexibility of implementation than modeling them directly with >> records >> > would permit. >> > Further, these interfaces are unsealed. We compromise on the sealed sum >> of >> > products to enable >> > alternative implementations, for example to support alternative formats >> that >> > encode the same information in a JSON document but in a more efficient >> form than >> > text. >> > >> > The API has static methods for parsing strings into a `JsonValue`, >> conversion to >> > and from purely untyped representations (lists and maps), and factory >> methods >> > for building JSON documents. We apply composition consistently, e.g, a >> > JsonString has a string, a JsonObject has a map of string to JsonValue, >> as >> > opposed to extension for structural JSON values. >> > >> > It turns out that this simple API is almost all we need for traversal. >> It gives >> > us an immutable representation of a document, and we can use pattern >> matching to >> > answer the myriad questions that will come up (Does this object have >> key X? Does >> > it map to a number? Is that number representable as an integer?) when >> going >> > from an untyped format like JSON to a more strongly typed domain model. >> > Given a simple document like: >> > >> > ``` >> > { >> > "name": "John?, >> > "age": 30 >> > } >> > ``` >> > >> > we can parse and traverse the document as follows: >> > >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject o >> > && o.members().get("name") instanceof JsonString s >> > && s.value() instanceof String name >> > && o.members().get("age") instanceof JsonNumber n >> > && n.toNumber() instanceof Long l && l instanceof int age) { >> > // use "name" and "age" >> > } >> > ``` >> > >> > Later, when the language acquires the ability to expose deconstruction >> patterns >> > for arbitrary interfaces (similar to today's record patterns, see >> > >> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns >> ), >> > this will be simplifiable to: >> > >> > ``` >> > JsonValue doc = Json.parse(inputString); >> > if (doc instanceof JsonObject(var members) >> > && members.get("name") instanceof JsonString(String name) >> > && members.get("age") instanceof JsonNumber(int age)) { >> > // use "name" and "age" >> > } >> > ``` >> > >> > So, overtime, as more pattern matching features are introduced we >> anticipate >> > improved use of the API. This is a primary reason why the API is so >> minimal. >> > Convenience methods we add today, such as a method that accesses a JSON >> > object component as say a JSON string or throws an exception, will >> become >> > redundant in the future. >> > >> > ## JSON numbers >> > >> > The specification of JSON number makes no explicit distinction between >> integral >> > and decimal numbers, nor specifies limits on the size of those numbers. >> > This is a common source of interoperability issues when consuming JSON >> > documents. Generally users cannot always but often do assume JSON >> numbers are >> > parsable, without loss of precision, to IEEE double-precision floating >> point >> > numbers or 32-bit signed integers. >> > >> > In this respect the API provides three means to operate on the JSON >> number, >> > giving the user full control: >> > >> > 1. Underlying string representation can be obtained, if preserving >> syntactic >> > details such as leading or trailing zeros is important. >> > 2. The string representation can be parsed to an instance of >> `BigDecimal`, using >> > `toBigDecimal` if preserving decimal numbers is important. >> > 3. The string representation can be parsed into an instance of `Long`, >> `Double`, >> > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this >> method >> > depends on how the representation can be parsed, possibly losing >> precision, >> > choosing a suitably convenient numeric type that can then be pattern >> > matched on. >> > >> > Primitive pattern matching will help as will further pattern matching >> features >> > enabling the user to partially match. >> > >> > ## Prototype implementation >> > >> > The prototype implementation is currently located into the JDK sandbox >> > repository >> > under the `json` branch, see >> > here >> > >> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json >> > The prototype API javadoc generated from the repository is also >> available at >> > >> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html >> > >> > ### Testing and conformance >> > >> > The prototype implementation passes all conformance test cases but two, >> > available >> > on https://github.com/nst/JSONTestSuite. The two exceptions are the >> ones which >> > the >> > prototype specifically prohibits, i.e, duplicated names in JSON objects >> > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35 >> ). >> > >> > ### Performance >> > >> > Our main focus so far has been on the API design and a functional >> > implementation. >> > Hence, there has been less focus on performance even though we know >> there are a >> > number of performance enhancements we can make eventually. >> > We are reasonably happy with the current performance. The >> > implementation performs well when compared to other JSON implementations >> > parsing from string instances and traversing documents. >> > >> > An example of where we may choose simplicity and usability over >> performance >> > is the rejection of JSON documents containing objects that in turn >> contain >> > members >> > with duplicate names. That may increase the cost of parsing, but >> simplifies the >> > user >> > experience for the majority of cases since if we reasonably assume >> JsonObjects >> > are >> > map-like, what should the user do with such members, pick one the last >> one? >> > merge >> > the values? or reject? >> > >> > ## A JSON JEP? >> > >> > We plan to draft JEP when we are ready. Attentive readers will observe >> that >> > a JEP already exists, JEP 198: Light-Weight JSON API >> > (https://openjdk.org/jeps/198). We will >> > either update this JEP, or withdraw it and draft a new one. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat May 17 06:39:55 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 17 May 2025 06:39:55 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com> <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com> <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com> Message-ID: On Fri, 16 May 2025 20:00:53 GMT, Roger Riggs wrote: >> This API is concerned with the "what" and not so much the "how." > > The purpose of Reader and subclasses is to normalize characters in various forms (char arrays, byte streams, char buffers, etc) into a coherent stream of characters and be able to read it incrementally. > If the caller is going to use the entire CharSequence, as in the case of `Reader.of(cs)`, there is no reason to have a reader at all. Both String and CharSequence have more useful APIs than Reader for parsing. > The motivation for reading all characters and reading lines came from use cases around input from sub-processes where the input is decoded from a byte stream, but that's not `Reader.of(cs).` In many situations the programmer has no choice whether to use a reader or not, as the code he works in must fulfill a given specification (like JAX-RS), so he is getting a `Reader` *whether needed or not* -- it is not under *his* control. But as he wants to get *all* content, he likes to use this new method. Pretty valid and frequent use case in the enterprise world. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093982275 From thomas.stuefe at gmail.com Sat May 17 06:41:19 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 17 May 2025 08:41:19 +0200 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: References: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com> Message-ID: Side note, I did not find any tests for the VFORK mode. Even the FORK mode seems not that well covered ( we only seem to run java/lang/ProcessBuilder/Basic.java in FORK mode) On Fri, May 16, 2025 at 6:59?PM Thomas St?fe wrote: > I am fine with waiting past 25, though the continued existence of this > mode makes me apprehensive. Back at SAP I have seen real customer issues > from these kind of problems, and we only catched those out of accident. > > A separate deprecation for JDK 25 may be a good first step (a warning, but > continued acceptance, of the VFORK mode) > > On Fri, May 16, 2025 at 6:20?PM Joseph D. Darcy > wrote: > >> I concur that this work is better down early in JDK 26. >> >> Thanks, >> >> -Joe >> >> On 5/16/2025 12:26 AM, Thomas St?fe wrote: >> >> Okay, moved the release version to 26. >> >> Could one of you (you or @Roger Riggs ) review >> the CSR if you have the cycles to spare? >> >> https://bugs.openjdk.org/browse/JDK-8357090 >> >> Thanks! >> >> On Fri, May 16, 2025 at 7:56?AM Alan Bateman >> wrote: >> >>> On 16/05/2025 05:10, Thomas St?fe wrote: >>> >>> >>> >>>> >>> Thank you, Alan. I will prepare a patch and a CSR. >>> >>> Okay, and maybe something for early in JDK 26 to avoid touching this >>> area close to the fork for JDK 25 RDP1. >>> >>> -Alan >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Sat May 17 06:52:44 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 17 May 2025 08:52:44 +0200 Subject: ProcessImpl: Can we obsolete the vfork mode? In-Reply-To: References: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com> <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com> Message-ID: This is the deprecation issue: https://bugs.openjdk.org/browse/JDK-8357179 Deprecation patch PR: https://github.com/openjdk/jdk/pull/25282 Deprecation CSR: https://bugs.openjdk.org/browse/JDK-8357180 Deprecation Release Note: https://bugs.openjdk.org/browse/JDK-8357181 Cheers, Thomas On Sat, May 17, 2025 at 8:41?AM Thomas St?fe wrote: > Side note, I did not find any tests for the VFORK mode. Even the FORK mode > seems not that well covered ( we only seem to run > java/lang/ProcessBuilder/Basic.java in FORK mode) > > On Fri, May 16, 2025 at 6:59?PM Thomas St?fe > wrote: > >> I am fine with waiting past 25, though the continued existence of this >> mode makes me apprehensive. Back at SAP I have seen real customer issues >> from these kind of problems, and we only catched those out of accident. >> >> A separate deprecation for JDK 25 may be a good first step (a warning, >> but continued acceptance, of the VFORK mode) >> >> On Fri, May 16, 2025 at 6:20?PM Joseph D. Darcy >> wrote: >> >>> I concur that this work is better down early in JDK 26. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 5/16/2025 12:26 AM, Thomas St?fe wrote: >>> >>> Okay, moved the release version to 26. >>> >>> Could one of you (you or @Roger Riggs ) review >>> the CSR if you have the cycles to spare? >>> >>> https://bugs.openjdk.org/browse/JDK-8357090 >>> >>> Thanks! >>> >>> On Fri, May 16, 2025 at 7:56?AM Alan Bateman >>> wrote: >>> >>>> On 16/05/2025 05:10, Thomas St?fe wrote: >>>> >>>> >>>> >>>>> >>>> Thank you, Alan. I will prepare a patch and a CSR. >>>> >>>> Okay, and maybe something for early in JDK 26 to avoid touching this >>>> area close to the fork for JDK 25 RDP1. >>>> >>>> -Alan >>>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.org Sat May 17 06:55:02 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 17 May 2025 06:55:02 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) Message-ID: For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. We plan to deprecate this in JDK 25 and to remove it in JDK 26. This patch just writes a deprecation message to stderr: 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls VFORK MODE DEPRECATED The VFORK launch mechanism has been deprecated for being dangerous. It will be removed in a future java version. Either remove the jdk.lang.Process.launchMechanism property (preferred) or use FORK mode instead (-Djdk.lang.Process.launchMechanism=FORK). ... ------------- Commit messages: - deprecate-vfork Changes: https://git.openjdk.org/jdk/pull/25282/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357179 Stats: 14 lines in 1 file changed: 10 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25282/head:pull/25282 PR: https://git.openjdk.org/jdk/pull/25282 From ethan at mccue.dev Sat May 17 08:29:36 2025 From: ethan at mccue.dev (Ethan McCue) Date: Sat, 17 May 2025 10:29:36 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <3c9d37e7-fb38-40cb-ab95-5d7ad3e56019.shaojin.wensj@alibaba-inc.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <3c9d37e7-fb38-40cb-ab95-5d7ad3e56019.shaojin.wensj@alibaba-inc.com> Message-ID: I think we should pull apart those concerns a little: I am of the opinion that the API is more important at this stage than the actual implementation, save for the places where having an API of a particular shape mandates implementation choices. > The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed like this, which will cause trouble to users and affect performance. Can you go very deep on why you think this is the case? There are properties of this today (i.e. indirection due to a lack of value classes) which can be resolved in time, but others which are intrinsic. > For simple types of JSON, you can directly use Java type mapping, such as: > null -> null > string -> string > number -> integer/long/bigint/float/double, select the mapping type through configuration, or according to a rule we set. So that is what toUntyped provides in this draft - having a pass-through with the explicit hierarchy. Can you also elaborate on the use cases you have seen for the "direct Java type mapping?" What APIs expect these generic structures? On Fri, May 16, 2025 at 11:42?PM wenshao wrote: > As the author of a popular json library (fastjson/fastjson2), I think the > current design is not good, not easy to use, and the performance is not > good. > The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed > like this, which will cause trouble to users and affect performance. > > For simple types of JSON, you can directly use Java type mapping, such as: > null -> null > string -> string > number -> integer/long/bigint/float/double, select the mapping type > through configuration, or according to a rule we set. > > > Array and Object types should also support more flexible mapping: > object -> JsonObject or Map (HashMap/LinkedHashMap/ConcurrentHashMap...) > array -> JsonArray or List(ArrayList/LinkedList/...) or typed-array > > > Lazy parsing should not be used because it will degrade performance. If we > need to support partial parsing, we can provide a skip api, and later we > can provide a jsonpath api, or support passing in type/JsonSchema > information and parsing according to the schema. > > Also, if we want better performance, both Parser and Generator should > provide both UTF16 and UTF8 implementations. > > ------------------------------------------------------------------ > ????forax > ?????2025?5?17?(??) 02:43 > ????Brian Goetz > ? ??Paul Sandoz; "core-libs-dev"< > core-libs-dev at openjdk.org> > ? ??Re: Towards a JSON API for the JDK > > > > ------------------------------ > *From: *"Brian Goetz" > *To: *"Remi Forax" > *Cc: *"Paul Sandoz" , "core-libs-dev" < > core-libs-dev at openjdk.org> > *Sent: *Friday, May 16, 2025 7:46:09 PM > *Subject: *Re: Towards a JSON API for the JDK > If you read the implementation, you'll see that significant laziness is > indeed possible for JsonObject and JsonArray, even while doing eager > validation. (Of course, one can shift the balance to achieve various other > tradeoffs.) > > Reading the implementation is on my TODO list :) > > R?mi > > > > On 5/16/2025 10:35 AM, forax at univ-mlv.fr wrote: > > ----- Original Message ----- > > From: "Brian Goetz" > To: "Remi Forax" , "Paul Sandoz" > Cc: "core-libs-dev" > Sent: Friday, May 16, 2025 2:53:18 PM > Subject: Re: Towards a JSON API for the JDK > > On 5/15/2025 5:27 PM, Remi Forax wrote: > > It's not clear to me why JsonArray (for example) has to be an interface instead > of a record ? > > Oh, you know the answer to this. A record limits us to a single > implementation with a rigid representation. Behind an interface, we can > hide lazy parsing and inflation, wrapping other representations to > reduce copies, etc. > > First, let me refine the question. > There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number. > For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces. > > So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing. > > But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later. > > Now, for me, this library is more about being simple and safe than fast. > If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces. > > regards, > R?mi > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat May 17 11:28:51 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 17 May 2025 11:28:51 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: References: Message-ID: <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com> On Wed, 14 May 2025 18:48:50 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Use type long for bitLength instead of int" >> >> This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c. > > The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now. > > I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26. > > In other words, take your time ;-) @rgiulietti Regarding the tests for _n_-th root, the tests for `sqrt()` and `pow()` could be extended in order to test also `nthRoot()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2888313569 From ethan at mccue.dev Sat May 17 11:37:28 2025 From: ethan at mccue.dev (Ethan McCue) Date: Sat, 17 May 2025 13:37:28 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Message-ID: I think it's worth noting that the way you used the prospective API in your ONNX code is not representative of how the API would generally be used in a jdk-only scenario. Custom making a general transformation from JsonValue -> Record is outside the ken of i'd say most. I'd be interested in an experience report of using it straight up. On Thu, May 15, 2025 at 10:31?PM Paul Sandoz wrote: > Hi, > > We would like to share with you our thoughts and plans towards a JSON API > for the JDK. > Please see the document below. > > - > > We have had the pleasure of using a clone of this API in some experiments > we are conducting with > ONNX and code reflection [1]. Using the API we were able to quickly write > code to ingest and convert > a JSON document representing ONNX operation schema into instances of > records modeling the schema > (see here [2]). > > The overall out-of-box experience with such a minimal "batteries included? > API has so far been positive. > > Thanks, > Paul. > > [1] https://openjdk.org/projects/babylon/ > [2] > https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 > > # Towards a JSON API for the JDK > > One of the most common requests for the JDK is an API for parsing and > generating > JSON. While JSON originated as a text-based serialization format for JSON > objects ("JSON" stands for "JavaScript Object Notation"), because of its > simple > and flexible syntax, it eventually found use outside the JavaScript > ecosystem as > a general data interchange format, such as framework configuration files > and web > service requests/response formats. > > While the JDK cannot, and should not, provide libraries for every > conceivable > file format or protocol, the JDK philosophy is one of "batteries included", > which is to say we should be able to write basic programs that use common > protocols such as HTTP, without having to appeal to third party libraries. > The Java ecosystem already has plenty of JSON libraries, so inclusion in > the JDK is largely meant to be a convenience, rather than needing to be > the "one > true" JSON library to meet the needs of all users. Users with specific > needs > are always free to select one of the existing third-party libraries. > > ## Goals and requirements > > Our primary goal is that the library be simple to use for parsing, > traversing, > and generating conformant JSON documents. Advanced features, such as data > binding or path-based traversal should be possible to implement as layered > features, but for simplicity are not included in the core API. We adopt a > goal > that the performance should be "good enough", but where performance > considerations conflict with simplicity and usability, we will choose in > favor > of the latter. > > ## API design approach > > The description of JSON at `https:://json.org` describes a JSON document > using > the familiar "railroad diagram": > ![image](https://www.json.org/img/value.png) > > This diagram describes an algebraic data type (a sum of products), which we > model directly with a set of Java interfaces: > > ``` > interface JsonValue { } > interface JsonArray extends JsonValue { List values(); } > interface JsonObject extends JsonValue { Map members(); > } > interface JsonNumber extends JsonValue { Number toNumber(); } > interface JsonString extends JsonValue { String value(); } > interface JsonBoolean extends JsonValue { boolean value(); } > interface JsonNull extends JsonValue { } > ``` > > These interfaces have (hidden) companion implementation classes that admit > greater flexibility of implementation than modeling them directly with > records would permit. > Further, these interfaces are unsealed. We compromise on the sealed sum of > products to enable > alternative implementations, for example to support alternative formats > that > encode the same information in a JSON document but in a more efficient > form than > text. > > The API has static methods for parsing strings into a `JsonValue`, > conversion to > and from purely untyped representations (lists and maps), and factory > methods > for building JSON documents. We apply composition consistently, e.g, a > JsonString has a string, a JsonObject has a map of string to JsonValue, as > opposed to extension for structural JSON values. > > It turns out that this simple API is almost all we need for traversal. It > gives > us an immutable representation of a document, and we can use pattern > matching to > answer the myriad questions that will come up (Does this object have key > X? Does > it map to a number? Is that number representable as an integer?) when going > from an untyped format like JSON to a more strongly typed domain model. > Given a simple document like: > > ``` > { > "name": "John?, > "age": 30 > } > ``` > > we can parse and traverse the document as follows: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject o > && o.members().get("name") instanceof JsonString s > && s.value() instanceof String name > && o.members().get("age") instanceof JsonNumber n > && n.toNumber() instanceof Long l && l instanceof int age) { > // use "name" and "age" > } > ``` > > Later, when the language acquires the ability to expose deconstruction > patterns > for arbitrary interfaces (similar to today's record patterns, see > > https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns > ), > this will be simplifiable to: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject(var members) > && members.get("name") instanceof JsonString(String name) > && members.get("age") instanceof JsonNumber(int age)) { > // use "name" and "age" > } > ``` > > So, overtime, as more pattern matching features are introduced we > anticipate > improved use of the API. This is a primary reason why the API is so > minimal. > Convenience methods we add today, such as a method that accesses a JSON > object component as say a JSON string or throws an exception, will become > redundant in the future. > > ## JSON numbers > > The specification of JSON number makes no explicit distinction between > integral > and decimal numbers, nor specifies limits on the size of those numbers. > This is a common source of interoperability issues when consuming JSON > documents. Generally users cannot always but often do assume JSON numbers > are > parsable, without loss of precision, to IEEE double-precision floating > point > numbers or 32-bit signed integers. > > In this respect the API provides three means to operate on the JSON number, > giving the user full control: > > 1. Underlying string representation can be obtained, if preserving > syntactic > details such as leading or trailing zeros is important. > 2. The string representation can be parsed to an instance of `BigDecimal`, > using > `toBigDecimal` if preserving decimal numbers is important. > 3. The string representation can be parsed into an instance of `Long`, > `Double`, > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this > method > depends on how the representation can be parsed, possibly losing > precision, > choosing a suitably convenient numeric type that can then be pattern > matched on. > > Primitive pattern matching will help as will further pattern matching > features > enabling the user to partially match. > > ## Prototype implementation > > The prototype implementation is currently located into the JDK sandbox > repository > under the `json` branch, see > here > https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json > The prototype API javadoc generated from the repository is also available > at > > https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html > > ### Testing and conformance > > The prototype implementation passes all conformance test cases but two, > available > on https://github.com/nst/JSONTestSuite. The two exceptions are the ones > which the > prototype specifically prohibits, i.e, duplicated names in JSON objects > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). > > ### Performance > > Our main focus so far has been on the API design and a functional > implementation. > Hence, there has been less focus on performance even though we know there > are a > number of performance enhancements we can make eventually. > We are reasonably happy with the current performance. The > implementation performs well when compared to other JSON implementations > parsing from string instances and traversing documents. > > An example of where we may choose simplicity and usability over performance > is the rejection of JSON documents containing objects that in turn contain > members > with duplicate names. That may increase the cost of parsing, but > simplifies the user > experience for the majority of cases since if we reasonably assume > JsonObjects are > map-like, what should the user do with such members, pick one the last > one? merge > the values? or reject? > > ## A JSON JEP? > > We plan to draft JEP when we are ready. Attentive readers will observe that > a JEP already exists, JEP 198: Light-Weight JSON API ( > https://openjdk.org/jeps/198). We will > either update this JEP, or withdraw it and draft a new one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat May 17 13:05:50 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 17 May 2025 13:05:50 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen wrote: >>> ```java >>> > char[] ca = new char[end - off]; >>> ``` >>> >>> Your code here has a memory allocation, which may cause slowdown >> >> This is exactly what I wanted to express with my posting. > >> > ```java >> > > char[] ca = new char[end - off]; >> > ``` >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Your code here has a memory allocation, which may cause slowdown >> >> This is exactly what I wanted to express with my posting. > > I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars. @wenshao Why did you remove UTF16::compress from your proposal? Wasn't it providing the expected benefit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2888375783 From duke at openjdk.org Sat May 17 14:39:01 2025 From: duke at openjdk.org (ExE Boss) Date: Sat, 17 May 2025 14:39:01 GMT Subject: RFR: 8350607: Consolidate MethodHandles::zero into MethodHandles::constant [v2] In-Reply-To: References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com> Message-ID: On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang wrote: >> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too. >> >> There may need to be additional intrinsic work for MH combinator lf bytecode generation. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > We no longer load DelegateMH as we no longer rebind Changes requested by ExE-Boss at github.com (no known OpenJDK username). src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893: > 4891: * @return a constant method handle of the given type, which returns a default value of the given return type > 4892: * @throws NullPointerException if the argument is null > 4893: * @see MethodHandles#primitiveZero `MethodHandles?.primitiveZero(?)` is?a?private internal?API. Suggestion: * @see MethodHandles#zero ------------- PR Review: https://git.openjdk.org/jdk/pull/23706#pullrequestreview-2848299662 PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r2094138280 From liach at openjdk.org Sat May 17 14:39:01 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 17 May 2025 14:39:01 GMT Subject: RFR: 8350607: Consolidate MethodHandles::zero into MethodHandles::constant [v2] In-Reply-To: References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com> Message-ID: On Sat, 17 May 2025 14:32:43 GMT, ExE Boss wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> We no longer load DelegateMH as we no longer rebind > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893: > >> 4891: * @return a constant method handle of the given type, which returns a default value of the given return type >> 4892: * @throws NullPointerException if the argument is null >> 4893: * @see MethodHandles#primitiveZero > > `MethodHandles?.primitiveZero(?)` is?a?private internal?API. > Suggestion: > > * @see MethodHandles#zero There's a general rfe for checking inaccessible links. Don't recall why thisv was even changed, most likely ide being too smart. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r2094138728 From swen at openjdk.org Sat May 17 14:58:53 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 17 May 2025 14:58:53 GMT Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen wrote: >>> ```java >>> > char[] ca = new char[end - off]; >>> ``` >>> >>> Your code here has a memory allocation, which may cause slowdown >> >> This is exactly what I wanted to express with my posting. > >> > ```java >> > > char[] ca = new char[end - off]; >> > ``` >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Your code here has a memory allocation, which may cause slowdown >> >> This is exactly what I wanted to express with my posting. > > I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars. > @wenshao Why did you remove UTF16::compress from your proposal? Wasn't it providing the expected benefit? StringUTF16::compress has been added in PR #24967 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2888440484 From markus at headcrashing.eu Sat May 17 15:01:00 2025 From: markus at headcrashing.eu (Markus KARG) Date: Sat, 17 May 2025 17:01:00 +0200 Subject: RFC: 8357183: Improving efficiency of Writer::append(CharSequence) and Writer::append(CharSequence, int, int) / Sub Task of 8356679: Using CharSequence::getChars internally In-Reply-To: <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> Message-ID: <36b5f579-3d45-48ee-948c-a73507ca6764@headcrashing.eu> Roger, thank you for your comments. Following your advice I have splitted the larger work of JDK-8356679 into sub tasks. I would like to start with a first PR implementing the *foundational* work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For convenience, attached below is a copy of the description. Comments Welcome! If everybody is fine with this, I would be happy to get some +1 to publish the PR for JDK-8357183! -Markus This sub task of JDK-8356679 proposes implementation-only changes to java.io.Writer. No API is changed. Implementation behavior is slightly changed w.r.t to self-calls to non-private methods. The target is to make the Writer::append(CharSequence) and Writer::append(CharSequence, int, int) methods *in the non-String* case be as efficient as they are already *in the String* case. This is achived by now handling CharSequence in *the exact same* optimized way as String was specifically handled before. This generalization of the previously String-specific optimization is possible since Java 25, thanks to the new CharSequence::getChars(int, int, char[], int) bulk-read method. Prior to the proposed change, the code was unefficient, as ontop of what the String-case did, the text content of other CharSequences (like StringBuilder and CharBuffer) had to be copied *once or multiply*, before it was finally processed *as* a String. The changes in detail are: * Extract the original implementation of Writer::write(String, int, int) to become a newly introduced, internal method Writer::implWrite(CharSequence, int, int). This allows making use of that exact original implementation by other methods, particularly CharSequence::append, but potentially also sub classes in the same package (for subsequent enhancement of specific Writers). * Writer::append(CharSequence) prevents the previously implied creation of an intermediate String representation in the non-String case (which implied creating another temporary object on the heap, and duplicating full text content), ontop of what the String case did * Writer::append(CharSequence, int, int), in addition to the optimization of the single-arg case, also prevents the previously implied creation of a sub sequence (which always meant to create another temporary object on the heap, and in many cases meant to duplicate partial text content). * As a benefit, the JavaDocs of these methods can be simplified thanks to the reduced number of self-calls. While this changes the internal behavior slightly, it is finally clarifying that these JavaDoc sections were originally meant as explanatory notes what *the default code* does, but not as as mandatory specs what *subclasses* have to do. This work is foundational to subsequent enhancements of specific Writers, as the new implWrite(CharSequence, int, int) method is to be called by them *instead* of the previously called write(String, int, int) method, to allow for the same efficiency optimiziation now found in the new default code. Due to that, no other Writers are changed in this first step; these Writers will follow in subsequent JBS / PRs. Am 14.05.2025 um 15:57 schrieb Roger Riggs: > Hi Markus, > > Starting out with the common case is a good idea for the first PR. > > I much prefer a PR with a single goal and that comes to a conclusion > and does not add new features or changes after the PR is submitted. > I tend to lose interest in PRs with lots of churn, it means I have to > re-review the bulk of it when there is a change and may wait days to > let it settle down before coming back to it. > > I tend to think the PR was not really ready to be reviewed if simple > issues and corrections have to be made frequently. > Do your own checking for typos and copyrights and simple refactoring > before opening the PR. > Quality before quantity or speed. > > I'm fine with separate Jira issues that clearly delineate a specific > scope and goal. > > The title of this issue (8356679) doesn't identify the real goal. > It seems to be to improve performance or memory usage, not just to use > a new API. > > These are my personal opinions about contributions and process. > > Regards, Roger > > > On 5/14/25 6:48 AM, Markus KARG wrote: >> Many of the modified classes derive from a common super class and >> share one needed common change (which is one of the points which are >> easy to see once you see all of those classes in a single PR, but >> hard to explain in plaint-text pre-PR mailing list threads), so at >> least those need to be discussed *together*. But to spare JBS and >> PRs, I can open the PR with just the first set of changes, and once >> we agree that this set is fine, I can push the next commit *in the >> same PR*. Otherwise we would need endless JBS, mailing list threads, >> and PRs, just to fixe a dozen internal code lines. >> >> Having said that, does the current state of this thread count as >> "reached common agreement to file a PR" or do I still have to wait >> until more people chime in? >> >> -Markus >> >> >> Am 13.05.2025 um 15:10 schrieb Roger Riggs: >>> Hi Markus, >>> >>> A main point was to avoid trying to do everything at once. >>> The PR comments become hard to follow and intermingled and it takes >>> longer to get agreement because of the thrash in the PR. >>> >>> Roger >>> >>> On 5/13/25 5:05 AM, Markus KARG wrote: >>>> Thank you, Roger. >>>> >>>> Actually the method helps in the "toString()" variants, too, as in >>>> some places we could *get rid* of "toString()" (which is more work >>>> than "just" a buffer due to the added compression complexity). >>>> >>>> In fact, I already took the time to rewrite *all* of them while >>>> waiting for the approval of this list posting. In *all* cases >>>> *less* buffering / copying is needed, and *less* "toString()" >>>> conversion (which is a copy under the hood) is needed. So if I >>>> would be allowed to show the code as a PR, it would be much easier >>>> to explain and discuss. >>>> >>>> A PR is the best place to discuss "how to code would change". In >>>> the worst case, let's drop it if we see that it is actually a bad >>>> thing. >>>> >>>> -Markus >>>> >>>> >>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs: >>>>> Hi Markus, >>>>> >>>>> On the surface, its looks constructive. >>>>> I suspect that many of these cases will turn into discussions >>>>> about the right/best/better way to buffer the characters. >>>>> The getChars method only helps when extracting to a char array, >>>>> many of the current implementations create strings as the >>>>> intermediary. The advantage of the 1 character at a time technique >>>>> is not needing a (separated allocated) buffer. >>>>> Consider taking a few at a time before launching into the whole set. >>>>> >>>>> $.02, Roger >>>>> >>>>> On 5/11/25 2:45 AM, Markus KARG wrote: >>>>>> Dear Core Libs Team, >>>>>> >>>>>> I am hereby requesting comments on JDK-8356679. >>>>>> >>>>>> I would like to invest some time and set up a PR implementing >>>>>> Chen Liangs's proposal laid out in >>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your >>>>>> convenience, the text of that JBS is copied below. According to >>>>>> the Developer's Guide I do need to get broad agreement BEFORE >>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show >>>>>> consent, so I may file a PR. >>>>>> >>>>>> Thanks >>>>>> -Markus >>>>>> >>>>>> >>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >>>>>> >>>>>> Recently OpenJDK adopted the new method >>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in >>>>>> Java 25. As a bulk reader method, it allows potentially improved >>>>>> efficiency over the previously available char-by-char reader >>>>>> method CharSequence::charAt(int). >>>>>> >>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing >>>>>> list to use the new method within the internal source code of >>>>>> OpenJDK for the implementation of Appendables (see >>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >>>>>> The idea behind this is that the implementations might be more >>>>>> efficient then. >>>>>> >>>>>> A quick analysis of the OpenJDK source code identified (at least) >>>>>> the following classes which could potentially run more efficient >>>>>> when using CharSequence::getChars internally, thanks to bulk >>>>>> reading and / or prevention of internal copies / toString() >>>>>> conversions: >>>>>> * java.io.Writer >>>>>> * java.io.StringWriter >>>>>> * java.io.PrintWriter >>>>>> * java.io.BufferedWriter >>>>>> * java.io.CharArrayWriter >>>>>> * java.io.FileWriter >>>>>> * java.io.OutputStreamWriter >>>>>> * sun.nio.cs.StreamEncoder >>>>>> * java.io.PrintStream >>>>>> * java.nio.CharBuffer >>>>>> >>>>>> In the sense of "eat your own dog food", it makes sense to >>>>>> implement Chen's idea in (at least) those classes. Possibly more >>>>>> classes could get identified when taking a deeper look. Besides >>>>>> the potential efficiency improvements, it would be a good show >>>>>> case for the usage of the new API. >>>>>> >>>>>> The risk of this change should be low, as test coverage exists, >>>>>> and as the intended changes are solely internal to the >>>>>> implementation. No API will get changed. In some cases the >>>>>> JavaDocs will get slightly adapted where it currently exposes the >>>>>> actual implementation (to not lie in future). >>>>>> >>>>> >>> > From duke at openjdk.org Sat May 17 15:07:05 2025 From: duke at openjdk.org (Markus KARG) Date: Sat, 17 May 2025 15:07:05 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v9] In-Reply-To: References: Message-ID: <9NTR14nhT6i_PCj6UT762FRW1ozfIZgTJ7O_Nd6g-is=.71a41cd0-036f-44cc-b984-a3af9c2599c6@github.com> On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs wrote: >> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. >> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. >> Support methods are static, designed to pass all values as arguments and return a value. >> >> The value byte array is reallocated under 3 conditions: >> - Increasing the capacity with the same encoder >> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16 >> - Inflation with the same capacity >> >> Added StressSBTest to exercise public instance methods of StringBuilder. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed extraneous "the" src/java.base/share/classes/java/lang/StringUTF16.java line 1535: > 1533: checkBoundsBeginEnd(i, end, value); > 1534: putChar(value, i, c1); > 1535: putChar(value, i + 1, c2); Can someone please shed some light on this change: What is the benefit of `i + constant` over `i++`? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2094144854 From liach at openjdk.org Sat May 17 17:09:59 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 17 May 2025 17:09:59 GMT Subject: RFR: 8351443: Improve robustness of StringBuilder [v9] In-Reply-To: <9NTR14nhT6i_PCj6UT762FRW1ozfIZgTJ7O_Nd6g-is=.71a41cd0-036f-44cc-b984-a3af9c2599c6@github.com> References: <9NTR14nhT6i_PCj6UT762FRW1ozfIZgTJ7O_Nd6g-is=.71a41cd0-036f-44cc-b984-a3af9c2599c6@github.com> Message-ID: On Sat, 17 May 2025 15:04:21 GMT, Markus KARG wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed extraneous "the" > > src/java.base/share/classes/java/lang/StringUTF16.java line 1535: > >> 1533: checkBoundsBeginEnd(i, end, value); >> 1534: putChar(value, i, c1); >> 1535: putChar(value, i + 1, c2); > > Can someone please shed some light on this change: What is the benefit of `i + constant` over `i++`? ? i++ generates excessive store bytecodes compared to +1, +2, ... and the result bytecode size is larger, which is harmful to jit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2094169027 From cay.horstmann at gmail.com Sun May 18 05:55:12 2025 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Sun, 18 May 2025 07:55:12 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Message-ID: <52514642-e172-4096-a616-a2c9a9787552@gmail.com> +1 for having a JSON battery included with the JDK. And for "Our primary goal is that the library be simple to use for parsing, traversing, and generating conformant JSON documents." Generating JSON could be easier. Why not convenience methods Json.newObject and Json.newArray like in https://github.com/arkanovicz/essential-json? Parsing with instanceof will work, but is obviously painful today, as your example shows. The simplification with deconstruction patterns is not impressive either. JsonValue doc = Json.parse(inputString); if (doc instanceof JsonObject(var members) && members.get("name") instanceof JsonString(String name) && members.get("age") instanceof JsonNumber(int age)) { // use "name" and "age" } else throw new NoSuchArgumentException(); vs. Jackson String name = doc.get("name").asText(); int age = doc.get("age").asInt(); ... If only there was some deconstruction magic that approximates the JavaScript code const doc = { name: "John", age: 30 } const { name, age } = doc What about editing documents? With Jackson, you can mutate objects and arrays. I see the appeal of immutability, but then there needs to be a convenient transform API. Right now, making John one year older is not pretty: var nextYearDoc = switch (doc) { case JsonObject(var members) if members.get("name") instanceof JsonString(String name) && members.get("age") instanceof JsonNumber(int age)) -> Json.fromUntyped(Map.of("name", name, "age", age + 1)); default -> throw new NoSuchArgumentException(); } And it gets worse if John is nested more deeply in a document. I have worked a lot with immutable XML in Scala. One minimally needs a mechanism for recursive rewriting with a node replacement function. I am not aware of an existing library that attempts this in Java for JSON. I am sure it can be done, but it may not be trivial to do such an API well. Cheers, Cay PS. Trying to create and show the youthful John gives me grief right now: Json.fromUntyped(Map.of("name", "John", "age", 30)).toString() | Exception java.lang.NullPointerException: Cannot read the array length because "value" is null | at String.rangeCheck (String.java:307) | at String. (String.java:303) | at JsonNumberImpl.toString (JsonNumberImpl.java:105) | at JsonObjectImpl.toString (JsonObjectImpl.java:56) | at (#23:1) The JsonNumberImpl.toString method needs to handle the case that it was constructed from a Number. Il 15/05/25 22:30, Paul Sandoz ha scritto: > Hi, > > We would like to share with you our thoughts and plans towards a JSON API for the JDK. > Please see the document below. > > - > > We have had the pleasure of using a clone of this API in some experiments we are conducting with > ONNX and code reflection [1]. Using the API we were able to quickly write code to ingest and convert > a JSON document representing ONNX operation schema into instances of records modeling the schema > (see here [2]). > > The overall out-of-box experience with such a minimal "batteries included? API has so far been positive. > > Thanks, > Paul. > > [1] https://openjdk.org/projects/babylon/ > [2] https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 > > # Towards a JSON API for the JDK > > One of the most common requests for the JDK is an API for parsing and generating > JSON. While JSON originated as a text-based serialization format for JSON > objects ("JSON" stands for "JavaScript Object Notation"), because of its simple > and flexible syntax, it eventually found use outside the JavaScript ecosystem as > a general data interchange format, such as framework configuration files and web > service requests/response formats. > > While the JDK cannot, and should not, provide libraries for every conceivable > file format or protocol, the JDK philosophy is one of "batteries included", > which is to say we should be able to write basic programs that use common > protocols such as HTTP, without having to appeal to third party libraries. > The Java ecosystem already has plenty of JSON libraries, so inclusion in > the JDK is largely meant to be a convenience, rather than needing to be the "one > true" JSON library to meet the needs of all users. Users with specific needs > are always free to select one of the existing third-party libraries. > > ## Goals and requirements > > Our primary goal is that the library be simple to use for parsing, traversing, > and generating conformant JSON documents. Advanced features, such as data > binding or path-based traversal should be possible to implement as layered > features, but for simplicity are not included in the core API. We adopt a goal > that the performance should be "good enough", but where performance > considerations conflict with simplicity and usability, we will choose in favor > of the latter. > > ## API design approach > > The description of JSON at `https:://json.org` describes a JSON document using > the familiar "railroad diagram": > ![image](https://www.json.org/img/value.png) > > This diagram describes an algebraic data type (a sum of products), which we > model directly with a set of Java interfaces: > > ``` > interface JsonValue { } > interface JsonArray extends JsonValue { List values(); } > interface JsonObject extends JsonValue { Map members(); } > interface JsonNumber extends JsonValue { Number toNumber(); } > interface JsonString extends JsonValue { String value(); } > interface JsonBoolean extends JsonValue { boolean value(); } > interface JsonNull extends JsonValue { } > ``` > > These interfaces have (hidden) companion implementation classes that admit > greater flexibility of implementation than modeling them directly with records would permit. > Further, these interfaces are unsealed. We compromise on the sealed sum of products to enable > alternative implementations, for example to support alternative formats that > encode the same information in a JSON document but in a more efficient form than > text. > > The API has static methods for parsing strings into a `JsonValue`, conversion to > and from purely untyped representations (lists and maps), and factory methods > for building JSON documents. We apply composition consistently, e.g, a > JsonString has a string, a JsonObject has a map of string to JsonValue, as > opposed to extension for structural JSON values. > > It turns out that this simple API is almost all we need for traversal. It gives > us an immutable representation of a document, and we can use pattern matching to > answer the myriad questions that will come up (Does this object have key X? Does > it map to a number? Is that number representable as an integer?) when going > from an untyped format like JSON to a more strongly typed domain model. > Given a simple document like: > > ``` > { > "name": "John?, > "age": 30 > } > ``` > > we can parse and traverse the document as follows: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject o > && o.members().get("name") instanceof JsonString s > && s.value() instanceof String name > && o.members().get("age") instanceof JsonNumber n > && n.toNumber() instanceof Long l && l instanceof int age) { > // use "name" and "age" > } > ``` > > Later, when the language acquires the ability to expose deconstruction patterns > for arbitrary interfaces (similar to today's record patterns, see > https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), > this will be simplifiable to: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject(var members) > && members.get("name") instanceof JsonString(String name) > && members.get("age") instanceof JsonNumber(int age)) { > // use "name" and "age" > } > ``` > > So, overtime, as more pattern matching features are introduced we anticipate > improved use of the API. This is a primary reason why the API is so minimal. > Convenience methods we add today, such as a method that accesses a JSON > object component as say a JSON string or throws an exception, will become > redundant in the future. > > ## JSON numbers > > The specification of JSON number makes no explicit distinction between integral > and decimal numbers, nor specifies limits on the size of those numbers. > This is a common source of interoperability issues when consuming JSON > documents. Generally users cannot always but often do assume JSON numbers are > parsable, without loss of precision, to IEEE double-precision floating point > numbers or 32-bit signed integers. > > In this respect the API provides three means to operate on the JSON number, > giving the user full control: > > 1. Underlying string representation can be obtained, if preserving syntactic > details such as leading or trailing zeros is important. > 2. The string representation can be parsed to an instance of `BigDecimal`, using > `toBigDecimal` if preserving decimal numbers is important. > 3. The string representation can be parsed into an instance of `Long`, `Double`, > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method > depends on how the representation can be parsed, possibly losing precision, > choosing a suitably convenient numeric type that can then be pattern > matched on. > > Primitive pattern matching will help as will further pattern matching features > enabling the user to partially match. > > ## Prototype implementation > > The prototype implementation is currently located into the JDK sandbox > repository > under the `json` branch, see > here https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json > The prototype API javadoc generated from the repository is also available at > https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html > > ### Testing and conformance > > The prototype implementation passes all conformance test cases but two, available > on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which the > prototype specifically prohibits, i.e, duplicated names in JSON objects > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). > > ### Performance > > Our main focus so far has been on the API design and a functional implementation. > Hence, there has been less focus on performance even though we know there are a > number of performance enhancements we can make eventually. > We are reasonably happy with the current performance. The > implementation performs well when compared to other JSON implementations > parsing from string instances and traversing documents. > > An example of where we may choose simplicity and usability over performance > is the rejection of JSON documents containing objects that in turn contain members > with duplicate names. That may increase the cost of parsing, but simplifies the user > experience for the majority of cases since if we reasonably assume JsonObjects are > map-like, what should the user do with such members, pick one the last one? merge > the values? or reject? > > ## A JSON JEP? > > We plan to draft JEP when we are ready. Attentive readers will observe that > a JEP already exists, JEP 198: Light-Weight JSON API (https://openjdk.org/jeps/198). We will > either update this JEP, or withdraw it and draft a new one. -- Cay S. Horstmann | https://horstmann.com From kbarrett at openjdk.org Sun May 18 11:41:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 18 May 2025 11:41:59 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner Message-ID: This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to use java.lang.ref.Cleaner. This change is algorithmically similar to the two previous versions: JDK-6857566 and JDK-8156500 (current mainline). The critical function is Bits::reserveMemory(). For both of those versions and this change, a thread calls that function and tries to reserve some space. If it fails, then it keeps trying until all cleaners deactivated (cleared) by prior GCs have been cleaned. If reservation still fails, then it invokes the GC to try to deactivate more cleaners for cleaning. After that GC it keeps trying the reservation and waiting for cleaning, with sleeps to avoid a spin loop, eventually either succeeding or giving up and throwing OOME. Retaining that algorithmic approach is one of the goals of this change, since it has been successfully in use since JDK 9 (and was originally developed and extensively tested in JDK 8). The key to this approach is having a way to determine that deactivated cleaners have been cleaned. JDK-6857566 accomplished this by having waiting threads help the reference processor until there was no available work. JDK-8156500 waits for the reference processor to quiesce, relying on its immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way to do this, which is why this change rolls its own Cleaner-like mechanism from the underlying primitives. Like JDK-6857566, this change has waiting threads help with cleaning references. This was a potentially undesirable feature of JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. (Though by the time of JDK-6857566 the cleaners were only used by DBB, and became internal-only somewhere around that time as well.) That's not a concern here, as the cleaners involved are only from DBB, and we know what they look like. As noted in the discussion of JDK-6857566, it's good to have DBB cleaning being done off the reference processing thread, as it may be expensive and slow down enqueuing other pending references. JDK-6857566 only did some of that, and JDK-8156500 lost that feature. This change moves all of the DBB cleaning off of the reference processing thread. (So does PR 22165.) Neither JDK-6857566 nor this change are completely precise. For both, a thread may find there is no available work while other threads have work in progress. Making this change more precise seems to cost complexity and performance. JDK-8156500 is precise in this respect, so we're losing that. But this imprecision wasn't known to cause problems for JDK-6857566, and there hasn't been any evidence of problems with this change either. During the development of JDK-6857566 it was noticed that parallel cleaning didn't seem to have much (if any) performance benefit. That seems to be true for this change as well. PR 22165 uses java.lang.ref.Cleaner to manage cleaning. That class doesn't provide a good way to detect progress toward or completion of cleaning of deactivated cleaners from prior GCs. So PR 22165 uses a somewhat clumsy and unreliable mechanism (the canaries) to try to do that. A proposal for such functionality was discussed (in PR 22165) but deemed (probably rightly so) too intrusive. An unpublished alternative was less intrusive, but still might raise questions. The change being proposed here avoids changing or using that class, and performs at least as well. Another issue with PR 22165 is that if we are indeed out of memory and on our way to OOME, each allocating thread may come up against the slow path lock in Bits::reserveMemory, and in turn perform 9 full GCs and then OOME. That seems kind of pathological. For JDK-6857566, JDK-8156500, and this change, an allocating thread only performs 1 full GC before OOME. One issue with this change is that it incorporates a near-copy of the CleanableList class from java.lang.ref.Cleaner. Possible future work would merge the two into a common utility. There's another potential client for this: java.desktop/share/classes/sun/java2d/Disposer.java. I tried using a hashtable for this change (as with Disposer), but the CleanableList performed significantly better. A well-known issue with all of these approaches is -XX:+DisableExplicitGC. If used, then the GCs to request reference processing don't happen. That will likely lead to OOME, though the sleeps might provide an opportunity for automatic GCs to occur, maybe sometimes dodging OOME that way. https://mail.openjdk.org/pipermail/core-libs-dev/2013-October/021547.html Thread for discussion of development of JDK-6857566 Testing: mach5 tier1-6 Many runs of new tests micro/org/openjdk/bench/java/nio/DirectByteBuffer{GC,Churn} (thanks for those @shipilev), and jdk/java/nio/Buffer/DirectByteBufferAlloc for various versions of this change. The test java/nio/Buffer/DirectByteBufferAlloc.java can be run explicitly as a benchmark. But the arguments suggested in that file cause the measurements to be dominated by full GC times, swamping any other differences. Increasing the value of `XX:MaxDirectMemorySize` from 128m to 1024m provides a more useful comparison. Result of running that test with `-XX:MaxDirectMemorySize=1024m`, with other options as suggested in the file, and comparing the periodic per thread `ms/allocation` outputs, produces results like this: | | this change | PR 22165 | baseline | | ------ | ------------ | -------- | -------- | | avg | 0.76165 | 1.00368 | 1.02719 | | stddev | 0.12396 | 0.18361 | 0.27210 | | min | 0.54 | 0.6 | 0.59 | | max | 1.54 | 2.13 | 2.39 | ------------- Commit messages: - copyrights - remove java.nio use of jdk.internal.ref.Cleaner - add micros from Shipilev Changes: https://git.openjdk.org/jdk/pull/25289/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344332 Stats: 499 lines in 9 files changed: 450 ins; 22 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/25289.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289 PR: https://git.openjdk.org/jdk/pull/25289 From alanb at openjdk.org Sun May 18 12:13:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 18 May 2025 12:13:59 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett wrote: > This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage > native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences > and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to > use java.lang.ref.Cleaner. > > This change is algorithmically similar to the two previous versions: > JDK-6857566 and JDK-8156500 (current mainline). The critical function is > Bits::reserveMemory(). For both of those versions and this change, a thread > calls that function and tries to reserve some space. If it fails, then it > keeps trying until all cleaners deactivated (cleared) by prior GCs have been > cleaned. If reservation still fails, then it invokes the GC to try to > deactivate more cleaners for cleaning. After that GC it keeps trying the > reservation and waiting for cleaning, with sleeps to avoid a spin loop, > eventually either succeeding or giving up and throwing OOME. > > Retaining that algorithmic approach is one of the goals of this change, since > it has been successfully in use since JDK 9 (and was originally developed and > extensively tested in JDK 8). > > The key to this approach is having a way to determine that deactivated > cleaners have been cleaned. JDK-6857566 accomplished this by having waiting > threads help the reference processor until there was no available work. > JDK-8156500 waits for the reference processor to quiesce, relying on its > immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way > to do this, which is why this change rolls its own Cleaner-like mechanism from > the underlying primitives. Like JDK-6857566, this change has waiting threads > help with cleaning references. This was a potentially undesirable feature of > JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. > (Though by the time of JDK-6857566 the cleaners were only used by DBB, and > became internal-only somewhere around that time as well.) That's not a concern > here, as the cleaners involved are only from DBB, and we know what they look > like. > > As noted in the discussion of JDK-6857566, it's good to have DBB cleaning > being done off the reference processing thread, as it may be expensive and > slow down enqueuing other pending references. JDK-6857566 only did some of > that, and JDK-8156500 lost that feature. This change moves all of the DBB > cleaning off of the reference processing thread. (So does PR 22165.) > > Neither JDK-6857566 nor this change are completely precise. For both, a thread > may find there is no available work whil... src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26: > 24: */ > 25: > 26: package jdk.internal.nio; The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2094505609 From markus at headcrashing.eu Sun May 18 15:09:43 2025 From: markus at headcrashing.eu (Markus KARG) Date: Sun, 18 May 2025 17:09:43 +0200 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> Message-ID: <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> Roger, thank you for your comments. Following your advice I have splitted the larger work of JDK-8356679 into sub tasks. I would like to start with a first PR implementing the *foundational* work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For convenience, attached below is a copy of the description. Comments Welcome! If everybody is fine with this, I would be happy to get some +1 to publish the PR for JDK-8357183! Am 14.05.2025 um 15:57 schrieb Roger Riggs: > Hi Markus, > > Starting out with the common case is a good idea for the first PR. > > I much prefer a PR with a single goal and that comes to a conclusion > and does not add new features or changes after the PR is submitted. > I tend to lose interest in PRs with lots of churn, it means I have to > re-review the bulk of it when there is a change and may wait days to > let it settle down before coming back to it. > > I tend to think the PR was not really ready to be reviewed if simple > issues and corrections have to be made frequently. > Do your own checking for typos and copyrights and simple refactoring > before opening the PR. > Quality before quantity or speed. > > I'm fine with separate Jira issues that clearly delineate a specific > scope and goal. > > The title of this issue (8356679) doesn't identify the real goal. > It seems to be to improve performance or memory usage, not just to use > a new API. > > These are my personal opinions about contributions and process. > > Regards, Roger > > > On 5/14/25 6:48 AM, Markus KARG wrote: >> Many of the modified classes derive from a common super class and >> share one needed common change (which is one of the points which are >> easy to see once you see all of those classes in a single PR, but >> hard to explain in plaint-text pre-PR mailing list threads), so at >> least those need to be discussed *together*. But to spare JBS and >> PRs, I can open the PR with just the first set of changes, and once >> we agree that this set is fine, I can push the next commit *in the >> same PR*. Otherwise we would need endless JBS, mailing list threads, >> and PRs, just to fixe a dozen internal code lines. >> >> Having said that, does the current state of this thread count as >> "reached common agreement to file a PR" or do I still have to wait >> until more people chime in? >> >> -Markus >> >> >> Am 13.05.2025 um 15:10 schrieb Roger Riggs: >>> Hi Markus, >>> >>> A main point was to avoid trying to do everything at once. >>> The PR comments become hard to follow and intermingled and it takes >>> longer to get agreement because of the thrash in the PR. >>> >>> Roger >>> >>> On 5/13/25 5:05 AM, Markus KARG wrote: >>>> Thank you, Roger. >>>> >>>> Actually the method helps in the "toString()" variants, too, as in >>>> some places we could *get rid* of "toString()" (which is more work >>>> than "just" a buffer due to the added compression complexity). >>>> >>>> In fact, I already took the time to rewrite *all* of them while >>>> waiting for the approval of this list posting. In *all* cases >>>> *less* buffering / copying is needed, and *less* "toString()" >>>> conversion (which is a copy under the hood) is needed. So if I >>>> would be allowed to show the code as a PR, it would be much easier >>>> to explain and discuss. >>>> >>>> A PR is the best place to discuss "how to code would change". In >>>> the worst case, let's drop it if we see that it is actually a bad >>>> thing. >>>> >>>> -Markus >>>> >>>> >>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs: >>>>> Hi Markus, >>>>> >>>>> On the surface, its looks constructive. >>>>> I suspect that many of these cases will turn into discussions >>>>> about the right/best/better way to buffer the characters. >>>>> The getChars method only helps when extracting to a char array, >>>>> many of the current implementations create strings as the >>>>> intermediary. The advantage of the 1 character at a time technique >>>>> is not needing a (separated allocated) buffer. >>>>> Consider taking a few at a time before launching into the whole set. >>>>> >>>>> $.02, Roger >>>>> >>>>> On 5/11/25 2:45 AM, Markus KARG wrote: >>>>>> Dear Core Libs Team, >>>>>> >>>>>> I am hereby requesting comments on JDK-8356679. >>>>>> >>>>>> I would like to invest some time and set up a PR implementing >>>>>> Chen Liangs's proposal laid out in >>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your >>>>>> convenience, the text of that JBS is copied below. According to >>>>>> the Developer's Guide I do need to get broad agreement BEFORE >>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show >>>>>> consent, so I may file a PR. >>>>>> >>>>>> Thanks >>>>>> -Markus >>>>>> >>>>>> >>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >>>>>> >>>>>> Recently OpenJDK adopted the new method >>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in >>>>>> Java 25. As a bulk reader method, it allows potentially improved >>>>>> efficiency over the previously available char-by-char reader >>>>>> method CharSequence::charAt(int). >>>>>> >>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing >>>>>> list to use the new method within the internal source code of >>>>>> OpenJDK for the implementation of Appendables (see >>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >>>>>> The idea behind this is that the implementations might be more >>>>>> efficient then. >>>>>> >>>>>> A quick analysis of the OpenJDK source code identified (at least) >>>>>> the following classes which could potentially run more efficient >>>>>> when using CharSequence::getChars internally, thanks to bulk >>>>>> reading and / or prevention of internal copies / toString() >>>>>> conversions: >>>>>> * java.io.Writer >>>>>> * java.io.StringWriter >>>>>> * java.io.PrintWriter >>>>>> * java.io.BufferedWriter >>>>>> * java.io.CharArrayWriter >>>>>> * java.io.FileWriter >>>>>> * java.io.OutputStreamWriter >>>>>> * sun.nio.cs.StreamEncoder >>>>>> * java.io.PrintStream >>>>>> * java.nio.CharBuffer >>>>>> >>>>>> In the sense of "eat your own dog food", it makes sense to >>>>>> implement Chen's idea in (at least) those classes. Possibly more >>>>>> classes could get identified when taking a deeper look. Besides >>>>>> the potential efficiency improvements, it would be a good show >>>>>> case for the usage of the new API. >>>>>> >>>>>> The risk of this change should be low, as test coverage exists, >>>>>> and as the intended changes are solely internal to the >>>>>> implementation. No API will get changed. In some cases the >>>>>> JavaDocs will get slightly adapted where it currently exposes the >>>>>> actual implementation (to not lie in future). >>>>>> >>>>> >>> > From markus at headcrashing.eu Sun May 18 15:12:05 2025 From: markus at headcrashing.eu (Markus KARG) Date: Sun, 18 May 2025 17:12:05 +0200 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> Message-ID: <01ed672c-f974-48ae-8f50-7d2bb9e1e8f5@headcrashing.eu> Sorry, the posting below was cross-posted by accident. -Markus Am 18.05.2025 um 17:09 schrieb Markus KARG: > Roger, > > thank you for your comments. > > Following your advice I have splitted the larger work of JDK-8356679 > into sub tasks. > > I would like to start with a first PR implementing the *foundational* > work, i. e. optimizing Writer::append for efficiency (JDK-8357183). > For convenience, attached below is a copy of the description. > > Comments Welcome! > > If everybody is fine with this, I would be happy to get some +1 to > publish the PR for JDK-8357183! > > Am 14.05.2025 um 15:57 schrieb Roger Riggs: >> Hi Markus, >> >> Starting out with the common case is a good idea for the first PR. >> >> I much prefer a PR with a single goal and that comes to a conclusion >> and does not add new features or changes after the PR is submitted. >> I tend to lose interest in PRs with lots of churn, it means I have to >> re-review the bulk of it when there is a change and may wait days to >> let it settle down before coming back to it. >> >> I tend to think the PR was not really ready to be reviewed if simple >> issues and corrections have to be made frequently. >> Do your own checking for typos and copyrights and simple refactoring >> before opening the PR. >> Quality before quantity or speed. >> >> I'm fine with separate Jira issues that clearly delineate a specific >> scope and goal. >> >> The title of this issue (8356679) doesn't identify the real goal. >> It seems to be to improve performance or memory usage, not just to >> use a new API. >> >> These are my personal opinions about contributions and process. >> >> Regards, Roger >> >> >> On 5/14/25 6:48 AM, Markus KARG wrote: >>> Many of the modified classes derive from a common super class and >>> share one needed common change (which is one of the points which are >>> easy to see once you see all of those classes in a single PR, but >>> hard to explain in plaint-text pre-PR mailing list threads), so at >>> least those need to be discussed *together*. But to spare JBS and >>> PRs, I can open the PR with just the first set of changes, and once >>> we agree that this set is fine, I can push the next commit *in the >>> same PR*. Otherwise we would need endless JBS, mailing list threads, >>> and PRs, just to fixe a dozen internal code lines. >>> >>> Having said that, does the current state of this thread count as >>> "reached common agreement to file a PR" or do I still have to wait >>> until more people chime in? >>> >>> -Markus >>> >>> >>> Am 13.05.2025 um 15:10 schrieb Roger Riggs: >>>> Hi Markus, >>>> >>>> A main point was to avoid trying to do everything at once. >>>> The PR comments become hard to follow and intermingled and it takes >>>> longer to get agreement because of the thrash in the PR. >>>> >>>> Roger >>>> >>>> On 5/13/25 5:05 AM, Markus KARG wrote: >>>>> Thank you, Roger. >>>>> >>>>> Actually the method helps in the "toString()" variants, too, as in >>>>> some places we could *get rid* of "toString()" (which is more work >>>>> than "just" a buffer due to the added compression complexity). >>>>> >>>>> In fact, I already took the time to rewrite *all* of them while >>>>> waiting for the approval of this list posting. In *all* cases >>>>> *less* buffering / copying is needed, and *less* "toString()" >>>>> conversion (which is a copy under the hood) is needed. So if I >>>>> would be allowed to show the code as a PR, it would be much easier >>>>> to explain and discuss. >>>>> >>>>> A PR is the best place to discuss "how to code would change". In >>>>> the worst case, let's drop it if we see that it is actually a bad >>>>> thing. >>>>> >>>>> -Markus >>>>> >>>>> >>>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs: >>>>>> Hi Markus, >>>>>> >>>>>> On the surface, its looks constructive. >>>>>> I suspect that many of these cases will turn into discussions >>>>>> about the right/best/better way to buffer the characters. >>>>>> The getChars method only helps when extracting to a char array, >>>>>> many of the current implementations create strings as the >>>>>> intermediary. The advantage of the 1 character at a time >>>>>> technique is not needing a (separated allocated) buffer. >>>>>> Consider taking a few at a time before launching into the whole set. >>>>>> >>>>>> $.02, Roger >>>>>> >>>>>> On 5/11/25 2:45 AM, Markus KARG wrote: >>>>>>> Dear Core Libs Team, >>>>>>> >>>>>>> I am hereby requesting comments on JDK-8356679. >>>>>>> >>>>>>> I would like to invest some time and set up a PR implementing >>>>>>> Chen Liangs's proposal laid out in >>>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your >>>>>>> convenience, the text of that JBS is copied below. According to >>>>>>> the Developer's Guide I do need to get broad agreement BEFORE >>>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show >>>>>>> consent, so I may file a PR. >>>>>>> >>>>>>> Thanks >>>>>>> -Markus >>>>>>> >>>>>>> >>>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >>>>>>> >>>>>>> Recently OpenJDK adopted the new method >>>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in >>>>>>> Java 25. As a bulk reader method, it allows potentially improved >>>>>>> efficiency over the previously available char-by-char reader >>>>>>> method CharSequence::charAt(int). >>>>>>> >>>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing >>>>>>> list to use the new method within the internal source code of >>>>>>> OpenJDK for the implementation of Appendables (see >>>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >>>>>>> The idea behind this is that the implementations might be more >>>>>>> efficient then. >>>>>>> >>>>>>> A quick analysis of the OpenJDK source code identified (at >>>>>>> least) the following classes which could potentially run more >>>>>>> efficient when using CharSequence::getChars internally, thanks >>>>>>> to bulk reading and / or prevention of internal copies / >>>>>>> toString() conversions: >>>>>>> * java.io.Writer >>>>>>> * java.io.StringWriter >>>>>>> * java.io.PrintWriter >>>>>>> * java.io.BufferedWriter >>>>>>> * java.io.CharArrayWriter >>>>>>> * java.io.FileWriter >>>>>>> * java.io.OutputStreamWriter >>>>>>> * sun.nio.cs.StreamEncoder >>>>>>> * java.io.PrintStream >>>>>>> * java.nio.CharBuffer >>>>>>> >>>>>>> In the sense of "eat your own dog food", it makes sense to >>>>>>> implement Chen's idea in (at least) those classes. Possibly more >>>>>>> classes could get identified when taking a deeper look. Besides >>>>>>> the potential efficiency improvements, it would be a good show >>>>>>> case for the usage of the new API. >>>>>>> >>>>>>> The risk of this change should be low, as test coverage exists, >>>>>>> and as the intended changes are solely internal to the >>>>>>> implementation. No API will get changed. In some cases the >>>>>>> JavaDocs will get slightly adapted where it currently exposes >>>>>>> the actual implementation (to not lie in future). >>>>>>> >>>>>> >>>> >> From shaojin.wensj at alibaba-inc.com Sun May 18 15:51:15 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Sun, 18 May 2025 23:51:15 +0800 Subject: =?UTF-8?B?QzIgaW5saW5pbmcgZmFpbGVkIGJlY2F1c2UgdGhlIFN0cmluZyBjb25zdHJ1Y3RvciBpcyB0?= =?UTF-8?B?b28gbGFyZ2U=?= Message-ID: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. The following is the output information of PrintInlining: ``` @ 9 java.lang.String:: (12 bytes) inline (hot) !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big ``` In Java code, the big method that cannot be inlined is the following constructor ```java String(Charset charset, byte[] bytes, int offset, int length) {} ``` This is an important method that is called frequently. Breaking it into small methods does not require changing the code logic and is easy to accomplish. It is the easiest gain with minimal impact. I suggest solving this problem in JDK 25. -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Sun May 18 18:20:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Sun, 18 May 2025 18:20:51 GMT Subject: RFR: 8357178: Simplify Class::componentType In-Reply-To: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: On Sat, 17 May 2025 02:15:42 GMT, Chen Liang wrote: > `isArray` and null return is now redundant when `componentType` is changed to an explicit field. src/java.base/share/classes/java/lang/Class.java line 3985: > 3983: @Override > 3984: public Class componentType() { > 3985: return componentType; Did you consider calling getComponentType(), which already returns the field? Are there regression tests for Class::componentType()/Class::getComponentType() somewhere? I didn't see them in the obvious test/jdk/java/lang/Class directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25280#discussion_r2094593495 From forax at univ-mlv.fr Sun May 18 19:29:47 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 18 May 2025 21:29:47 +0200 (CEST) Subject: C2 inlining failed because the String constructor is too large In-Reply-To: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com> References: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com> Message-ID: <1447913636.268929756.1747596587470.JavaMail.zimbra@univ-eiffel.fr> It's perhaps easier to just add an annotation @ForceInlining. regards, R?mi > From: "wenshao" > To: "core-libs-dev" > Sent: Sunday, May 18, 2025 5:51:15 PM > Subject: C2 inlining failed because the String constructor is too large > Through JVM Option +PrintInlining, we found that String has a constructor > codeSize of 852, which is too large. This caused failed to inline. > The following is the output information of PrintInlining: > ``` > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > ``` > In Java code, the big method that cannot be inlined is the following constructor > ```java > String(Charset charset, byte[] bytes, int offset, int length) {} > ``` > This is an important method that is called frequently. Breaking it into small > methods does not require changing the code logic and is easy to accomplish. > It is the easiest gain with minimal impact. I suggest solving this problem in > JDK 25. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Sun May 18 20:44:46 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sun, 18 May 2025 20:44:46 +0000 Subject: C2 inlining failed because the String constructor is too large In-Reply-To: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com> References: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com> Message-ID: This sounds like a very interesting proposal. If we can split up the constructor, we might be able to merge the two separate yes replacement (constructor) and no replacement (NoRepl) implementations into one down the road. I saw the PR https://github.com/openjdk/jdk/pull/25290, and from the diff (when Hide Whitespace is chosen), I see the change does bring much more consistency. Chen ________________________________ From: core-libs-dev on behalf of wenshao Sent: Sunday, May 18, 2025 10:51 AM To: core-libs-dev Subject: C2 inlining failed because the String constructor is too large Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. The following is the output information of PrintInlining: ``` @ 9 java.lang.String:: (12 bytes) inline (hot) !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big ``` In Java code, the big method that cannot be inlined is the following constructor ```java String(Charset charset, byte[] bytes, int offset, int length) {} ``` This is an important method that is called frequently. Breaking it into small methods does not require changing the code logic and is easy to accomplish. It is the easiest gain with minimal impact. I suggest solving this problem in JDK 25. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Sun May 18 20:50:06 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sun, 18 May 2025 20:50:06 +0000 Subject: RFC: 8356679: Using CharSequence::getChars internally In-Reply-To: <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> Message-ID: Hi Markus, I think you can submit a draft PR - while some people here like Alan Bateman use draft PRs to indicate "not ready for any review" and discussions are not forwarded to the mailing lists, they are still very useful for looking at the change set. Note that we are a few short weeks from RDP1 of 25 - while I also wish improvements can be integrated into the JDK, there is no guarantee that they will make 25, and we shouldn't rush changes in order to catch up with a release train. Regards, Chen ________________________________ From: core-libs-dev on behalf of Markus KARG Sent: Sunday, May 18, 2025 10:09 AM To: core-libs-dev at openjdk.org Subject: Re: RFC: 8356679: Using CharSequence::getChars internally Roger, thank you for your comments. Following your advice I have splitted the larger work of JDK-8356679 into sub tasks. I would like to start with a first PR implementing the *foundational* work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For convenience, attached below is a copy of the description. Comments Welcome! If everybody is fine with this, I would be happy to get some +1 to publish the PR for JDK-8357183! Am 14.05.2025 um 15:57 schrieb Roger Riggs: > Hi Markus, > > Starting out with the common case is a good idea for the first PR. > > I much prefer a PR with a single goal and that comes to a conclusion > and does not add new features or changes after the PR is submitted. > I tend to lose interest in PRs with lots of churn, it means I have to > re-review the bulk of it when there is a change and may wait days to > let it settle down before coming back to it. > > I tend to think the PR was not really ready to be reviewed if simple > issues and corrections have to be made frequently. > Do your own checking for typos and copyrights and simple refactoring > before opening the PR. > Quality before quantity or speed. > > I'm fine with separate Jira issues that clearly delineate a specific > scope and goal. > > The title of this issue (8356679) doesn't identify the real goal. > It seems to be to improve performance or memory usage, not just to use > a new API. > > These are my personal opinions about contributions and process. > > Regards, Roger > > > On 5/14/25 6:48 AM, Markus KARG wrote: >> Many of the modified classes derive from a common super class and >> share one needed common change (which is one of the points which are >> easy to see once you see all of those classes in a single PR, but >> hard to explain in plaint-text pre-PR mailing list threads), so at >> least those need to be discussed *together*. But to spare JBS and >> PRs, I can open the PR with just the first set of changes, and once >> we agree that this set is fine, I can push the next commit *in the >> same PR*. Otherwise we would need endless JBS, mailing list threads, >> and PRs, just to fixe a dozen internal code lines. >> >> Having said that, does the current state of this thread count as >> "reached common agreement to file a PR" or do I still have to wait >> until more people chime in? >> >> -Markus >> >> >> Am 13.05.2025 um 15:10 schrieb Roger Riggs: >>> Hi Markus, >>> >>> A main point was to avoid trying to do everything at once. >>> The PR comments become hard to follow and intermingled and it takes >>> longer to get agreement because of the thrash in the PR. >>> >>> Roger >>> >>> On 5/13/25 5:05 AM, Markus KARG wrote: >>>> Thank you, Roger. >>>> >>>> Actually the method helps in the "toString()" variants, too, as in >>>> some places we could *get rid* of "toString()" (which is more work >>>> than "just" a buffer due to the added compression complexity). >>>> >>>> In fact, I already took the time to rewrite *all* of them while >>>> waiting for the approval of this list posting. In *all* cases >>>> *less* buffering / copying is needed, and *less* "toString()" >>>> conversion (which is a copy under the hood) is needed. So if I >>>> would be allowed to show the code as a PR, it would be much easier >>>> to explain and discuss. >>>> >>>> A PR is the best place to discuss "how to code would change". In >>>> the worst case, let's drop it if we see that it is actually a bad >>>> thing. >>>> >>>> -Markus >>>> >>>> >>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs: >>>>> Hi Markus, >>>>> >>>>> On the surface, its looks constructive. >>>>> I suspect that many of these cases will turn into discussions >>>>> about the right/best/better way to buffer the characters. >>>>> The getChars method only helps when extracting to a char array, >>>>> many of the current implementations create strings as the >>>>> intermediary. The advantage of the 1 character at a time technique >>>>> is not needing a (separated allocated) buffer. >>>>> Consider taking a few at a time before launching into the whole set. >>>>> >>>>> $.02, Roger >>>>> >>>>> On 5/11/25 2:45 AM, Markus KARG wrote: >>>>>> Dear Core Libs Team, >>>>>> >>>>>> I am hereby requesting comments on JDK-8356679. >>>>>> >>>>>> I would like to invest some time and set up a PR implementing >>>>>> Chen Liangs's proposal laid out in >>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your >>>>>> convenience, the text of that JBS is copied below. According to >>>>>> the Developer's Guide I do need to get broad agreement BEFORE >>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show >>>>>> consent, so I may file a PR. >>>>>> >>>>>> Thanks >>>>>> -Markus >>>>>> >>>>>> >>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: >>>>>> >>>>>> Recently OpenJDK adopted the new method >>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in >>>>>> Java 25. As a bulk reader method, it allows potentially improved >>>>>> efficiency over the previously available char-by-char reader >>>>>> method CharSequence::charAt(int). >>>>>> >>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing >>>>>> list to use the new method within the internal source code of >>>>>> OpenJDK for the implementation of Appendables (see >>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). >>>>>> The idea behind this is that the implementations might be more >>>>>> efficient then. >>>>>> >>>>>> A quick analysis of the OpenJDK source code identified (at least) >>>>>> the following classes which could potentially run more efficient >>>>>> when using CharSequence::getChars internally, thanks to bulk >>>>>> reading and / or prevention of internal copies / toString() >>>>>> conversions: >>>>>> * java.io.Writer >>>>>> * java.io.StringWriter >>>>>> * java.io.PrintWriter >>>>>> * java.io.BufferedWriter >>>>>> * java.io.CharArrayWriter >>>>>> * java.io.FileWriter >>>>>> * java.io.OutputStreamWriter >>>>>> * sun.nio.cs.StreamEncoder >>>>>> * java.io.PrintStream >>>>>> * java.nio.CharBuffer >>>>>> >>>>>> In the sense of "eat your own dog food", it makes sense to >>>>>> implement Chen's idea in (at least) those classes. Possibly more >>>>>> classes could get identified when taking a deeper look. Besides >>>>>> the potential efficiency improvements, it would be a good show >>>>>> case for the usage of the new API. >>>>>> >>>>>> The risk of this change should be low, as test coverage exists, >>>>>> and as the intended changes are solely internal to the >>>>>> implementation. No API will get changed. In some cases the >>>>>> JavaDocs will get slightly adapted where it currently exposes the >>>>>> actual implementation (to not lie in future). >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Sun May 18 20:55:48 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 18 May 2025 20:55:48 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: > This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage > native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences > and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to > use java.lang.ref.Cleaner. > > This change is algorithmically similar to the two previous versions: > JDK-6857566 and JDK-8156500 (current mainline). The critical function is > Bits::reserveMemory(). For both of those versions and this change, a thread > calls that function and tries to reserve some space. If it fails, then it > keeps trying until all cleaners deactivated (cleared) by prior GCs have been > cleaned. If reservation still fails, then it invokes the GC to try to > deactivate more cleaners for cleaning. After that GC it keeps trying the > reservation and waiting for cleaning, with sleeps to avoid a spin loop, > eventually either succeeding or giving up and throwing OOME. > > Retaining that algorithmic approach is one of the goals of this change, since > it has been successfully in use since JDK 9 (and was originally developed and > extensively tested in JDK 8). > > The key to this approach is having a way to determine that deactivated > cleaners have been cleaned. JDK-6857566 accomplished this by having waiting > threads help the reference processor until there was no available work. > JDK-8156500 waits for the reference processor to quiesce, relying on its > immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way > to do this, which is why this change rolls its own Cleaner-like mechanism from > the underlying primitives. Like JDK-6857566, this change has waiting threads > help with cleaning references. This was a potentially undesirable feature of > JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. > (Though by the time of JDK-6857566 the cleaners were only used by DBB, and > became internal-only somewhere around that time as well.) That's not a concern > here, as the cleaners involved are only from DBB, and we know what they look > like. > > As noted in the discussion of JDK-6857566, it's good to have DBB cleaning > being done off the reference processing thread, as it may be expensive and > slow down enqueuing other pending references. JDK-6857566 only did some of > that, and JDK-8156500 lost that feature. This change moves all of the DBB > cleaning off of the reference processing thread. (So does PR 22165.) > > Neither JDK-6857566 nor this change are completely precise. For both, a thread > may find there is no available work whil... Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: move jdk.internal.nio.Cleaner to sun.nio ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25289/files - new: https://git.openjdk.org/jdk/pull/25289/files/3ebf665c..45d0b1ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=00-01 Stats: 8 lines in 6 files changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25289.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289 PR: https://git.openjdk.org/jdk/pull/25289 From kbarrett at openjdk.org Sun May 18 20:55:49 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 18 May 2025 20:55:49 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett wrote: > This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage > native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences > and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to > use java.lang.ref.Cleaner. > > This change is algorithmically similar to the two previous versions: > JDK-6857566 and JDK-8156500 (current mainline). The critical function is > Bits::reserveMemory(). For both of those versions and this change, a thread > calls that function and tries to reserve some space. If it fails, then it > keeps trying until all cleaners deactivated (cleared) by prior GCs have been > cleaned. If reservation still fails, then it invokes the GC to try to > deactivate more cleaners for cleaning. After that GC it keeps trying the > reservation and waiting for cleaning, with sleeps to avoid a spin loop, > eventually either succeeding or giving up and throwing OOME. > > Retaining that algorithmic approach is one of the goals of this change, since > it has been successfully in use since JDK 9 (and was originally developed and > extensively tested in JDK 8). > > The key to this approach is having a way to determine that deactivated > cleaners have been cleaned. JDK-6857566 accomplished this by having waiting > threads help the reference processor until there was no available work. > JDK-8156500 waits for the reference processor to quiesce, relying on its > immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way > to do this, which is why this change rolls its own Cleaner-like mechanism from > the underlying primitives. Like JDK-6857566, this change has waiting threads > help with cleaning references. This was a potentially undesirable feature of > JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. > (Though by the time of JDK-6857566 the cleaners were only used by DBB, and > became internal-only somewhere around that time as well.) That's not a concern > here, as the cleaners involved are only from DBB, and we know what they look > like. > > As noted in the discussion of JDK-6857566, it's good to have DBB cleaning > being done off the reference processing thread, as it may be expensive and > slow down enqueuing other pending references. JDK-6857566 only did some of > that, and JDK-8156500 lost that feature. This change moves all of the DBB > cleaning off of the reference processing thread. (So does PR 22165.) > > Neither JDK-6857566 nor this change are completely precise. For both, a thread > may find there is no available work whil... BTW, I'm fine with a suggestion to wait until JDK 26 before integrating this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25289#issuecomment-2889206138 From kbarrett at openjdk.org Sun May 18 20:55:50 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 18 May 2025 20:55:50 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 12:11:21 GMT, Alan Bateman wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> move jdk.internal.nio.Cleaner to sun.nio > > src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26: > >> 24: */ >> 25: >> 26: package jdk.internal.nio; > > The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together. Good point. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2094623283 From liach at openjdk.org Sun May 18 21:17:50 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 May 2025 21:17:50 GMT Subject: RFR: 8357178: Simplify Class::componentType In-Reply-To: References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: On Sun, 18 May 2025 18:18:04 GMT, Joe Darcy wrote: > Did you consider calling getComponentType(), which already returns the field? I don't think we want an extra indirection here - The logic here is quite simple. Counterargument could be that `MethodType::descriptorString` calls `toMethodDescriptorString`, except these methods involve more complex caching and is not simple like this field access. > Are there regression tests for Class::componentType()/Class::getComponentType() somewhere? I didn't see them in the obvious test/jdk/java/lang/Class directory. They are located in `test/jdk/java/lang/constant/TypeDescriptorTest.java`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25280#discussion_r2094628277 From liach at openjdk.org Sun May 18 22:03:28 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 May 2025 22:03:28 GMT Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently Message-ID: The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail. Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well. Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug. ------------- Commit messages: - Restore incorrectly removed annotation - Fix problems with class value tests Changes: https://git.openjdk.org/jdk/pull/25292/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25292&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357165 Stats: 14 lines in 1 file changed: 5 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25292.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25292/head:pull/25292 PR: https://git.openjdk.org/jdk/pull/25292 From duke at openjdk.org Sun May 18 23:47:08 2025 From: duke at openjdk.org (fabioromano1) Date: Sun, 18 May 2025 23:47:08 GMT Subject: RFR: 8077587: BigInteger Roots [v16] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Do first refinement loop only if shift == 0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/aeef24cb..307af7f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=14-15 Stats: 30 lines in 1 file changed: 12 ins; 11 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From liach at openjdk.org Mon May 19 00:22:08 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 May 2025 00:22:08 GMT Subject: RFR: 8357178: Simplify Class::componentType [v2] In-Reply-To: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: > `isArray` and null return is now redundant when `componentType` is changed to an explicit field. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: For parity with MT.descriptorString ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25280/files - new: https://git.openjdk.org/jdk/pull/25280/files/272ee25d..f8f0bf65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25280&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25280&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25280/head:pull/25280 PR: https://git.openjdk.org/jdk/pull/25280 From xgong at openjdk.org Mon May 19 03:13:55 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 19 May 2025 03:13:55 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong wrote: > JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). > > Two key areas require improvement: > 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. > 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. > > This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. > > Main changes: > 1. Java-side API refactoring: > - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on > architectures like AArch64. > 2. C2 compiler IR refactoring: > - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. > 3. Backend changes: > - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. > > Performance: > The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: > > Benchmark Mode Cnt Unit SIZE Before After Gain > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.312 935.269 1.02 > GatherOperationsBenchmark.micr... Ping again~ could any one please take a look at this PR? Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2889487313 From jlahoda at openjdk.org Mon May 19 03:49:20 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 03:49:20 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v4] In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adjusting message and tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25256/files - new: https://git.openjdk.org/jdk/pull/25256/files/f63dab37..db7e7ceb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From kbarrett at openjdk.org Mon May 19 05:53:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 May 2025 05:53:51 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v4] In-Reply-To: References: <-oOK2Dh2vnn9Qc5MBRiKoeauVFVPPV_9fKMqAQwjFfY=.b20b09d9-a268-4ca9-9362-7045c6a3afce@github.com> Message-ID: On Fri, 11 Apr 2025 10:52:03 GMT, Aleksey Shipilev wrote: >> As far as I can tell, intrinsic selection only applies when the call target is >> exactly the intrinsically attributed method. (Possibly after optimizations >> that lead to a call to that specific method.) And that's obviously necessary >> for correctness of applying intrinsics. >> >> The documentation for `@IntrinsicCandidate` suggests it is "better to make >> intrinsics be static methods", but non-static methods are certainly permitted, >> and I've found several. In particular, the method in question, >> `Reference::get`, has been a virtual intrinsic with at least three >> (non-intrinsic) overrides (SoftReference, PhantomReference, and >> FinalReference) for a long time. >> >> I did a bit of experimenting, and as far as I can tell, everything works as >> expected. Reference::get is already registered as having >> vmIntrinsics::_Reference_get as it's intrinsic_id, and that intrinsic id is >> handled by the various code processors, such as being in the dispatch table >> that @vnkozlov refreenced. >> >> All of Reference::get, Reference::refersTo, and Reference::clear are subtly >> different in the details of how they are implemented and intrinsified, because >> there are differences among them. >> >> refersTo is final, but needs different implementations for Reference and >> PhantomReference. That distinction is handled via nonpublic virtual >> refersToImpl. And those are implemented in terms of separate intrinsified >> private native methods because we found that C2 handling of intrinsified >> virtual native methods had problems. If not for that issue, the refersToImpl >> methods would be intrinsified virtual native methods. >> >> Reference::clear also needs clearImpl, but for a different reason. There are >> places where we want to directly call the implementation of Reference::clear, >> ignoring any overrides by derived application classes. That is accomplished by >> calling the virtual clearImpl, which has implementations in Reference and >> PhantomReference. And the clearImpls are implemented in terms of separate >> intrinsified private native methods because of the above mentioned C2 issue. >> >> The native implementations for clear call the same JVM_ReferenceClear helper >> function, which uses unknown_referent_no_keepalive to handle the distinction >> between weak and phantom strengths. If we just had the native implementation >> we could drop the PhantomReference override. But this operation also has >> intrinsic support, and the intrinsic makes use of the known strength. >> > ... > > I think I understand the intrinsic matchers machinery better now: it indeed binds intrinsics to concrete methods. So virtual overrides are supposed to have no difference. Also, I tried a few examples where I thought it should fail, and it does not. I added some diagnostic checks around interpreter, and they do not fail: > > > diff --git a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp > index bdc2ca908bd..255fa6443af 100644 > --- a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp > +++ b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp > @@ -652,6 +652,21 @@ address TemplateInterpreterGenerator::generate_Reference_get_entry(void) { > // rdx: scratch > // rdi: scratch > > + if (UseNewCode) { > + Label L_good; > + __ push(rscratch1); > + __ push(rscratch2); > + > + __ load_klass(rscratch1, rax, rscratch2); > + __ cmpb(Address(rscratch1, in_bytes(InstanceKlass::reference_type_offset())), REF_PHANTOM); > + __ jccb(Assembler::notEqual, L_good); > + __ stop("PHANTOM REFERENCE CALLED WITH INTERPRETER REFERENCE.GET INTRINSIC"); > + __ bind(L_good); > + > + __ pop(rscratch2); > + __ pop(rscratch1); > + } > + > // Load the value of the referent field. > const Address field_address(rax, referent_offset); > __ load_heap_oop(rax, field_address, /*tmp1*/ rbx, ON_WEAK_OOP_REF); > > > I tried C2 IR test, and it works fine: we return constant `0` for `PhantomReferences`, like we would expect. I am going to RFR that test separately, [JDK-8354417](https://bugs.openjdk.org/browse/JDK-8354417). > > That said, I am still not 100% sure there is no bug, because I see intrinsics like `Object.hashCode` do seem to handle virtual cases. Quoting from https://bugs.openjdk.org/browse/JDK-8271862 > However, Object.clone() and Object.hashCode() are also virtual, native and @IntrinsicCandidate, and these get special treatment by C2 to get the intrinsic generated more optimally. It's not clear to me if we should do something similar with refersTo0() or if the above workaround should be considered good enough. For Reference.refersTo (and later, Reference.clear) we did the workaround, avoiding methods that had all 3 properties. Similarly for Reference.get here. But it might be worthwhile looking into this issue more carefully and generally, both to make sure there aren't other affected intrinsics, and to either solve that case better or complain when it arises. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2094884157 From jpai at openjdk.org Mon May 19 06:22:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 06:22:56 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v4] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Mon, 19 May 2025 03:49:20 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adjusting message and tests. The updated changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2849510798 From jpai at openjdk.org Mon May 19 07:02:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 07:02:58 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: On Fri, 16 May 2025 18:37:38 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 478: >> >>> 476: * >>> 477: *

      If an I/O error occurs reading from the stream, then it >>> 478: * may do so after some, but not all, characters have been read. >> >> Hello Brian, I read this sentence a couple of times but it wasn't clear to me what this meant. I am guessing that we want to state that if an I/O error occurs when some (but not all?) characters have been read then the stream may be in an inconsistent state? Should we reword this paragraph? >> >> I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing. > >> I read this sentence a couple of times [...] > > Please see [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045). > >> I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing. > > If you think it worthwhile, please file an issue to improve that verbiage as well. Thank you Brian, the updated text for this section looks good to me. Once this PR gets integrated, I'll go through the Files.readXXX methods and file an issue to have that text simplified too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2094977207 From alanb at openjdk.org Mon May 19 07:17:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 May 2025 07:17:56 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <8SJl_mDv3MuJGgTfW3pc4adoVxHpbwVyPEgD0n2nguM=.d9845fcc-cf54-46e8-b2af-a2ce16f4b991@github.com> On Mon, 19 May 2025 06:59:58 GMT, Jaikiran Pai wrote: >>> I read this sentence a couple of times [...] >> >> Please see [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045). >> >>> I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing. >> >> If you think it worthwhile, please file an issue to improve that verbiage as well. > > Thank you Brian, the updated text for this section looks good to me. Once this PR gets integrated, I'll go through the Files.readXXX methods and file an issue to have that text simplified too. I see this has been changed to "then some characters, but not all" but it doesn't flow very well. The original sentence, which was copied/modified from InputStream.readAllBytes, is much cleaner and I think I would prefer to go back to that. Maybe Jai's issue could be address by dropping the first comma from the sentence? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2095001660 From jlahoda at openjdk.org Mon May 19 07:32:02 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 07:32:02 GMT Subject: Integrated: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). This pull request has now been integrated. Changeset: 77a3e04f Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/77a3e04ffc27554c14e3d45ba16ad0ee8f3c1eb1 Stats: 177 lines in 8 files changed: 151 ins; 10 del; 16 mod 8357016: Candidate main methods not computed properly Reviewed-by: jpai, vromero ------------- PR: https://git.openjdk.org/jdk/pull/25256 From tvaleev at openjdk.org Mon May 19 07:34:43 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Mon, 19 May 2025 07:34:43 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface Message-ID: Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html The specification is mostly composed of Math.min/max and Collections.min/max specifications. The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. ------------- Commit messages: - Fix linebreaks - JDK-8356995 Provide default methods min(T, T) and max(T, T) in Comparator interface Changes: https://git.openjdk.org/jdk/pull/25297/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356995 Stats: 112 lines in 2 files changed: 110 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297 PR: https://git.openjdk.org/jdk/pull/25297 From forax at univ-mlv.fr Mon May 19 08:13:13 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 May 2025 10:13:13 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: <52514642-e172-4096-a616-a2c9a9787552@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <52514642-e172-4096-a616-a2c9a9787552@gmail.com> Message-ID: <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "cay horstmann" > To: "core-libs-dev" > Sent: Sunday, May 18, 2025 7:55:12 AM > Subject: Re: Towards a JSON API for the JDK Hello Cay, > +1 for having a JSON battery included with the JDK. And for "Our primary goal is > that the library be simple to use for parsing, traversing, and generating > conformant JSON documents." > > Generating JSON could be easier. Why not convenience methods Json.newObject and > Json.newArray like in https://github.com/arkanovicz/essential-json? > > Parsing with instanceof will work, but is obviously painful today, as your > example shows. The simplification with deconstruction patterns is not > impressive either. > > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject(var members) > && members.get("name") instanceof JsonString(String name) > && members.get("age") instanceof JsonNumber(int age)) { > // use "name" and "age" > } else throw new NoSuchArgumentException(); > > vs. Jackson > > String name = doc.get("name").asText(); > int age = doc.get("age").asInt(); > ... > > If only there was some deconstruction magic that approximates the JavaScript > code > > const doc = { name: "John", age: 30 } > const { name, age } = doc We already have that, it's called a record :) Basically, you are advocating for a mapping JsonObject <--> record. [...] > > Cheers, > > Cay > Here is a simple JsonObject mapper using java.util.json types. https://github.com/forax/json-object-mapper I believe this is also the fastest possible ... it leverages method handles to generate the mapping code (it's only 128 lines of code, obviously, it's a prototype) https://github.com/forax/json-object-mapper/blob/master/src/main/java/json/RecordMapperImpl.java It's mostly on par with hand-coded code (i've just a supplementary lookup through a StableValue) // Benchmark Mode Cnt Score Error Units // RecordMapperBench.mappingSimple avgt 5 15,057 ? 0,050 ns/op // RecordMapperBench.recordMapper avgt 5 16,997 ? 0,044 ns/op regards, R?mi From jlahoda at openjdk.org Mon May 19 08:31:56 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 08:31:56 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v16] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 22:32:12 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments javac changes look good to me, with one trivial nit in `Check`. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5848: > 5846: } > 5847: } > 5848: } Nit - there appears to be an extra space at the beginning of this line. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2849882159 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2095145360 From jpai at openjdk.org Mon May 19 08:55:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 08:55:53 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig wrote: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing Hello Manuel, > When passing -J-version to the patched javac, tools/launcher/ToolsOpts.java wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly The proposed change looks reasonable to me. A brief look through JEP-223 https://openjdk.org/jeps/223 suggests that a space character cannot appear in the JDK version, so this proposed change to use " -J-" won't run into the same issue as previously. The copyright year on this test will need an update. Please also add a "noreg-self" (https://openjdk.org/guide/#noreg) to the JBS issue. ------------- PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2849969430 From pminborg at openjdk.org Mon May 19 09:13:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 19 May 2025 09:13:03 GMT Subject: RFR: 8357178: Simplify Class::componentType [v2] In-Reply-To: References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: <5K8uBd9NeI5sS4c6qT-BCiPOJp0DnC5dNmBnoSZvS14=.577456e6-50be-4a36-9a79-47de1d4e38fb@github.com> On Mon, 19 May 2025 00:22:08 GMT, Chen Liang wrote: >> `isArray` and null return is now redundant when `componentType` is changed to an explicit field. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > For parity with MT.descriptorString Question: Why was this overload added in the first place, as it seems equivalent to `getComponentType()`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2890245474 From jpai at openjdk.org Mon May 19 09:13:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 09:13:14 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:10:21 GMT, Manuel H?ssig wrote: >> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: >> >> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 >> >> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. >> >> Testing: >> - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) >> - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Thank you for the update. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2850018076 From mhaessig at openjdk.org Mon May 19 09:13:14 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 19 May 2025 09:13:14 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25230/files - new: https://git.openjdk.org/jdk/pull/25230/files/a11ff5e5..388f3683 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25230/head:pull/25230 PR: https://git.openjdk.org/jdk/pull/25230 From jpai at openjdk.org Mon May 19 09:22:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 09:22:54 GMT Subject: RFR: 8357106: Add missing classpath exception copyright headers In-Reply-To: References: Message-ID: On Fri, 16 May 2025 07:04:04 GMT, Sorna Sarathi N wrote: > This PR adds missing classpath exception The change looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25261#pullrequestreview-2850053263 From jpai at openjdk.org Mon May 19 09:31:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 09:31:55 GMT Subject: RFR: 8357081: Removed unused methods of HexDigits In-Reply-To: References: Message-ID: On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen wrote: > In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods It does indeed look like these are unused. The change looks OK to me but please wait for one more review from someone more familiar with this code to understand if there's anything more to consider. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25258#pullrequestreview-2850079533 From duke at openjdk.org Mon May 19 09:32:53 2025 From: duke at openjdk.org (duke) Date: Mon, 19 May 2025 09:32:53 GMT Subject: RFR: 8357106: Add missing classpath exception copyright headers In-Reply-To: References: Message-ID: On Fri, 16 May 2025 07:04:04 GMT, Sorna Sarathi N wrote: > This PR adds missing classpath exception @Sorna-Sarathi Your change (at version 1b55b287f84d5cad1958aec440f3b499a874b04c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25261#issuecomment-2890316340 From mhaessig at openjdk.org Mon May 19 09:32:53 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 19 May 2025 09:32:53 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:13:14 GMT, Manuel H?ssig wrote: >> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: >> >> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 >> >> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. >> >> Testing: >> - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) >> - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25230#issuecomment-2890310647 From duke at openjdk.org Mon May 19 09:32:54 2025 From: duke at openjdk.org (duke) Date: Mon, 19 May 2025 09:32:54 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:13:14 GMT, Manuel H?ssig wrote: >> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: >> >> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 >> >> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. >> >> Testing: >> - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) >> - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright @mhaessig Your change (at version 388f36832198c72268a3302cacb3192e9e93cf21) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25230#issuecomment-2890316802 From mhaessig at openjdk.org Mon May 19 10:18:58 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 19 May 2025 10:18:58 GMT Subject: Integrated: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig wrote: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing This pull request has now been integrated. Changeset: 36c9be70 Author: Manuel H?ssig Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/36c9be70e27eccdd2a156931fafa1f55dd3fb022 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" Reviewed-by: jpai, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/25230 From ssarathi at openjdk.org Mon May 19 10:19:55 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Mon, 19 May 2025 10:19:55 GMT Subject: Integrated: 8357106: Add missing classpath exception copyright headers In-Reply-To: References: Message-ID: <_z7ivO4xGAYExHsow29YjGlW_YjsfkDaztbrOkFTGrc=.99772a7f-ee07-47e1-81ef-22f88aa8bcd0@github.com> On Fri, 16 May 2025 07:04:04 GMT, Sorna Sarathi N wrote: > This PR adds missing classpath exception This pull request has now been integrated. Changeset: afcaf840 Author: Sorna Sarathi N Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/afcaf84022f165d66068c16460b7666f48e84773 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8357106: Add missing classpath exception copyright headers Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/25261 From duke at openjdk.org Mon May 19 10:21:08 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 19 May 2025 10:21:08 GMT Subject: RFR: 8077587: BigInteger Roots [v17] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Code simplification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/307af7f6..fe82fa72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=15-16 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From liach at openjdk.org Mon May 19 10:46:52 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 May 2025 10:46:52 GMT Subject: RFR: 8357178: Simplify Class::componentType [v2] In-Reply-To: <5K8uBd9NeI5sS4c6qT-BCiPOJp0DnC5dNmBnoSZvS14=.577456e6-50be-4a36-9a79-47de1d4e38fb@github.com> References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> <5K8uBd9NeI5sS4c6qT-BCiPOJp0DnC5dNmBnoSZvS14=.577456e6-50be-4a36-9a79-47de1d4e38fb@github.com> Message-ID: <1rO5rd1EN4l_CuHuxsB4tUINs0pBzm-qEiq4sSGF8lo=.d346059c-9bf1-442e-b6b5-2fdf092d336a@github.com> On Mon, 19 May 2025 09:10:23 GMT, Per Minborg wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> For parity with MT.descriptorString > > Question: Why was this overload added in the first place, as it seems equivalent to `getComponentType()`? @minborg It implements a method in TypeDescriptor.OfField. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2890543283 From dfuchs at openjdk.org Mon May 19 11:09:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 19 May 2025 11:09:00 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v10] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 11:42:08 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - update to minimise code changes > - Merge branch 'master' into 8348986-exceptions > - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 78: > 76: * controlled. Consider using a unique value for the > 77: * SecurityProperties.includedInExceptions(String value) mechanism > 78: * Current values defined are "socket", "jar", "userInfo" If I am not mistaken the "socket" info is no longer here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2095457460 From jbhateja at openjdk.org Mon May 19 11:30:50 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 19 May 2025 11:30:50 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Mon, 19 May 2025 03:10:46 GMT, Xiaohong Gong wrote: >> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). >> >> Two key areas require improvement: >> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. >> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. >> >> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. >> >> Main changes: >> 1. Java-side API refactoring: >> - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on >> architectures like AArch64. >> 2. C2 compiler IR refactoring: >> - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. >> 3. Backend changes: >> - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. >> >> Performance: >> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: >> >> Benchmark Mode Cnt Unit SIZE Before After Gain >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.31... > > Ping again~ could any one please take a look at this PR? Thanks a lot! Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing and get back. Do you have any idea about following regression? GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 64 55844.814 48311.847 0.86 GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 256 15139.459 13009.848 0.85 GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 1024 3861.834 3284.944 0.85 GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 4096 938.665 817.673 0.87 Best Regards ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2890659302 From nbenalla at openjdk.org Mon May 19 11:34:31 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 11:34:31 GMT Subject: RFR: 8356629: Incorrect use of {@linkplain} in java.sql Message-ID: Please review this trivial patch to fix a javadoc bug. TIA ------------- Commit messages: - use PseudoColumnUsage#name() instead - fix incorrect `@link` tags Changes: https://git.openjdk.org/jdk/pull/25286/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25286&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356629 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25286.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25286/head:pull/25286 PR: https://git.openjdk.org/jdk/pull/25286 From duke at openjdk.org Mon May 19 11:35:54 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 11:35:54 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 15:38:33 GMT, Lance Andersen wrote: >> src/jdk.zipfs/share/classes/module-info.java line 299: >> >>> 297: *

    • >>> 298: * Any other values will cause an {@code IllegalArgumentException} >>> 299: * to be thrown. >> >> The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too. > > The IAE message would be best to standardize around the wording that the compressMethod property uses (same for releaseVersion while we are at it. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095504122 From duke at openjdk.org Mon May 19 11:35:55 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 11:35:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Wed, 14 May 2025 16:42:07 GMT, Lance Andersen wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on review feedback. > > test/jdk/jdk/nio/zipfs/TestPosix.java line 434: > >> 432: createTestZipFile(ZIP_FILE, ENV_DEFAULT).close(); >> 433: // check entries on zipfs with default options >> 434: try (FileSystem zip = FileSystems.newFileSystem(ZIP_FILE, ENV_DEFAULT)) { > > This tests an empty Map and should still be a test as it is different from ENV_READ_ONLY Revert and added new ReadOnly variants of those tests. Thanks for calling me out on this, it was a bit sloppy of me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095503763 From duke at openjdk.org Mon May 19 11:45:54 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 11:45:54 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com> On Fri, 16 May 2025 14:23:38 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114: > >> 112: private final ZipPath rootdir; >> 113: // Starts in readOnly (safe mode), but might be reset at the end of initialization. >> 114: private boolean readOnly = true; > > If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't? ""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?"" If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents. While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since: 1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.). 2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup). I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour. > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 245: > >> 243: : "The underlying ZIP file is not writable"; >> 244: throw new IOException( >> 245: "A writable ZIP file system could not be opened for: " + zfpath + "\n" + reason); > > The JDK coding guidelines recommend excluding file paths from exception messages. So in this case the `zfpath` should be left out from the exception message. Additionally, I haven't seen us using newline characters in exception messages that we construct in the JDK code. So I think we should leave that out too. > > Given this, I think it might be simpler to just change this `if` block to something like: > > > > if (...) { > String reason = multiReleaseVersion.isPresent() > ? "the multi-release JAR file is not writable" > : "the ZIP file is not writable"; > > throw new IOException(reason); > } Thanks for letting me know. Now I think about the "no filename" things is very sensible for core libraries. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095517691 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095520598 From duke at openjdk.org Mon May 19 11:45:55 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 11:45:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 15:19:26 GMT, Lance Andersen wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230: >> >>> 228: // It requires 'entryLookup' and 'readOnly' to have safe defaults (which >>> 229: // is why they are the only non-final fields), and it requires that the >>> 230: // inode map has been initialized. >> >> It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults. >> >> Perhaps something like: >> >>> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed. > > Not sure I see a need for the last sentence regarding the inode map having to be initialized in addition to Jai's comments above Fair enough, removed. I err on the side of over explaining things for future maintainers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095518822 From duke at openjdk.org Mon May 19 11:48:58 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 11:48:58 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 15:17:40 GMT, Lance Andersen wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221: >> >>> 219: } >>> 220: // sm and existence check >>> 221: zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ); >> >> Type name clash with existing AccessMode class. Since new enum is private, happy to rename. > > So perhaps change the name of the newly added enum Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095527265 From duke at openjdk.org Mon May 19 11:52:56 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 11:52:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 14:37:28 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241: > >> 239: this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); >> 240: if (readOnly && accessMode == AccessMode.READ_WRITE) { >> 241: String reason = Files.isWritable(zfpath) > > Nit - this additional call to Files.isWritable(...) can be avoided if we store the value of the previous call (a couple of lines above). I realize that the previous `Files.isWritable` is stashed at the end of the `||` conditionals to prevent it from being invoked in certain situations. > > So maybe a better change would be something like: > > > String reason = multiReleaseVersion.isPresent() > ? "A multi-release JAR file opened with a specified version is not writable" > : "The underlying ZIP file is not writable"; > > > which would then avoid any additional calls to `Files.isWritable`. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095532769 From duke at openjdk.org Mon May 19 11:53:56 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Mon, 19 May 2025 11:53:56 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v16] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 22:32:12 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 308: > 306: "Ljdk/internal/ValueBased+Annotation;"; > 307: private static final String REQUIRES_IDENTITY_ANNOTATION = > 308: "Ljdk/internal/RequieresIdentity;"; typo: RequieresIdentity -> RequiresIdentity ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2095534505 From duke at openjdk.org Mon May 19 12:01:55 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 12:01:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 15:35:18 GMT, Lance Andersen wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259: >> >>> 257: >>> 258: // Pass "this" as a parameter after everything else is set up. >>> 259: this.rootdir = new ZipPath(this, new byte[]{'/'}); >> >> This could probably be set above release version etc. but it's a choice of either: >> 1. waiting until everything is set up before passing "this" >> 2. letting an incomplete "this" instance get passed to another class (possible escape risk?) >> >> Though in this case the "incompleteness" is limited to it not being set up for multi-jar reading yet, which absolutely shouldn't affect the root path. It feels safer to me to leave it to the end, or perhaps we should dig in to ZipPath, figure out what it really wants here, and just call a different constructor? > > I think it was fine where it was originally given how rootdir is used I'd rather at least have it over the last part where the non-final fields are modified (in that state it's an instance functionally identical to one opened on a non-MR JAR). Looking through the ZipPath code, it seems to (currently) only need to read back the ZipCoder field (but I'm still nervous about restoring the "this" escape to its original location since the ZipPath code might change one day and rely on something not initialized). I moved it so it's the last final field initialized, but I'll revert it completely if you want. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095549535 From duke at openjdk.org Mon May 19 12:12:10 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 12:12:10 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v5] In-Reply-To: References: Message-ID: <8zTn8lVzIJC3VY0ZfQIDrMMGSGenVKBnqnqUCoKXdTA=.11f09e50-e233-400b-80f1-c475f606d48a@github.com> > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Changes based on review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/2326999b..a82e4019 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=03-04 Stats: 65 lines in 4 files changed: 35 ins; 7 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From duke at openjdk.org Mon May 19 12:15:38 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 12:15:38 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Fixed test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/a82e4019..ea781c16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From jpai at openjdk.org Mon May 19 12:26:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 12:26:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com> References: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com> Message-ID: <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com> On Mon, 19 May 2025 11:41:16 GMT, David Beaumont wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114: >> >>> 112: private final ZipPath rootdir; >>> 113: // Starts in readOnly (safe mode), but might be reset at the end of initialization. >>> 114: private boolean readOnly = true; >> >> If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't? > > ""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?"" > > If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents. > > While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since: > > 1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.). > > 2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup). > > I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour. Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did: diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java index e2fddd96fe8..f54b5360ac5 100644 --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java @@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem { private final Path zfpath; final ZipCoder zc; private final ZipPath rootdir; - // Starts in readOnly (safe mode), but might be reset at the end of initialization. - private boolean readOnly = true; + private final boolean readOnly; // default time stamp for pseudo entries private final long zfsDefaultTimeStamp = System.currentTimeMillis(); @@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) { // Determining a release version uses 'this' instance to read paths etc. Optional multiReleaseVersion = determineReleaseVersion(env); - - // Set the version-based lookup function for multi-release JARs. - this.entryLookup = - multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity()); - // We only allow read-write zip/jar files if they are not multi-release // JARs and the underlying file is writable. this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); @@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) { : "the ZIP file is not writable"; throw new IOException(reason); } + // Set the version-based lookup function for multi-release JARs. + this.entryLookup = + multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity()); + } /** With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change. Making it `final` and having it not accessed until the ultimate value is set in the constructor would get us past any of the concerns we may have about the "initial" value of `readOnly`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095587777 From jpai at openjdk.org Mon May 19 12:26:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 12:26:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com> References: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com> <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com> Message-ID: On Mon, 19 May 2025 12:22:11 GMT, Jaikiran Pai wrote: >> ""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?"" >> >> If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents. >> >> While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since: >> >> 1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.). >> >> 2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup). >> >> I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour. > > Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did: > > > diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java > index e2fddd96fe8..f54b5360ac5 100644 > --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java > +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java > @@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem { > private final Path zfpath; > final ZipCoder zc; > private final ZipPath rootdir; > - // Starts in readOnly (safe mode), but might be reset at the end of initialization. > - private boolean readOnly = true; > + private final boolean readOnly; > > // default time stamp for pseudo entries > private final long zfsDefaultTimeStamp = System.currentTimeMillis(); > @@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) { > > // Determining a release version uses 'this' instance to read paths etc. > Optional multiReleaseVersion = determineReleaseVersion(env); > - > - // Set the version-based lookup function for multi-release JARs. > - this.entryLookup = > - multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity()); > - > // We only allow read-write zip/jar files if they are not multi-release > // JARs and the underlying file is writable. > this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); > @@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) { > : "the ZIP file is not writable"; > throw new IOException(reason); > } > + // Set the version-based lookup function for multi-release JARs. > + this.entryLookup = > + multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity()); > + > } > > /** > > > > > With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change. > > Making it `final` and having it not accessed until the ultimate value is set in the constructor would get us past any of t... On second thought, may be this isn't enough. I see that I missed the fact that `determineReleaseVersion()` requires access to `this`. Please leave this in the current form that you have in your PR. I need a few more moments to consider if anything needs to be changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095591964 From jpai at openjdk.org Mon May 19 12:35:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 12:35:58 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. src/jdk.zipfs/share/classes/module-info.java line 290: > 288: * already exist, and is incompatible with {@code "create"=true}. > 289: * Specifying both will cause an {@code IllegalArgumentException} > 290: * to be thrown when the Zip filesystem is created To be precise, perhaps this last sentence should be reworded to: > Specifying {@code create} as {@code true} and {@code accessMode} as {@code readOnly} will cause an {@code IllegalArgumentException} to be thrown when the ZIP filesystem is created. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095608509 From jpai at openjdk.org Mon May 19 12:44:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 12:44:07 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3] In-Reply-To: References: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com> Message-ID: On Thu, 15 May 2025 17:27:42 GMT, David Beaumont wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167: >> >>> 165: return null; >>> 166: } >>> 167: case String label when READ_WRITE.label.equals(label) -> { >> >> I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler: >> >> >> case "readWrite" -> { >> return READ_WRITE; >> } >> case "readOnly" -> { >> return READ_ONLY; >> } > > Or just an if :) > > The reason for the new style was the "need" for the "String label when" qualifier, which I don't actually need because String.equals(xx) copes with being given non-strings fine. You can't use the syntax you suggested in the new switch since "value" isn't a String. Thank you for updating this to a traditional and trivial `if/else`. >> src/jdk.zipfs/share/classes/module-info.java line 277: >> >>> 275: *
    • >>> 276: * A value defining the desired read/write access mode of the file system >>> 277: * (either read-write or read-only). >> >> This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system. >> >> Perhaps we could reword this to something like: >> >>> >>> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access. > > Yeah, I tried to distinguish the accessMode flags (for which there are 3 states, ro, rw, n/a) and the final state of the file system from fs.isReadOnly(). Hence using `...` for whenever the actually resulting state is mentioned. I guess it wasn't clear enough. Thank you for updating this part, this is much more clearer now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095625151 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095622485 From jpai at openjdk.org Mon May 19 12:44:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 12:44:08 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com> On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 210: > 208: } > 209: } > 210: // sm and existence check Nit - this is pre-existing, but would be good to cleanup. The "sm" here refers to SecurityManager. In JDK mainline, the SecurityManager is no longer present. So it would be good to change this comment to just "existence check" and remove reference to "sm". src/jdk.zipfs/share/classes/module-info.java line 304: > 302: * > 303: * > 304: * The access mode has no effect on reported POSIX file permissions (in cases For consistency, I think this should be: > The {@code accessMode} has no .... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095621216 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095616802 From jpai at openjdk.org Mon May 19 12:50:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 12:50:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208: > 206: // Multi-release JARs, when opened with a specified version are inherently read-only. > 207: Path multiReleaseJar = createMultiReleaseJar(); > 208: try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) { I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095637058 From jpai at openjdk.org Mon May 19 12:56:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 12:56:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224: > 222: // Underlying file is read-only. > 223: Path readOnlyZip = Utils.createJarFile("read_only.zip", Map.of("file.txt", "Hello World")); > 224: readOnlyZip.toFile().setReadOnly(); `java.io.File.setReadOnly()` specifies: > On some platforms it may be possible to start the > Java virtual machine with special privileges that allow it to modify > files that are marked read-only. Whether or not a read-only file or > directory may be deleted depends upon the underlying system. So I think we should run the subsequent asserts in this test after first checking if the file was set to read-only. If it isn't then we should skip the test. Something like: final boolean marked = readOnlyZip.toFile().setReadOnly(); Assumptions.assumeTrue(marked, "skipping test since " + readOnlyZip + " couldn't be marked read-only"); assertThrows(IOException.class, () -> FileSystems.newFileSystem(readOnlyZip, Map.of("accessMode", "readWrite"))); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095650541 From jpai at openjdk.org Mon May 19 13:03:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 13:03:00 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. On a general note, all of these updated files will require a copyright year update. test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 239: > 237: assertTrue(fs.isReadOnly()); > 238: if (!"First version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) { > 239: fail("unexpected file content"); Nit, for this and the other new `fail` statements, it might be good to include the unexpected file content in the fail message. If at all the test fails for whatever reason, that additional detail usually help to quickly debug the failures. Or maybe just replace the `if` followed by a `fail` with an `assertEquals()` call. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2890930980 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095657482 From jpai at openjdk.org Mon May 19 13:09:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 13:09:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 10:01:05 GMT, David Beaumont wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test. > > test/jdk/jdk/nio/zipfs/Utils.java line 52: > >> 50: */ >> 51: static Path createJarFile(String name, String... entries) throws IOException { >> 52: Path jarFile = Paths.get(name); > > Previous tests always had the test file called the same thing. > Note that in jtreg tests, the file of the same name often already exists in the test directory. > I tried adding a "ensure file doesn't already exist" check and it fails lots of tests. It's interesting that we have several places in the test which use this `Utils.createJarFile()` and pass it a test specific JAR file name and yet this utility was ignoring the passed name hard coding the name to `basic.jar`. It appears to be an oversight and your fix here I believe is a good thing. > I tried adding a "ensure file doesn't already exist" check and it fails lots of tests. I think it's OK in its current form to allow the file to be overwritten. Plus, you have also updated the javadoc of this test utility method to explicitly state its current behaviour, which I think is enough to let the call sites know how this behaves. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095672596 From jpai at openjdk.org Mon May 19 13:09:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 13:09:57 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. test/jdk/jdk/nio/zipfs/Utils.java line 52: > 50: */ > 51: static Path createJarFile(String name, String... entries) throws IOException { > 52: Path jarFile = Paths.get(name); In recent times we have replaced `Paths.get(...)` call in the JDK code with `Path.of(...)`. We should do the same here and the other line in this utility class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095676145 From jpai at openjdk.org Mon May 19 13:14:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 13:14:58 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. test/jdk/jdk/nio/zipfs/Utils.java line 48: > 46: * > 47: * @param name the file name of the jar file to create in the working directory. > 48: * @param entries a list of JAR entries to be populated with random bytes. Nit - maybe reword this to: > @param entries JAR file entry names, whose content will be populated with random bytes. test/jdk/jdk/nio/zipfs/Utils.java line 78: > 76: * > 77: * @param name the file name of the jar file to create in the working directory. > 78: * @param entries a map of relative file name path strings to file content Nit - I think we should replace this description with something like: > @param entries a map of JAR file entry names to entry content ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095686442 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095684096 From jpai at openjdk.org Mon May 19 13:25:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 13:25:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: <87vFNxeXLspOxvNyBLBbVyAnEMwLSTCokW0o1fItFRM=.27c91bbb-9269-4b12-a443-8070dd61048f@github.com> On Mon, 19 May 2025 12:15:38 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test. test/jdk/jdk/nio/zipfs/TestPosix.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2025, SAP SE. All rights reserved. For non-Oracle copyright lines like these, we don't edit them and instead we introduce a newline for the Oracle copyright year. So we should revert the change to this line and introduce the following new line just after this current one: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095707195 From swen at openjdk.org Mon May 19 13:32:55 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 19 May 2025 13:32:55 GMT Subject: RFR: 8357081: Removed unused methods of HexDigits In-Reply-To: References: Message-ID: On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen wrote: > In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods The getCharsLatin1/getCharsUTF16 methods of HexDigits may be used in j.u.Formatter/HexFormat in the future. For this reason, should we keep them? @cl4es ------------- PR Comment: https://git.openjdk.org/jdk/pull/25258#issuecomment-2891047804 From duke at openjdk.org Mon May 19 13:33:56 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 13:33:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com> References: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com> Message-ID: On Mon, 19 May 2025 12:39:22 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 210: > >> 208: } >> 209: } >> 210: // sm and existence check > > Nit - this is pre-existing, but would be good to cleanup. The "sm" here refers to SecurityManager. In JDK mainline, the SecurityManager is no longer present. So it would be good to change this comment to just "existence check" and remove reference to "sm". Done. > src/jdk.zipfs/share/classes/module-info.java line 290: > >> 288: * already exist, and is incompatible with {@code "create"=true}. >> 289: * Specifying both will cause an {@code IllegalArgumentException} >> 290: * to be thrown when the Zip filesystem is created > > To be precise, perhaps this last sentence should be reworded to: > >> Specifying {@code create} as {@code true} and {@code accessMode} as {@code readOnly} will cause an {@code IllegalArgumentException} to be thrown when the ZIP filesystem is created. Done. > src/jdk.zipfs/share/classes/module-info.java line 304: > >> 302: * >> 303: * >> 304: * The access mode has no effect on reported POSIX file permissions (in cases > > For consistency, I think this should be: > >> The {@code accessMode} has no .... Done. > test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208: > >> 206: // Multi-release JARs, when opened with a specified version are inherently read-only. >> 207: Path multiReleaseJar = createMultiReleaseJar(); >> 208: try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) { > > I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file. It does throw if accessMode=readWrite and the result is not writable for any reason. this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); if (readOnly && accessMode == ZipAccessMode.READ_WRITE) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095718428 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095714913 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095715684 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095723172 From duke at openjdk.org Mon May 19 13:39:03 2025 From: duke at openjdk.org (kieran-farrell) Date: Mon, 19 May 2025 13:39:03 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 Message-ID: With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: - random-byte-only - 99.8% - higher-precision - 3.5% - counter-based - 0% Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: - random-byte-only 143.487 ? 10.932 ns/op - higher-precision 149.651 ? 8.438 ns/op - counter-based 245.036 ? 2.943 ns/op The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. ------------- Commit messages: - update to add ns percision - 3 variantions - UUID src and test Changes: https://git.openjdk.org/jdk/pull/25303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334015 Stats: 108 lines in 2 files changed: 104 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From jpai at openjdk.org Mon May 19 13:43:04 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 13:43:04 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com> Message-ID: On Mon, 19 May 2025 13:31:04 GMT, David Beaumont wrote: >> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208: >> >>> 206: // Multi-release JARs, when opened with a specified version are inherently read-only. >>> 207: Path multiReleaseJar = createMultiReleaseJar(); >>> 208: try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) { >> >> I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file. > > It does throw if accessMode=readWrite and the result is not writable for any reason. > > > this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); > if (readOnly && accessMode == ZipAccessMode.READ_WRITE) { Actually looking at the current proposed implementation in ZipFileSystem where we have: this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); if (readOnly && accessMode == ZipAccessMode.READ_WRITE) { String reason = multiReleaseVersion.isPresent() ? "the multi-release JAR file is not writable" : "the ZIP file is not writable"; throw new IOException(reason); } I'm surprised this test currently passes. Shouldn't this line in the test lead to an `IOException`: FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) Did I misread something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095732163 From duke at openjdk.org Mon May 19 13:43:07 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 13:43:07 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:58:00 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test. > > test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 239: > >> 237: assertTrue(fs.isReadOnly()); >> 238: if (!"First version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) { >> 239: fail("unexpected file content"); > > Nit, for this and the other new `fail` statements, it might be good to include the unexpected file content in the fail message. If at all the test fails for whatever reason, that additional detail usually help to quickly debug the failures. Or maybe just replace the `if` followed by a `fail` with an `assertEquals()` call. Urgh, my bad. That's the hangover from these tests being first implemented in the ZipFSTester class without access to sensible assert methods. > test/jdk/jdk/nio/zipfs/TestPosix.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, 2025, SAP SE. All rights reserved. > > For non-Oracle copyright lines like these, we don't edit them and instead we introduce a newline for the Oracle copyright year. So we should revert the change to this line and introduce the following new line just after this current one: > > * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Thanks! Done. > test/jdk/jdk/nio/zipfs/Utils.java line 48: > >> 46: * >> 47: * @param name the file name of the jar file to create in the working directory. >> 48: * @param entries a list of JAR entries to be populated with random bytes. > > Nit - maybe reword this to: > >> @param entries JAR file entry names, whose content will be populated with random bytes. Done. > test/jdk/jdk/nio/zipfs/Utils.java line 52: > >> 50: */ >> 51: static Path createJarFile(String name, String... entries) throws IOException { >> 52: Path jarFile = Paths.get(name); > > In recent times we have replaced `Paths.get(...)` call in the JDK code with `Path.of(...)`. We should do the same here and the other line in this utility class. Good spot, thanks. Sadly I'm currently working on other code in which Path.of() is not permitted, so I won't naturally spot these things. > test/jdk/jdk/nio/zipfs/Utils.java line 78: > >> 76: * >> 77: * @param name the file name of the jar file to create in the working directory. >> 78: * @param entries a map of relative file name path strings to file content > > Nit - I think we should replace this description with something like: > >> @param entries a map of JAR file entry names to entry content Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095730823 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095740846 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095740347 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095735890 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095738222 From duke at openjdk.org Mon May 19 13:46:16 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 13:46:16 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v7] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Changes based on feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/ea781c16..46b19106 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=05-06 Stats: 26 lines in 5 files changed: 6 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From vromero at openjdk.org Mon May 19 13:47:50 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 May 2025 13:47:50 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v17] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/def2505f..cf92614c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=15-16 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From jpai at openjdk.org Mon May 19 14:04:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 14:04:08 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com> Message-ID: On Mon, 19 May 2025 13:35:37 GMT, Jaikiran Pai wrote: > Did I misread something? I missed the fact that for a multi-release JAR file, we mark the file system as read-only, only if the `multi-release` or the `releaseVersion` environment properties have been set. So in this test here, the file system can indeed be opened in read-write mode. Sorry about the noise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095779244 From duke at openjdk.org Mon May 19 14:04:08 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 14:04:08 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v8] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Changes based on feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/46b19106..3b3fe2d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=06-07 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From duke at openjdk.org Mon May 19 14:04:09 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 14:04:09 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:54:37 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test. > > test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224: > >> 222: // Underlying file is read-only. >> 223: Path readOnlyZip = Utils.createJarFile("read_only.zip", Map.of("file.txt", "Hello World")); >> 224: readOnlyZip.toFile().setReadOnly(); > > `java.io.File.setReadOnly()` specifies: > >> On some platforms it may be possible to start the >> Java virtual machine with special privileges that allow it to modify >> files that are marked read-only. Whether or not a read-only file or >> directory may be deleted depends upon the underlying system. > > So I think we should run the subsequent asserts in this test after first checking if the file was set to read-only. If it isn't then we should skip the test. Something like: > > > final boolean marked = readOnlyZip.toFile().setReadOnly(); > Assumptions.assumeTrue(marked, "skipping test since " + readOnlyZip + " couldn't be marked read-only"); > assertThrows(IOException.class, > () -> FileSystems.newFileSystem(readOnlyZip, Map.of("accessMode", "readWrite"))); Done. Thanks for introducing me to the Assumptions class :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095780258 From cay.horstmann at gmail.com Mon May 19 14:12:55 2025 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Mon, 19 May 2025 16:12:55 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <52514642-e172-4096-a616-a2c9a9787552@gmail.com> <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <5cffce95-71ab-40a8-87ec-edeb774e9890@gmail.com> Il 19/05/25 10:13, Remi Forax ha scritto: >> If only there was some deconstruction magic that approximates the JavaScript >> code >> >> const doc = { name: "John", age: 30 } >> const { name, age } = doc > > We already have that, it's called a record :) > > Basically, you are advocating for a mapping JsonObject <--> record. > > [...] > >> >> Cheers, >> >> Cay >> > > Here is a simple JsonObject mapper using java.util.json types. > https://github.com/forax/json-object-mapper That's interesting, but I don't think it works as a solution to read generic JSON. I have to deal with much JSON that is at best semi-structured. And anyway, databinding is is excluded from the scope of the core Java JSON API. Let me explain in more detail what I was trying say offhandedly. For tree traversal, Jackson has isXxx, asXxx, get, path (for "safe" chaining), and JSON Pointer support. The core Java JSON library proposes to rely on pattern matching instead. With the capabilities of pattern matching today, that is unappealing. Could it get better with some of the ideas in https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns? Let's assume we have a factory method var doc = JsonObject.of("name", JsonString.of("John"), "age", JsonNumber.of(30)); Could there be a matching deconstructor? It couldn't be overloads like public inverse JsonObject of(String key1, JsonValue value1, String key2, JsonValue value2) The deconstructor could not know which entries to pick and in what order. But similar to the regex example in the design note, one could define a "pattern object" holding the keys: case JsonObject.withKeys("name", "age").of(JsonString.of(String name), JsonNumber.of(long age)) -> Maybe even: case JsonObject.withKeys("name", "age").fromUntyped(String name, Long age) -> With nested objects: case JsonObject.withKeys("user").of( JsonObject.withKeys("name", "age").fromUntyped(String name, Long age)) -> { /* use name, age */ } default -> /* deal with error */ I made some impromptu design decisions to get this far, as well as assumptions how deconstruction would eventually work. Which may well be wrong. In Jackson, it would be try { JsonNode user = nestedDoc.get("user"); String name = user.get("name").asText(); int age = user.get("age").asInt(); /* use name, age */ } catch (...) { /* deal with error */ } At first I thought the pattern matching version would be worse, but I admit that the structural safety is appealing. Cheers, Cay -- Cay S. Horstmann | https://horstmann.com From snazy at snazy.de Mon May 19 14:34:35 2025 From: snazy at snazy.de (Robert Stupp) Date: Mon, 19 May 2025 16:34:35 +0200 Subject: ClassLoader.definePackage() throwing IllegalArgumentException Message-ID: <8c837531-0bb5-4456-8042-5bc024d38542@snazy.de> Hi, I'd like to follow up on https://bugs.openjdk.org/browse/JDK-8350547. TL;DR java.lang.ClassLoader.definePackage() (the one taking 8 arguments) clearly defines that a IllegalArgumentException is thrown, "if a package of the given name is already defined by this class loader". However, it seems that it's a common oversight that an IAE can be thrown. Examples are the CDI reference implementation ("Weld") and Quarkus. In other words: "naively" calling 'definePackage' without a retry on IAE leads to issues when defining classes in custom class loaders in parallel. The CL.definePackage() API is there since Java 1.2, and I admit that my initial approach to change the currently observed behavior isn't going to fly. I thought about adding more information to the message of the IAE thrown in 'definePackage()', but even this "innocent" change could break the observed behavior / existing code. One option could be to add a new function 'definePackageIfNotExists()` to j.l.ClassLoader, which works like the existing 'definePackage()' but returns the existing package, if it already exists and is compatible with the given arguments. The downside is that it could still throw, if the arguments are incompatible (e.g. a different "implTitle") - so it might just be a less likely, but still possible way of unexpectedly hitting an IAE. With 'definePackageIfNotExists()` it might be possible to deprecate 'definePackage()', but that deprecation largely depends on the actual usage of it in the wild, which I do not know. I'm not sure whether such a deprecation can fly. And the next question would be whether it can be deprecated for removal ; and if yes, when could it be removed. Actually, even a new 'definePackageIfNotExists()` could break existing code, in case an implementation overrides the existing 'definePackage' but not 'definePackageIfNotExists()`. Another question to which I don't know the answer is whether the 7 package attribute parameters specification/implementation title/version/vendor + seal-base do fit "all today's wishes & needs". Or: is there demand for a "better" or "more flexible" way to define a class/package? Or: can that API be redefined in a different way tailored for today's needs and wishes? And are there any that would justify such an effort? Overall, I'm a bit lost on what the "best" way would be for this. Maybe the answer is that there is no better way yet, which is also fine. Maybe the only "fix" is to enhance the Javadocs and prominently highlight the behavior and add a "reference code snippet" how 'definePackage()' should be used and why. Robert -- Robert Stupp @snazy From vromero at openjdk.org Mon May 19 14:35:40 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 May 2025 14:35:40 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v18] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Merge branch 'master' into JDK-8354556 - review comments - addressing review comments - addressing review comments - update warning message - Merge branch 'master' into JDK-8354556 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java Co-authored-by: Chen Liang - additional changes from Archie - removing dead code - integrating code from Archie - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd ------------- Changes: https://git.openjdk.org/jdk/pull/24746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=17 Stats: 647 lines in 32 files changed: 562 ins; 37 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From forax at univ-mlv.fr Mon May 19 14:54:46 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 19 May 2025 16:54:46 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: <5cffce95-71ab-40a8-87ec-edeb774e9890@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <52514642-e172-4096-a616-a2c9a9787552@gmail.com> <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr> <5cffce95-71ab-40a8-87ec-edeb774e9890@gmail.com> Message-ID: <1366070687.269600941.1747666486192.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "cay horstmann" > To: "Remi Forax" > Cc: "core-libs-dev" > Sent: Monday, May 19, 2025 4:12:55 PM > Subject: Re: Towards a JSON API for the JDK > Il 19/05/25 10:13, Remi Forax ha scritto: >>> If only there was some deconstruction magic that approximates the JavaScript >>> code >>> >>> const doc = { name: "John", age: 30 } >>> const { name, age } = doc >> >> We already have that, it's called a record :) >> >> Basically, you are advocating for a mapping JsonObject <--> record. >> >> [...] >> >>> >>> Cheers, >>> >>> Cay >>> >> >> Here is a simple JsonObject mapper using java.util.json types. >> https://github.com/forax/json-object-mapper > > That's interesting, but I don't think it works as a solution to read generic > JSON. I have to deal with much JSON that is at best semi-structured. And > anyway, databinding is is excluded from the scope of the core Java JSON API. If the mapping is driven by the record definition then mapping and matching are mostly equivalent, mapping throws exceptions when something goes wrong while matching returns something saying no-match. Here is an example, record Person(String name, int age) {} var recordMapper = RecordMapper.of(MethodHandles.lookup()); JsonObject json = ... if (recordMapper.match(json, Person.class) instanceof Person(String name, int age)) { // can use name and age here } see https://github.com/forax/json-object-mapper/blob/master/src/test/java/json/RecordMapperTest.java#L40 [...] > > At first I thought the pattern matching version would be worse, but I admit that > the structural safety is appealing. I agree. > > Cheers, > > Cay R?mi From acobbs at openjdk.org Mon May 19 15:01:55 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 19 May 2025 15:01:55 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface In-Reply-To: References: Message-ID: On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote: > I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. IMHO it makes sense. It's the min/max analog to a stable sort. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2891353170 From rgiulietti at openjdk.org Mon May 19 15:06:56 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 19 May 2025 15:06:56 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v8] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Fri, 16 May 2025 11:10:12 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > An optimization src/java.base/share/classes/java/math/BigInteger.java line 5034: > 5032: */ > 5033: private byte[] magSerializedForm() { > 5034: byte[] result = new byte[(magBitLength() + 7) >>> 3]; I think there's a risk of overflow, so consider Suggestion: byte[] result = new byte[(magBitLength() - 1 >>> 3) + 1]; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2095920641 From rgiulietti at openjdk.org Mon May 19 15:06:57 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 19 May 2025 15:06:57 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v8] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Mon, 19 May 2025 15:02:57 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> An optimization > > src/java.base/share/classes/java/math/BigInteger.java line 5034: > >> 5032: */ >> 5033: private byte[] magSerializedForm() { >> 5034: byte[] result = new byte[(magBitLength() + 7) >>> 3]; > > I think there's a risk of overflow, so consider > Suggestion: > > byte[] result = new byte[(magBitLength() - 1 >>> 3) + 1]; Ah no, there's a unsigned shift `>>>`. Disregard ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2095922459 From forax at univ-mlv.fr Mon May 19 15:16:38 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 May 2025 17:16:38 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> Okay, i've taken a look to the design and this is not pretty. The main issue is that the javadoc claims that "Both JsonValue instances and their underlying values are immutable." but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation. Because the hierarchy is non sealed, it also means that it is easy to create JsonValue that are invalid, for example var funJsonNumber = new JsonNumber() { public Number toNumber () { return Double . NaN ; } public BigDecimal toBigDecimal () { throw new UnsupportedOperationException(); } public String toString () { return "NaN" ; } }; var json = Json.fromUntyped( List . of ( funJsonNumber )); For me, the Json hierarchy should be implemented with true ADTs, with all subtypes of JsonValue being records. regards, R?mi > From: "Remi Forax" > To: "Brian Goetz" > Cc: "Paul Sandoz" , "core-libs-dev" > > Sent: Friday, May 16, 2025 8:42:47 PM > Subject: Re: Towards a JSON API for the JDK >> From: "Brian Goetz" >> To: "Remi Forax" >> Cc: "Paul Sandoz" , "core-libs-dev" >> >> Sent: Friday, May 16, 2025 7:46:09 PM >> Subject: Re: Towards a JSON API for the JDK >> If you read the implementation, you'll see that significant laziness is indeed >> possible for JsonObject and JsonArray, even while doing eager validation. (Of >> course, one can shift the balance to achieve various other tradeoffs.) > Reading the implementation is on my TODO list :) > R?mi >> On 5/16/2025 10:35 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >>> ----- Original Message ----- >>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | ] >>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | ] , "Paul >>>> Sandoz" [ mailto:paul.sandoz at oracle.com | ] Cc: >>>> "core-libs-dev" [ mailto:core-libs-dev at openjdk.org | >>>> ] Sent: Friday, May 16, 2025 2:53:18 PM >>>> Subject: Re: Towards a JSON API for the JDK >>>> On 5/15/2025 5:27 PM, Remi Forax wrote: >>>>> It's not clear to me why JsonArray (for example) has to be an interface instead >>>>> of a record ? >>>> Oh, you know the answer to this.? A record limits us to a single >>>> implementation with a rigid representation.? Behind an interface, we can >>>> hide lazy parsing and inflation, wrapping other representations to >>>> reduce copies, etc. >>> First, let me refine the question. >>> There are only 4 kinds of JSON values that benefit from having different >>> representations, object, array, string and number. >>> For object and array, both takes an interface as parameter (Map or List) so >>> JsonArray and JSonObject do not need to be themselves interfaces. >>> So the only values where it may be worth to be modeled using an interface are >>> JsonString and JsonNumber, because as you said, you can do "lazy" parsing. >>> But delaying the parsing of the content has the side effect that even if >>> Json.parse() did not throw an exception, it does not mean that the JSON text is >>> valid, an exception may be thrown later. >>> Now, for me, this library is more about being simple and safe than fast. >>> If you agree with that, delaying the parsing is not a good idea, thus JSON >>> values should be modeled using records and not interfaces. >>> regards, >>> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon May 19 15:18:12 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 May 2025 15:18:12 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v9] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Don't use JUnit utils in TestNg. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/3b3fe2d7..e5725599 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=07-08 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From duke at openjdk.org Mon May 19 15:21:58 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 19 May 2025 15:21:58 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v8] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Mon, 19 May 2025 15:03:51 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 5034: >> >>> 5032: */ >>> 5033: private byte[] magSerializedForm() { >>> 5034: byte[] result = new byte[(magBitLength() + 7) >>> 3]; >> >> I think there's a risk of overflow, so consider >> Suggestion: >> >> byte[] result = new byte[(magBitLength() - 1 >>> 3) + 1]; > > Ah no, there's a unsigned shift `>>>`. > Disregard Indeed, I had thought about this possibility too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2095957646 From bpb at openjdk.org Mon May 19 15:22:53 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 19 May 2025 15:22:53 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v4] In-Reply-To: References: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> Message-ID: <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com> On Fri, 16 May 2025 17:22:14 GMT, Brian Burkhalter wrote: >> I guess collapsing the tests made them more ambiguous. Will fix. > > Split the test method in half for Unix and Windows in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427). > The behavior and system property is Windows specific and might make things simpler to make it a Windows only test. I think I might have misunderstood this comment. Was the intent to make this test use `@requires os.family == "windows"`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2095962959 From rriggs at openjdk.org Mon May 19 15:52:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 15:52:52 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) In-Reply-To: References: Message-ID: On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe wrote: > For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. > > We plan to deprecate this in JDK 25 and to remove it in JDK 26. > > This patch just writes a deprecation message to stderr: > > > 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls > VFORK MODE DEPRECATED > The VFORK launch mechanism has been deprecated for being dangerous. > It will be removed in a future java version. Either remove the > jdk.lang.Process.launchMechanism property (preferred) or use FORK mode > instead (-Djdk.lang.Process.launchMechanism=FORK). > ... lgtm; thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25282#pullrequestreview-2851284733 From rgiulietti at openjdk.org Mon May 19 15:53:10 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 19 May 2025 15:53:10 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Fri, 16 May 2025 13:30:01 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 3860: >> >>> 3858: && Integer.lowestOneBit(mag[0]) == mag[0] >>> 3859: && numberOfTrailingZeroInts() == mag.length - 1 >>> 3860: ? magBitLength() - 1 : magBitLength(); >> >> Suggestion: >> >> int[] mag = this.mag; >> return magBitLength() >> - (signum < 0 >> // Check if magnitude is a power of two >> && Integer.lowestOneBit(mag[0]) == mag[0] >> && numberOfTrailingZeroInts() == mag.length - 1 >> ? 1 : 0); >> >> >> In this way, codeSize will drop from 52 to 45 > > What is the usefulness of doing `int[] mag = this.mag;` at line 3856, since `bitLength()` does not access to `static` fields and `BigInteger` is not threadsafe, and therefore no race conditions occur? I think the suggestion is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096038516 From duke at openjdk.org Mon May 19 15:53:10 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 19 May 2025 15:53:10 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v9] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Removed numberOfTrailingZeros() as a duplicate of the cached getLowestSetBit() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/b151b7e3..b74fefa5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=07-08 Stats: 18 lines in 1 file changed: 5 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From alanb at openjdk.org Mon May 19 15:59:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 May 2025 15:59:59 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v4] In-Reply-To: <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com> References: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com> Message-ID: On Mon, 19 May 2025 15:20:25 GMT, Brian Burkhalter wrote: >> Split the test method in half for Unix and Windows in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427). > >> The behavior and system property is Windows specific and might make things simpler to make it a Windows only test. > > I think I might have misunderstood this comment. Was the intent to make this test use `@requires os.family == "windows"`? I think that would be simpler and means the `@EnabledOnOs` usages would go away, but it's up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2096050597 From alanb at openjdk.org Mon May 19 16:01:25 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 May 2025 16:01:25 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) In-Reply-To: References: Message-ID: <2QsUpYlpfhTSliyQQJ_vwPBiCErV4MjOIfyNeefES3E=.748e86cc-9d47-4744-9e1b-14375881a392@github.com> On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe wrote: > For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. > > We plan to deprecate this in JDK 25 and to remove it in JDK 26. > > This patch just writes a deprecation message to stderr: > > > 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls > VFORK MODE DEPRECATED > The VFORK launch mechanism has been deprecated for being dangerous. > It will be removed in a future java version. Either remove the > jdk.lang.Process.launchMechanism property (preferred) or use FORK mode > instead (-Djdk.lang.Process.launchMechanism=FORK). > ... src/java.base/unix/classes/java/lang/ProcessImpl.java line 111: > 109: "It will be removed in a future java version. Either remove the\n" + > 110: "jdk.lang.Process.launchMechanism property (preferred) or use FORK mode\n" + > 111: "instead (-Djdk.lang.Process.launchMechanism=FORK)."); This is okay although I could imagine someone wanting to replace this with a text block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25282#discussion_r2096052329 From jlahoda at openjdk.org Mon May 19 16:02:00 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 16:02:00 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v18] In-Reply-To: References: Message-ID: <4WJiJCaO8Kf9FzD4YX0nP13CoVOcDw9wePKvBVyaQw8=.81f09b20-763c-4e6b-a0ff-a12167e0644c@github.com> On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Merge branch 'master' into JDK-8354556 > - review comments > - addressing review comments > - addressing review comments > - update warning message > - Merge branch 'master' into JDK-8354556 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang > - additional changes from Archie > - removing dead code > - integrating code from Archie > - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd javac changes look good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2851310025 From nbenalla at openjdk.org Mon May 19 16:08:02 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 16:08:02 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base Message-ID: Please review this patch to fix some `javadoc` bugs in `java.base`. Certain `@link` tags used to refer to private fields instead of public APIs. A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. TIA ------------- Commit messages: - respond to feedback - fix incorrect `@link` tags Changes: https://git.openjdk.org/jdk/pull/25287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356632 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287 PR: https://git.openjdk.org/jdk/pull/25287 From liach at openjdk.org Mon May 19 16:08:03 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 May 2025 16:08:03 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893: > 4891: * @return a constant method handle of the given type, which returns a default value of the given return type > 4892: * @throws NullPointerException if the argument is null > 4893: * @see primitiveZero(Wrapper) Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant. src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341: > 1339: * @throws ClassNotFoundException if one of the component classes cannot be resolved > 1340: * @see MethodType.readResolve() > 1341: * @see MethodType.writeObject(ObjectOutputStream s) This is already not generated by the javadoc as this method is private. Why is this check against a private method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316583 PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316628 From duke at openjdk.org Mon May 19 16:08:04 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 19 May 2025 16:08:04 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sun, 18 May 2025 02:17:46 GMT, Chen Liang wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893: > >> 4891: * @return a constant method handle of the given type, which returns a default value of the given return type >> 4892: * @throws NullPointerException if the argument is null >> 4893: * @see primitiveZero(Wrapper) > > Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant. From?: Suggestion: * @see MethodHandles#zero ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094592478 From nbenalla at openjdk.org Mon May 19 16:08:04 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 16:08:04 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sun, 18 May 2025 02:18:24 GMT, Chen Liang wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341: > >> 1339: * @throws ClassNotFoundException if one of the component classes cannot be resolved >> 1340: * @see MethodType.readResolve() >> 1341: * @see MethodType.writeObject(ObjectOutputStream s) > > This is already not generated by the javadoc as this method is private. Why is this check against a private method? They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2095501605 From duke at openjdk.org Mon May 19 16:15:59 2025 From: duke at openjdk.org (duke) Date: Mon, 19 May 2025 16:15:59 GMT Subject: Withdrawn: 8349545: ClassLoader.definePackage() throws IllegalArgumentException if package already defined In-Reply-To: References: Message-ID: On Sun, 23 Feb 2025 11:32:41 GMT, Robert Stupp wrote: > Concurent calls to `ClassLoader.definePackage()` can yield `IllegalArgumentException`s if the package is already defined. Some built-in class loaders, like `URLClassLoader`, already handle this case, but custom class loaders (would) have to handle this case. > > This change updates the logic of `CL.definePackage` to not throw an IAE if the "redefined" package is equal to the already defined one. > > Tests added in `jdk/java/lang/Package/PackageDefineTest.java` (+ pulling up the `TestClassLoader` from `PackageDefineTest`). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23737 From darcy at openjdk.org Mon May 19 16:20:50 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 19 May 2025 16:20:50 GMT Subject: RFR: 8357178: Simplify Class::componentType [v2] In-Reply-To: References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: On Sun, 18 May 2025 21:15:21 GMT, Chen Liang wrote: > > Did you consider calling getComponentType(), which already returns the field? > > I don't think we want an extra indirection here - The logic here is quite simple. Counterargument could be that `MethodType::descriptorString` calls `toMethodDescriptorString`, except these methods involve more complex caching and is not simple like this field access. My mental model anyway is that this trivial inline would be something the VM would do readily. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25280#discussion_r2096089013 From alanb at openjdk.org Mon May 19 16:42:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 May 2025 16:42:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v9] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 15:18:12 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Don't use JUnit utils in TestNg. src/jdk.zipfs/share/classes/module-info.java line 264: > 262: * {@linkplain Runtime.Version Java SE Platform version number}, > 263: * an {@code IllegalArgumentException} will be thrown when the Zip > 264: * filesystem is created. I think this needs to "when creating the ZIP file system". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096125703 From alanb at openjdk.org Mon May 19 16:49:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 May 2025 16:49:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v9] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 15:18:12 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Don't use JUnit utils in TestNg. src/jdk.zipfs/share/classes/module-info.java line 288: > 286: * isReadOnly()} will always return {@code true}. Creating a > 287: * read-only file system requires the underlying ZIP file to > 288: * already exist, and is incompatible with {@code "create"=true}. I think it would be clearer to drop "and is incompatible with {@code "create"=true}". The sentence that follows makes it clear that accessMode=readWrite && create=true cause IAE to be thrown. src/jdk.zipfs/share/classes/module-info.java line 291: > 289: * Specifying {@code create} as {@code true} and {@code accessMode} as > 290: * {@code readOnly} will cause an {@code IllegalArgumentException} > 291: * to be thrown when the ZIP filesystem is created. "created" sounds past tense, so making it "when creating the ZIP file system" would work better here. Same comment on the text further down. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096133967 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096134802 From smarks at openjdk.org Mon May 19 16:56:00 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 19 May 2025 16:56:00 GMT Subject: Integrated: 8351230: Collections.synchronizedList returns a list that is not thread-safe In-Reply-To: References: Message-ID: On Thu, 1 May 2025 19:05:50 GMT, Stuart Marks wrote: > Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper: > > - overrides and adds locking to SequencedCollection methods; > - performs instance management of reversed synchronized views; > - adds test for race conditions and functional tests of synchronized wrappers. This pull request has now been integrated. Changeset: 6818dcc0 Author: Stuart Marks URL: https://git.openjdk.org/jdk/commit/6818dcc08ed85e220c5206fda5c991b886e35334 Stats: 260 lines in 3 files changed: 247 ins; 9 del; 4 mod 8351230: Collections.synchronizedList returns a list that is not thread-safe Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/24990 From stuefe at openjdk.org Mon May 19 16:59:06 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 19 May 2025 16:59:06 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) [v2] In-Reply-To: References: Message-ID: > For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. > > We plan to deprecate this in JDK 25 and to remove it in JDK 26. > > This patch just writes a deprecation message to stderr: > > > 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls > VFORK MODE DEPRECATED > The VFORK launch mechanism has been deprecated for being dangerous. > It will be removed in a future java version. Either remove the > jdk.lang.Process.launchMechanism property (preferred) or use FORK mode > instead (-Djdk.lang.Process.launchMechanism=FORK). > ... Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: use string block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25282/files - new: https://git.openjdk.org/jdk/pull/25282/files/8bd4a36e..ec3197f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25282&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25282&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25282/head:pull/25282 PR: https://git.openjdk.org/jdk/pull/25282 From stuefe at openjdk.org Mon May 19 16:59:06 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 19 May 2025 16:59:06 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) [v2] In-Reply-To: <2QsUpYlpfhTSliyQQJ_vwPBiCErV4MjOIfyNeefES3E=.748e86cc-9d47-4744-9e1b-14375881a392@github.com> References: <2QsUpYlpfhTSliyQQJ_vwPBiCErV4MjOIfyNeefES3E=.748e86cc-9d47-4744-9e1b-14375881a392@github.com> Message-ID: On Mon, 19 May 2025 15:58:17 GMT, Alan Bateman wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> use string block > > src/java.base/unix/classes/java/lang/ProcessImpl.java line 111: > >> 109: "It will be removed in a future java version. Either remove the\n" + >> 110: "jdk.lang.Process.launchMechanism property (preferred) or use FORK mode\n" + >> 111: "instead (-Djdk.lang.Process.launchMechanism=FORK)."); > > This is okay although I could imagine someone wanting to replace this with a text block. okay, changed to string block ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25282#discussion_r2096149401 From rgiulietti at openjdk.org Mon May 19 17:08:50 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 19 May 2025 17:08:50 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface In-Reply-To: References: Message-ID: On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote: > Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: > https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html > The specification is mostly composed of Math.min/max and Collections.min/max specifications. > > The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. > > I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. @amaembo Could you please switch the test class to make use of [JUnit](https://junit.org/junit5/)? For new tests we now prefer JUnit over TestNG. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2891719275 From bpb at openjdk.org Mon May 19 17:10:50 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 19 May 2025 17:10:50 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v7] In-Reply-To: References: Message-ID: > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355954: Make test Windows-only ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24977/files - new: https://git.openjdk.org/jdk/pull/24977/files/9fa45418..74e16983 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=05-06 Stats: 16 lines in 1 file changed: 1 ins; 14 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977 PR: https://git.openjdk.org/jdk/pull/24977 From bpb at openjdk.org Mon May 19 17:10:51 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 19 May 2025 17:10:51 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v4] In-Reply-To: References: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com> <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com> Message-ID: On Mon, 19 May 2025 15:57:14 GMT, Alan Bateman wrote: > I think that would be simpler and means the `@EnabledOnOs` usages would go away, but it's up to you. I agree that is better. So changed in [74e1698](https://github.com/openjdk/jdk/pull/24977/commits/74e16983c94d9b29c91b660e8a025388d72aee71). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2096163983 From jd at civilian-framework.org Mon May 19 17:15:41 2025 From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=) Date: Mon, 19 May 2025 19:15:41 +0200 Subject: Towards a JSON API for the JDK Message-ID: Developers use JSON libraries like Fastjson, Jackson and Gson primarily (my claim) because they can marshal between JSON files and POJOs in one line of code with great performance and can easily tweak the mapping using annotations or adapter classes. Being able to read/write a JSON file from/to a generic tree of JsonValues might have use-cases, but manually implementing data-binding based one tree traversal w/wo pattern matching will produce bloated and fragile code (my claim). So my question is if there are plans to address data-binding in the future and how it would relate to the envisioned core API. Thanks Johannes > # Towards a JSON API for the JDK > > One of the most common requests for the JDK is an API for parsing and generating > JSON. While JSON originated as a text-based serialization format for JSON > objects ("JSON" stands for "JavaScript Object Notation"), because of its simple > and flexible syntax, it eventually found use outside the JavaScript ecosystem as > a general data interchange format, such as framework configuration files and web > service requests/response formats. > > While the JDK cannot, and should not, provide libraries for every conceivable > file format or protocol, the JDK philosophy is one of "batteries included", > which is to say we should be able to write basic programs that use common > protocols such as HTTP, without having to appeal to third party libraries. > The Java ecosystem already has plenty of JSON libraries, so inclusion in > the JDK is largely meant to be a convenience, rather than needing to be the "one > true" JSON library to meet the needs of all users. Users with specific needs > are always free to select one of the existing third-party libraries. > > ## Goals and requirements > > Our primary goal is that the library be simple to use for parsing, traversing, > and generating conformant JSON documents. Advanced features, such as data > binding or path-based traversal should be possible to implement as layered > features, but for simplicity are not included in the core API. We adopt a goal > that the performance should be "good enough", but where performance > considerations conflict with simplicity and usability, we will choose in favor > of the latter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Mon May 19 17:17:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 17:17:59 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe wrote: >> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. >> >> We plan to deprecate this in JDK 25 and to remove it in JDK 26. >> >> This patch just writes a deprecation message to stderr: >> >> >> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls >> VFORK MODE DEPRECATED >> The VFORK launch mechanism has been deprecated for being dangerous. >> It will be removed in a future java version. Either remove the >> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode >> instead (-Djdk.lang.Process.launchMechanism=FORK). >> ... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > use string block Marked as reviewed by rriggs (Reviewer). Looks good, also reviewed the CSR, it can be finalized. ------------- PR Review: https://git.openjdk.org/jdk/pull/25282#pullrequestreview-2851506982 PR Comment: https://git.openjdk.org/jdk/pull/25282#issuecomment-2891742547 From duke at openjdk.org Mon May 19 17:19:53 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 19 May 2025 17:19:53 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com> On Mon, 19 May 2025 15:50:10 GMT, Raffaello Giulietti wrote: >> What is the usefulness of doing `int[] mag = this.mag;` at line 3856, since `bitLength()` does not access to `static` fields and `BigInteger` is not threadsafe, and therefore no race conditions occur? > > I think the suggestion is fine. Yes, but perhaps in the current version it's more clear what is the returned value according to the condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096183726 From alan.bateman at oracle.com Mon May 19 17:20:36 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 19 May 2025 18:20:36 +0100 Subject: ClassLoader.definePackage() throwing IllegalArgumentException In-Reply-To: <8c837531-0bb5-4456-8042-5bc024d38542@snazy.de> References: <8c837531-0bb5-4456-8042-5bc024d38542@snazy.de> Message-ID: <0128fdaa-126b-44b8-8f01-1bb2f0935469@oracle.com> On 19/05/2025 15:34, Robert Stupp wrote: > Hi, > > I'd like to follow up on https://bugs.openjdk.org/browse/JDK-8350547. > > TL;DR java.lang.ClassLoader.definePackage() (the one taking 8 > arguments) clearly defines that a IllegalArgumentException is thrown, > "if a package of the given name is already defined by this class loader". > > However, it seems that it's a common oversight that an IAE can be > thrown. Examples are the CDI reference implementation ("Weld") and > Quarkus. In other words: "naively" calling 'definePackage' without a > retry on IAE leads to issues when defining classes in custom class > loaders in parallel. > > The CL.definePackage() API is there since Java 1.2, and I admit that > my initial approach to change the currently observed behavior isn't > going to fly. > > I thought about adding more information to the message of the IAE > thrown in 'definePackage()', but even this "innocent" change could > break the observed behavior / existing code. > > One option could be to add a new function 'definePackageIfNotExists()` > to j.l.ClassLoader, which works like the existing 'definePackage()' > but returns the existing package, if it already exists and is > compatible with the given arguments. The downside is that it could > still throw, if the arguments are incompatible (e.g. a different > "implTitle") - so it might just be a less likely, but still possible > way of unexpectedly hitting an IAE. > > With 'definePackageIfNotExists()` it might be possible to deprecate > 'definePackage()', but that deprecation largely depends on the actual > usage of it in the wild, which I do not know. I'm not sure whether > such a deprecation can fly. And the next question would be whether it > can be deprecated for removal ; and if yes, when could it be removed. > > Actually, even a new 'definePackageIfNotExists()` could break existing > code, in case an implementation overrides the existing 'definePackage' > but not 'definePackageIfNotExists()`. > > Another question to which I don't know the answer is whether the 7 > package attribute parameters specification/implementation > title/version/vendor + seal-base do fit "all today's wishes & needs". > Or: is there demand for a "better" or "more flexible" way to define a > class/package? Or: can that API be redefined in a different way > tailored for today's needs and wishes? And are there any that would > justify such an effort? > > Overall, I'm a bit lost on what the "best" way would be for this. > Maybe the answer is that there is no better way yet, which is also > fine. Maybe the only "fix" is to enhance the Javadocs and prominently > highlight the behavior and add a "reference code snippet" how > 'definePackage()' should be used and why. As we discussed already, this API "awkwardness" goes back to JDK 1.2 (1998) so changing the behavior now would be risky. Hard to know how many custom class loaders are using this method but expanding the apiNote to include a snippet that catches IAE to deal with concurrent attempts to define the package would be okay. As to your "all today's wishes & needs" comment. The "Package Version Specification" was of its time. It might be interesting to see how definePackage is used but I wouldn't be surprised to see the specXXX and implXXX parameters specified as null. Also the notion of sealed packages is legacy now. -Alan From alanb at openjdk.org Mon May 19 17:25:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 May 2025 17:25:52 GMT Subject: RFR: 8355954: File.delete removes read-only files (win) [v7] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 17:10:50 GMT, Brian Burkhalter wrote: >> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355954: Make test Windows-only Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24977#pullrequestreview-2851532693 From rriggs at openjdk.org Mon May 19 17:31:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 17:31:52 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface In-Reply-To: References: Message-ID: On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote: > Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: > https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html > The specification is mostly composed of Math.min/max and Collections.min/max specifications. > > The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. > > I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. Min and Max for the equals case would be more consistent if the value returned for equals was the same as the condition, as if `=>` or `<=` were used for the comparison. The code would be easier to read and match the description if max used `>=` and min used `<=`. ------------- PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-2851547425 From rgiulietti at openjdk.org Mon May 19 17:36:52 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 19 May 2025 17:36:52 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com> Message-ID: On Mon, 19 May 2025 17:16:58 GMT, fabioromano1 wrote: >> I think the suggestion is fine. > > Yes, but perhaps in the current version it's more clear what is the returned value according to the condition. One could see the suggested variant as "return magBitLength(), except for a corrective term in case blah blah..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096209014 From duke at openjdk.org Mon May 19 17:43:56 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 19 May 2025 17:43:56 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com> Message-ID: <1TYLBX7dQMXEARyetI6hnxkAr9lgj17f4jE-ID76K7I=.b640f392-b382-4c26-b237-e99fa430b85c@github.com> On Mon, 19 May 2025 17:34:16 GMT, Raffaello Giulietti wrote: >> Yes, but perhaps in the current version it's more clear what is the returned value according to the condition. > > One could see the suggested variant as "return magBitLength(), except for a corrective term in case blah blah..." Moreover, the current version avoids a subtraction in almost all cases, although probably it is negligible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096217698 From naoto.sato at oracle.com Mon May 19 18:02:28 2025 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 19 May 2025 11:02:28 -0700 Subject: Towards a JSON API for the JDK In-Reply-To: <52514642-e172-4096-a616-a2c9a9787552@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <52514642-e172-4096-a616-a2c9a9787552@gmail.com> Message-ID: <9eb26b27-6579-45ed-9a7d-70859efef7a7@oracle.com> Hi, On 5/17/25 10:55 PM, Cay Horstmann wrote: > PS. Trying to create and show the youthful John gives me grief right now: > > Json.fromUntyped(Map.of("name", "John", "age", 30)).toString() > |? Exception java.lang.NullPointerException: Cannot read the array > length because "value" is null > |??????? at String.rangeCheck (String.java:307) > |??????? at String. (String.java:303) > |??????? at JsonNumberImpl.toString (JsonNumberImpl.java:105) > |??????? at JsonObjectImpl.toString (JsonObjectImpl.java:56) > |??????? at (#23:1) > > The JsonNumberImpl.toString method needs to handle the case that it was > constructed from a Number. I could not reproduce it with the current branch. Could you please elaborate it more? Naoto From nbenalla at openjdk.org Mon May 19 18:11:34 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 18:11:34 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v3] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - feedback: never bump ASM version - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274 + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274 + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274 + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274 + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274 - Update --release 25 symbol information for JDK 24 build 20 The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/ - initial commit start-of-JDK-26 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=02 Stats: 1705 lines in 56 files changed: 1616 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From vyazici at openjdk.org Mon May 19 18:11:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 19 May 2025 18:11:55 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > warning Marked as reviewed by vyazici (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2851630246 From rriggs at openjdk.org Mon May 19 18:21:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 18:21:52 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 In-Reply-To: References: Message-ID: On Mon, 19 May 2025 13:33:51 GMT, kieran-farrell wrote: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. src/java.base/share/classes/java/util/UUID.java line 195: > 193: * > 194: * @return A {@code UUID} generated from the current system time > 195: */ Seems like there should be a reference to the RFC somewhere here using the @spec javadoc tag. And also in the class javadoc. src/java.base/share/classes/java/util/UUID.java line 219: > 217: randomBytes[8] |= (byte) 0x80; > 218: > 219: return new UUID(randomBytes); This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next(). Can the sub-microsecond value just be truncated and avoid the expensive divide operation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2096254869 PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2096265946 From rriggs at openjdk.org Mon May 19 18:44:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 18:44:53 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v3] In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 05:30:25 GMT, Shaojin Wen wrote: >> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > simplify code Please update the performance comparisons (percentage improvement.) src/java.base/share/classes/java/util/UUID.java line 491: > 489: * hexadecimal representation, concatenate these hexadecimal strings into one continuous string, and then interpret > 490: * this string as a hexadecimal number to form and return a long value. > 491: */ Is there a reference describing this technique? Such as the Hacker's Delight citation used in java.lang.Long? If not a longer descriptive comment would be good for maintainability. ------------- PR Review: https://git.openjdk.org/jdk/pull/22928#pullrequestreview-2851674685 PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2096283194 From duke at openjdk.org Mon May 19 18:46:10 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 19 May 2025 18:46:10 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett wrote: >> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage >> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences >> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to >> use java.lang.ref.Cleaner. >> >> This change is algorithmically similar to the two previous versions: >> JDK-6857566 and JDK-8156500 (current mainline). The critical function is >> Bits::reserveMemory(). For both of those versions and this change, a thread >> calls that function and tries to reserve some space. If it fails, then it >> keeps trying until all cleaners deactivated (cleared) by prior GCs have been >> cleaned. If reservation still fails, then it invokes the GC to try to >> deactivate more cleaners for cleaning. After that GC it keeps trying the >> reservation and waiting for cleaning, with sleeps to avoid a spin loop, >> eventually either succeeding or giving up and throwing OOME. >> >> Retaining that algorithmic approach is one of the goals of this change, since >> it has been successfully in use since JDK 9 (and was originally developed and >> extensively tested in JDK 8). >> >> The key to this approach is having a way to determine that deactivated >> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting >> threads help the reference processor until there was no available work. >> JDK-8156500 waits for the reference processor to quiesce, relying on its >> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way >> to do this, which is why this change rolls its own Cleaner-like mechanism from >> the underlying primitives. Like JDK-6857566, this change has waiting threads >> help with cleaning references. This was a potentially undesirable feature of >> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. >> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and >> became internal-only somewhere around that time as well.) That's not a concern >> here, as the cleaners involved are only from DBB, and we know what they look >> like. >> >> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning >> being done off the reference processing thread, as it may be expensive and >> slow down enqueuing other pending references. JDK-6857566 only did some of >> that, and JDK-8156500 lost that feature. This change moves all of the DBB >> cleaning off of the reference processing thread. (So does PR 22165.) >> >> Neither JDK-6857566 nor this change are... > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > move jdk.internal.nio.Cleaner to sun.nio src/java.base/share/classes/java/nio/Bits.java line 145: > 143: // Increment with overflow to 0, so the value can > 144: // never equal the initial/reset cleanedEpoch value. > 145: RESERVE_GC_EPOCH = Integer.max(0, RESERVE_GC_EPOCH + 1); Could?also do?the?following which?avoids the?branch in?`Integer.max`: Suggestion: RESERVE_GC_EPOCH = (RESERVE_GC_EPOCH + 1) & Integer.MAX_VALUE; src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209: > 207: super(-1, 0, cap, cap, fd, isSync, segment); > 208: address = addr; > 209: cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper); **OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]: Suggestion: cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper); [^1]: - https://github.com/prettier/prettier/issues/7475 - https://alexandersandberg.com/tabs-for-accessibility/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096283888 PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096296130 From rriggs at openjdk.org Mon May 19 18:47:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 18:47:54 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > warning Useful renames and comment placement improvements. lgtm. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2851703586 From duke at openjdk.org Mon May 19 18:49:52 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 19 May 2025 18:49:52 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 20:50:41 GMT, Kim Barrett wrote: >> src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26: >> >>> 24: */ >>> 25: >>> 26: package jdk.internal.nio; >> >> The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together. > > Good point. Done. But?`MhUtil` was?added to?the?newly created?`jdk.internal.invoke` package in? instead of?adding?it to?the?pre?existing `sun.invoke`?package. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096304667 From vromero at openjdk.org Mon May 19 19:21:57 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 May 2025 19:21:57 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v18] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Merge branch 'master' into JDK-8354556 > - review comments > - addressing review comments > - addressing review comments > - update warning message > - Merge branch 'master' into JDK-8354556 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang > - additional changes from Archie > - removing dead code > - integrating code from Archie > - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2892039464 From rriggs at openjdk.org Mon May 19 19:37:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 19:37:52 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett wrote: >> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage >> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences >> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to >> use java.lang.ref.Cleaner. >> >> This change is algorithmically similar to the two previous versions: >> JDK-6857566 and JDK-8156500 (current mainline). The critical function is >> Bits::reserveMemory(). For both of those versions and this change, a thread >> calls that function and tries to reserve some space. If it fails, then it >> keeps trying until all cleaners deactivated (cleared) by prior GCs have been >> cleaned. If reservation still fails, then it invokes the GC to try to >> deactivate more cleaners for cleaning. After that GC it keeps trying the >> reservation and waiting for cleaning, with sleeps to avoid a spin loop, >> eventually either succeeding or giving up and throwing OOME. >> >> Retaining that algorithmic approach is one of the goals of this change, since >> it has been successfully in use since JDK 9 (and was originally developed and >> extensively tested in JDK 8). >> >> The key to this approach is having a way to determine that deactivated >> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting >> threads help the reference processor until there was no available work. >> JDK-8156500 waits for the reference processor to quiesce, relying on its >> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way >> to do this, which is why this change rolls its own Cleaner-like mechanism from >> the underlying primitives. Like JDK-6857566, this change has waiting threads >> help with cleaning references. This was a potentially undesirable feature of >> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. >> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and >> became internal-only somewhere around that time as well.) That's not a concern >> here, as the cleaners involved are only from DBB, and we know what they look >> like. >> >> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning >> being done off the reference processing thread, as it may be expensive and >> slow down enqueuing other pending references. JDK-6857566 only did some of >> that, and JDK-8156500 lost that feature. This change moves all of the DBB >> cleaning off of the reference processing thread. (So does PR 22165.) >> >> Neither JDK-6857566 nor this change are... > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > move jdk.internal.nio.Cleaner to sun.nio The initial PR description is copied into every email. The detail in the PR is appreciated but can be less intrusive if included in a comment after the initial description. src/java.base/share/classes/java/nio/Bits.java line 170: > 168: // without it that test likely fails. Since failure here > 169: // ends in OOME, there's no need to hurry. > 170: for (int sleeps = 0; true; ) { More typical coding pattern in openjdk code. Here and elsewhere in this PR. Suggestion: while (true) { int sleeps = 0; src/java.base/share/classes/java/nio/BufferCleaner.java line 33: > 31: import java.util.Objects; > 32: import sun.nio.Cleaner; > 33: A class cleaner describing the overall objective (an excerpt from the PR description) would be useful. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88: > 86: // Long-standing behavior: when deallocation fails, VM exits. > 87: if (System.err != null) { > 88: new Error("Cleaner terminated abnormally", x).printStackTrace(); The message would be more useful to identify this as a **Buffer** Cleaner terminated abnormally. src/java.base/share/classes/sun/nio/Cleaner.java line 31: > 29: * {@code Cleaner} represents an object and a cleaning action. > 30: */ > 31: public interface Cleaner { Can this be renamed NIOCleaner or NIOBufClenaer or something to avoid the ambiguity between the other cleaner. ------------- PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2851749648 PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096331929 PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096341238 PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096351666 PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096355156 From rriggs at openjdk.org Mon May 19 19:40:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 May 2025 19:40:52 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 18:40:56 GMT, ExE Boss wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> move jdk.internal.nio.Cleaner to sun.nio > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209: > >> 207: super(-1, 0, cap, cap, fd, isSync, segment); >> 208: address = addr; >> 209: cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper); > > **OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]: > Suggestion: > > cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper); > > > [^1]: - prettier/prettier#7475 > - https://alexandersandberg.com/tabs-for-accessibility/ OpenJDK has not considered adoption of tabs-for-accessibility and sticks to using spaces across the codebase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096367503 From paul.sandoz at oracle.com Mon May 19 19:55:22 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 May 2025 19:55:22 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr> Message-ID: > > This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing one particular encoding of JSON and making it central to the API. Is that really the most important encoding? > It's one opinionated kind, a simple bi-directional mapping (embedding-projection pair) based on what the json values contain. The implementations can be entirely written less than 100 lines of code using the public API (there are more lines for the documentation). Users can easily write their own and can serve as an example with a bit more exposition in the documentation. The methods could be removed and it would not affect anything else, so it's not fundamental nor central. Paul. From paul.sandoz at oracle.com Mon May 19 19:59:17 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 May 2025 19:59:17 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Message-ID: On May 17, 2025, at 4:37?AM, Ethan McCue wrote: I think it's worth noting that the way you used the prospective API in your ONNX code is not representative of how the API would generally be used in a jdk-only scenario. Custom making a general transformation from JsonValue -> Record is outside the ken of i'd say most. I'd be interested in an experience report of using it straight up. Fair point. Although my use-case is likely more complex I hope my out-of-the-box experience is similar for others that may use it in less complex ways. Pau. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli at openjdk.org Mon May 19 19:59:51 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 19 May 2025 19:59:51 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: References: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com> Message-ID: <40zDBK-DvbpQPX1ColLdmfgGA1yTeUtidbOQV22QZCg=.93953b52-747c-4f8a-9ef4-5ad45d30f6d5@github.com> On Thu, 15 May 2025 17:15:20 GMT, Jiangli Zhou wrote: >> test/lib-test/TEST.ROOT line 31: >> >>> 29: keys=randomness >>> 30: >>> 31: # Minimum jtreg version >> >> Shoule we update the copyright year for file TestNativeProcessBuilder.java > > @sendaoYan Please let me know if you have any additional review comments, thanks. > > Also looking for a 'R'eviewer for reviewing. Thanks! A friendly ping ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2096399535 From paul.sandoz at oracle.com Mon May 19 20:02:50 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 May 2025 20:02:50 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On May 19, 2025, at 8:16?AM, Remi Forax wrote: Okay, i've taken a look to the design and this is not pretty. That seems an exaggerated statement to me. It's a trade-off, a compromise, allowing others to implement their own parsers, perhaps from non-textual representations. So of course we cannot enforce certain constraints and we need to specify how implementations must behave. The main issue is that the javadoc claims that "Both JsonValue instances and their underlying values are immutable." but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation. Because the hierarchy is non sealed, it also means that it is easy to create JsonValue that are invalid, for example var funJsonNumber = new JsonNumber() { public Number toNumber() { return Double.NaN; } public BigDecimal toBigDecimal() { throw new UnsupportedOperationException(); } public String toString() { return "NaN"; } }; var json = Json.fromUntyped(List.of(funJsonNumber)); For me, the Json hierarchy should be implemented with true ADTs, with all subtypes of JsonValue being records. Not doing that for reasons Brian has already explained. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Mon May 19 20:15:55 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 May 2025 20:15:55 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: Message-ID: <6F0F7985-2011-4530-8110-A6FCA53F6E05@oracle.com> The approach to the design of this API leans heavily on ongoing and future language and library features. This is why the API is so small as we don?t want conflicts with what we may do in the future. In the document we briefly mention data binding but don?t provide further context: Advanced features, such as data binding or path-based traversal should be possible to implement as layered features, but for simplicity are not included in the core API We think that Serialization 2.0 [1], a data-oriented approach to serialization, may provide the mechanism for binding between instances of JsonValue. Paul. [1] https://www.youtube.com/watch?v=fbqAyRJoQO0 On May 19, 2025, at 10:15?AM, Johannes D?bler wrote: Developers use JSON libraries like Fastjson, Jackson and Gson primarily (my claim) because they can marshal between JSON files and POJOs in one line of code with great performance and can easily tweak the mapping using annotations or adapter classes. Being able to read/write a JSON file from/to a generic tree of JsonValues might have use-cases, but manually implementing data-binding based one tree traversal w/wo pattern matching will produce bloated and fragile code (my claim). So my question is if there are plans to address data-binding in the future and how it would relate to the envisioned core API. Thanks Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Mon May 19 20:17:43 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 19 May 2025 20:17:43 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v4] In-Reply-To: References: Message-ID: > Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. 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 16 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into optim_uuid_to_string_202501 - simplify code - Remove redundant comments - use Long.expand - Merge remote-tracking branch 'upstream/master' into optim_uuid_to_string_202501 - refactor - from j3graham - add comments - use ByteArrayLittleEndian - ues Long.expand - ... and 6 more: https://git.openjdk.org/jdk/compare/6f6e5efd...878a3cb7 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22928/files - new: https://git.openjdk.org/jdk/pull/22928/files/55223571..878a3cb7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=02-03 Stats: 353363 lines in 4033 files changed: 118357 ins; 216754 del; 18252 mod Patch: https://git.openjdk.org/jdk/pull/22928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928 PR: https://git.openjdk.org/jdk/pull/22928 From kbarrett at openjdk.org Mon May 19 20:18:54 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 May 2025 20:18:54 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: <_Sn16clurXPHgVjZVt8Uq4uH4WeJ23qa1XTQnw3WY4w=.62794a53-a9d0-4eb6-a8df-62b04604b555@github.com> On Mon, 19 May 2025 18:30:45 GMT, ExE Boss wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> move jdk.internal.nio.Cleaner to sun.nio > > src/java.base/share/classes/java/nio/Bits.java line 145: > >> 143: // Increment with overflow to 0, so the value can >> 144: // never equal the initial/reset cleanedEpoch value. >> 145: RESERVE_GC_EPOCH = Integer.max(0, RESERVE_GC_EPOCH + 1); > > Could?also do?the?following which?avoids the?branch in?`Integer.max`: > Suggestion: > > RESERVE_GC_EPOCH = (RESERVE_GC_EPOCH + 1) & Integer.MAX_VALUE; I think the use of `Integer.max` is clearer, any performance difference is insignificant, and the compiler can make that change as an optimization if appropriate. So I'm not inclined to accept this suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096422654 From bpb at openjdk.org Mon May 19 20:21:50 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 19 May 2025 20:21:50 GMT Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in exception In-Reply-To: References: Message-ID: On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller wrote: > When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones. @ArnoZeller Please issue the `/integrate` command so that this request may be sponsored. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25250#issuecomment-2892170536 From kbarrett at openjdk.org Mon May 19 20:22:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 May 2025 20:22:52 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: <3DkRh7Fg6uianW9tEAegtTMlS0XPR-p2-AVcG0AaM5c=.b7207af6-1340-4041-888f-ed76da0e321c@github.com> On Mon, 19 May 2025 19:37:58 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209: >> >>> 207: super(-1, 0, cap, cap, fd, isSync, segment); >>> 208: address = addr; >>> 209: cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper); >> >> **OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]: >> Suggestion: >> >> cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper); >> >> >> [^1]: - prettier/prettier#7475 >> - https://alexandersandberg.com/tabs-for-accessibility/ > > OpenJDK has not considered adoption of tabs-for-accessibility and sticks to using spaces across the codebase. I didn't notice that a tab had snuck in there. Thanks for spotting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096427690 From paul.sandoz at oracle.com Mon May 19 20:36:11 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 May 2025 20:36:11 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: <52514642-e172-4096-a616-a2c9a9787552@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <52514642-e172-4096-a616-a2c9a9787552@gmail.com> Message-ID: <42EC08C7-4C39-4F05-A947-70F08C2818CE@oracle.com> Hi Cay, It would be really helpful to share some more detailed use-cases on editing/modification that you may reasonably expect users to perform. I hope we might be able to devise a transformation API, hopefully layered on top of the public API and possibly with structural sharing for unmodified parts. One such experiment is presented below that copies the flat map transformation patterns used by the class file API and code reflection (a combination of traversal + building). It can be used like this: JsonObject o = ... System.out.println(transformObject(o, (jc, c) -> { if (jc instanceof JsonObjectEntry(var name, JsonNumber n) && name.equals("UnitPrice")) { // Replace number c.accept(new JsonObjectEntry(name, JsonNumber.of(n.value().doubleValue() + 10.0))); } else { // Copy c.accept(jc); } })); This needs a lot more thought but there might be something to this. Paul. public class JsonTransform { public sealed interface JsonComponent { } public record JsonObjectMember(String name, JsonValue v) implements JsonComponent { } public record JsonArrayElement(JsonValue v) implements JsonComponent { } public static JsonObject transformObject(JsonObject o, BiConsumer> f) { /* value */ class ObjectConsumer implements Consumer { final Map outputEntries = new HashMap<>(); JsonObjectMember input; @Override public void accept(JsonComponent _output) { JsonObjectMember output = (JsonObjectMember) _output; JsonValue outputValue; if (input == output) { // traverse outputValue = switch (input.v()) { case JsonArray ja -> transformArray(ja, f); case JsonObject jo -> transformObject(jo, f); case JsonValue jv -> jv; }; } else { // replace outputValue = output.v(); } outputEntries.put(output.name(), outputValue); } } ObjectConsumer c = new ObjectConsumer(); for (Map.Entry inputEntry : o.members().entrySet()) { JsonObjectMember input = c.input = new JsonObjectMember(inputEntry.getKey(), inputEntry.getValue()); f.accept(input, c); } return JsonObject.of(c.outputEntries); } public static JsonArray transformArray(JsonArray a, BiConsumer> f) { /* value */ class ArrayConsumer implements Consumer { final ArrayList outputElements = new ArrayList<>(); JsonArrayElement input; @Override public void accept(JsonComponent _output) { JsonArrayElement output = (JsonArrayElement) _output; JsonValue outputValue; if (input == output) { // traverse outputValue = switch (input.v()) { case JsonArray ja -> transformArray(ja, f); case JsonObject jo -> transformObject(jo, f); case JsonValue jv -> jv; }; } else { // replace outputValue = output.v(); } outputElements.add(outputValue); } } ArrayConsumer c = new ArrayConsumer(); List values = a.values(); for (int i = 0; i < values.size(); i++) { // @@@ pass index? JsonArrayElement input = c.input = new JsonArrayElement(values.get(i)); f.accept(input, c); } return JsonArray.of(c.outputElements); } } On May 17, 2025, at 10:55?PM, Cay Horstmann wrote: +1 for having a JSON battery included with the JDK. And for "Our primary goal is that the library be simple to use for parsing, traversing, and generating conformant JSON documents." Generating JSON could be easier. Why not convenience methods Json.newObject and Json.newArray like in https://github.com/arkanovicz/essential-json? Parsing with instanceof will work, but is obviously painful today, as your example shows. The simplification with deconstruction patterns is not impressive either. JsonValue doc = Json.parse(inputString); if (doc instanceof JsonObject(var members) && members.get("name") instanceof JsonString(String name) && members.get("age") instanceof JsonNumber(int age)) { // use "name" and "age" } else throw new NoSuchArgumentException(); vs. Jackson String name = doc.get("name").asText(); int age = doc.get("age").asInt(); ... If only there was some deconstruction magic that approximates the JavaScript code const doc = { name: "John", age: 30 } const { name, age } = doc What about editing documents? With Jackson, you can mutate objects and arrays. I see the appeal of immutability, but then there needs to be a convenient transform API. Right now, making John one year older is not pretty: var nextYearDoc = switch (doc) { case JsonObject(var members) if members.get("name") instanceof JsonString(String name) && members.get("age") instanceof JsonNumber(int age)) -> Json.fromUntyped(Map.of("name", name, "age", age + 1)); default -> throw new NoSuchArgumentException(); } And it gets worse if John is nested more deeply in a document. I have worked a lot with immutable XML in Scala. One minimally needs a mechanism for recursive rewriting with a node replacement function. I am not aware of an existing library that attempts this in Java for JSON. I am sure it can be done, but it may not be trivial to do such an API well. Cheers, Cay PS. Trying to create and show the youthful John gives me grief right now: Json.fromUntyped(Map.of("name", "John", "age", 30)).toString() | Exception java.lang.NullPointerException: Cannot read the array length because "value" is null | at String.rangeCheck (String.java:307) | at String. (String.java:303) | at JsonNumberImpl.toString (JsonNumberImpl.java:105) | at JsonObjectImpl.toString (JsonObjectImpl.java:56) | at (#23:1) The JsonNumberImpl.toString method needs to handle the case that it was constructed from a Number. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Mon May 19 20:36:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 May 2025 20:36:51 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 19:27:27 GMT, Roger Riggs wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> move jdk.internal.nio.Cleaner to sun.nio > > src/java.base/share/classes/sun/nio/Cleaner.java line 31: > >> 29: * {@code Cleaner} represents an object and a cleaning action. >> 30: */ >> 31: public interface Cleaner { > > Can this be renamed NIOCleaner or NIOBufClenaer or something to avoid the ambiguity between the other cleaner. I intentionally (re)used the "Cleaner" name to avoid a bunch of renames that would increase the size of the change and distract from the meat of it. I think the name to use might be affected by how the implementation of the set of cleanup objects might get merged between the new java.nio.BufferCleaner and java.lang.ref.Cleaner. Perhaps the java.lang.ref.Cleaner.Cleanable interface should be used throughout? I didn't want to expand this change to include those kinds of questions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096448999 From darcy at openjdk.org Mon May 19 20:43:52 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 19 May 2025 20:43:52 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Mon, 19 May 2025 11:31:23 GMT, Nizar Benalla wrote: >> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341: >> >>> 1339: * @throws ClassNotFoundException if one of the component classes cannot be resolved >>> 1340: * @see MethodType.readResolve() >>> 1341: * @see MethodType.writeObject(ObjectOutputStream s) >> >> This is already not generated by the javadoc as this method is private. Why is this check against a private method? > > They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be. As it is, if the see tags are going to stay, I don't think `foo` markup should be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2096456914 From kbarrett at openjdk.org Mon May 19 20:46:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 May 2025 20:46:55 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 19:24:57 GMT, Roger Riggs wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> move jdk.internal.nio.Cleaner to sun.nio > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88: > >> 86: // Long-standing behavior: when deallocation fails, VM exits. >> 87: if (System.err != null) { >> 88: new Error("Cleaner terminated abnormally", x).printStackTrace(); > > The message would be more useful to identify this as a **Buffer** Cleaner terminated abnormally. This code was cribbed from https://github.com/openjdk/jdk/pull/22165, but your suggestion has led me to discover that wasn't right. I'm going to need to do some rework of the exception handling around cleaning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096460505 From forax at univ-mlv.fr Mon May 19 20:56:32 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 19 May 2025 22:56:32 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> > From: "Paul Sandoz" > To: "Remi Forax" > Cc: "Brian Goetz" , "core-libs-dev" > > Sent: Monday, May 19, 2025 10:02:50 PM > Subject: Re: Towards a JSON API for the JDK >> On May 19, 2025, at 8:16 AM, Remi Forax wrote: >> Okay, >> i've taken a look to the design and this is not pretty. > That seems an exaggerated statement to me. It's a trade-off, a compromise, > allowing others to implement their own parsers, perhaps from non-textual > representations. So of course we cannot enforce certain constraints and we need > to specify how implementations must behave. >> The main issue is that the javadoc claims that >> "Both JsonValue instances and their underlying values are immutable." >> but at the same time any subtypes of JsonValue is non-sealed so anyone can >> implement let say JsonString and adds it's own mutable implementation. You can not claim that JsonValue instances are immutable while obviously they are not. You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is not algebraic. You allow anybody to write their own class inside the JsonValue hierarchy, so there is no safety, strings can be not escaped correctly, number can represent invalid values, etc. The minute I write a method that takes a JsonValue as parameter i'm writing unsafe code, You are hoping that nobody will ever extend JsonValue subtypes, that's wishful thinking, this is not a safe design ... this is not pretty. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus at headcrashing.eu Mon May 19 21:02:18 2025 From: markus at headcrashing.eu (Markus KARG) Date: Mon, 19 May 2025 23:02:18 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <42EC08C7-4C39-4F05-A947-70F08C2818CE@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <52514642-e172-4096-a616-a2c9a9787552@gmail.com> <42EC08C7-4C39-4F05-A947-70F08C2818CE@oracle.com> Message-ID: <78efdce4-c8da-4c2a-8275-d4e6334831a9@headcrashing.eu> Paul, thank you for picking up the topic JSON. I do like the simplicity of your proposal, OTOH I have concerns: * Will it it be sustaining? We added a XML API when XML was "the" big thing, and now it is not a big thing anymore and we can't get rid of the XML API without breaking things. So does it really make sense to add a JSON API to OpenJDK? I see the risk that in 10 years we are in the same situation as with XML: It got replaced with "the" next big thing, and then it lingers in the JDK together with the XML API. Maybe it would be better to have some "beginner's bundle" with all those goodies that newcomers need, instead of making all of that part of the JRE? * Will it be too late? As JSON is such a big thing for many years, there are lots of implementations, and several abstracting APIs already, most prominently Jakarta JSON-P (formerly Java EE JSON-P; https://jakartaee.github.io/jsonp-api/). Does it make really make much sense to provide a competitive abstraction API? * Will it be too verbose? I doubt that the not really short-to-read code samples really attract beginners. And all others simply go with existing solutions, as they have no benefit from abondoning existing solutions. -Markus From jlu at openjdk.org Mon May 19 21:02:49 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 19 May 2025 21:02:49 GMT Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly state extlangs are allowed Message-ID: It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/25309/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357275 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309 PR: https://git.openjdk.org/jdk/pull/25309 From paul.sandoz at oracle.com Mon May 19 21:18:26 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 May 2025 21:18:26 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> Those extending the non-sealed subtypes of JsonValue must conform to the requirements that are specified. The current documentation could be more clearly written as to what those requirements are. Of course we cannot enforce those requirements any more than we can enforce the requirements specified for implementations of List. Paul. On May 19, 2025, at 1:56?PM, forax at univ-mlv.fr wrote: ________________________________ From: "Paul Sandoz" To: "Remi Forax" Cc: "Brian Goetz" , "core-libs-dev" Sent: Monday, May 19, 2025 10:02:50 PM Subject: Re: Towards a JSON API for the JDK On May 19, 2025, at 8:16?AM, Remi Forax wrote: Okay, i've taken a look to the design and this is not pretty. That seems an exaggerated statement to me. It's a trade-off, a compromise, allowing others to implement their own parsers, perhaps from non-textual representations. So of course we cannot enforce certain constraints and we need to specify how implementations must behave. The main issue is that the javadoc claims that "Both JsonValue instances and their underlying values are immutable." but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation. You can not claim that JsonValue instances are immutable while obviously they are not. You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is not algebraic. You allow anybody to write their own class inside the JsonValue hierarchy, so there is no safety, strings can be not escaped correctly, number can represent invalid values, etc. The minute I write a method that takes a JsonValue as parameter i'm writing unsafe code, You are hoping that nobody will ever extend JsonValue subtypes, that's wishful thinking, this is not a safe design ... this is not pretty. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon May 19 21:55:51 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 19 May 2025 23:55:51 +0200 (CEST) Subject: Towards a JSON API for the JDK In-Reply-To: <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> Message-ID: <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> > From: "Paul Sandoz" > To: "Remi Forax" > Cc: "Brian Goetz" , "core-libs-dev" > > Sent: Monday, May 19, 2025 11:18:26 PM > Subject: Re: Towards a JSON API for the JDK > Those extending the non-sealed subtypes of JsonValue must conform to the > requirements that are specified. The current documentation could be more > clearly written as to what those requirements are. Of course we cannot enforce > those requirements any more than we can enforce the requirements specified for > implementations of List. List is such a good example. For a List, like for a JsonValue, you have no idea if the implementation is mutable or not, so you can use a defensive copy using List.copyOf() (or Collections.unmodifiableList(new ArrayList<>(list)) in the older version of Java). How to do a defensive copy of a JsonValue ? The other issue I see is lazyness in Json.parse(). The API is restricted to String/char[], so restricted to JSON document that are not big. If the document is not big, lazyness usually make things slower and it also delays the moment you know if the document is a valid JSON document or not. With the actual design, you have no way to know if a JSON document is valid. If you combine both things, the fact that you have a big list of requirements for each subtypes and eager parsing, you are not far from having only one implementation possible, hence the idea of implementing real ADTs using records. > Paul. R?mi >> On May 19, 2025, at 1:56 PM, forax at univ-mlv.fr wrote: >>> From: "Paul Sandoz" >>> To: "Remi Forax" >>> Cc: "Brian Goetz" , "core-libs-dev" >>> >>> Sent: Monday, May 19, 2025 10:02:50 PM >>> Subject: Re: Towards a JSON API for the JDK >>>> On May 19, 2025, at 8:16 AM, Remi Forax wrote: >>>> Okay, >>>> i've taken a look to the design and this is not pretty. >>> That seems an exaggerated statement to me. It's a trade-off, a compromise, >>> allowing others to implement their own parsers, perhaps from non-textual >>> representations. So of course we cannot enforce certain constraints and we need >>> to specify how implementations must behave. >>>> The main issue is that the javadoc claims that >>>> "Both JsonValue instances and their underlying values are immutable." >>>> but at the same time any subtypes of JsonValue is non-sealed so anyone can >>>> implement let say JsonString and adds it's own mutable implementation. >> You can not claim that JsonValue instances are immutable while obviously they >> are not. >> You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is >> not algebraic. >> You allow anybody to write their own class inside the JsonValue hierarchy, so >> there is no safety, strings can be not escaped correctly, number can represent >> invalid values, etc. >> The minute I write a method that takes a JsonValue as parameter i'm writing >> unsafe code, >> You are hoping that nobody will ever extend JsonValue subtypes, that's wishful >> thinking, this is not a safe design ... this is not pretty. >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Mon May 19 22:46:31 2025 From: ethan at mccue.dev (Ethan McCue) Date: Mon, 19 May 2025 18:46:31 -0400 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr> Message-ID: What I mean by central in this context isn't that it's at the core of things and features are built on top of it - as you note it is a valid transformation of the hierarchy. What I mean is that absent other construction/deconstruction apis it is the most convenient avenue for those tasks. So code using the API would trend towards using it. See Remi's usage of fromUntyped elsewhere in the discussion tree. The thing that the language doesn't have yet is patterns. We have all the mechanism for creating objects. The broad issue I see is that, if we take the view that >in general< deconstruction should be the dual of construction - the mechanics for construction should probably be influenced by how you want people pulling these things apart. Basic example - JsonString.of - that is null hostile for good reason, but it is very easy to imagine wanting to write code that deals uniformly with absent, null, and string values for a field in an object. So that puts a pressure - beyond creation ergonomics - on a Json.of that is null-tolerant. Since that would be a good place for a dual pattern for pulling out a possibly nullable object member. (but still wouldn't solve for absent ones - I have a doc somewhere with like 15 options none of which inspire joy and many of which are conditional on exactly how patterns ship) On Mon, May 19, 2025, 3:55?PM Paul Sandoz wrote: > > > > > This is part of why fromUntyped/toUntyped is uncomfortable - it's > choosing one particular encoding of JSON and making it central to the API. > Is that really the most important encoding? > > > > > It's one opinionated kind, a simple bi-directional mapping > (embedding-projection pair) based on what the json values contain. The > implementations can be entirely written less than 100 lines of code using > the public API (there are more lines for the documentation). Users can > easily write their own and can serve as an example with a bit more > exposition in the documentation. The methods could be removed and it would > not affect anything else, so it's not fundamental nor central. > > Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vromero at openjdk.org Mon May 19 22:50:04 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 May 2025 22:50:04 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v18] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Merge branch 'master' into JDK-8354556 > - review comments > - addressing review comments > - addressing review comments > - update warning message > - Merge branch 'master' into JDK-8354556 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang > - additional changes from Archie > - removing dead code > - integrating code from Archie > - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd thanks guys for the reviews and contributions ------------- PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2892451481 From vromero at openjdk.org Mon May 19 22:50:06 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 May 2025 22:50:06 GMT Subject: Integrated: 8354556: Expand value-based class warnings to java.lang.ref API In-Reply-To: References: Message-ID: <5a5jcUgnclxBixFti4n6YX4EPOqXQBKCzhQqZQVPXHU=.987b3c82-af88-47a6-a2bd-d91c1002aedf@github.com> On Fri, 18 Apr 2025 00:06:26 GMT, Vicente Romero wrote: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 This pull request has now been integrated. Changeset: 637e9d16 Author: Vicente Romero URL: https://git.openjdk.org/jdk/commit/637e9d16ddb21003234abcd32f759aefd91f21f9 Stats: 647 lines in 32 files changed: 562 ins; 37 del; 48 mod 8354556: Expand value-based class warnings to java.lang.ref API Co-authored-by: Archie Cobbs Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/24746 From swen at openjdk.org Mon May 19 23:07:58 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 19 May 2025 23:07:58 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v4] In-Reply-To: References: Message-ID: <5B2SVUN_H6PROzr5_PLAhU8nv9l7NUwF0TCr1BUAgks=.38cd964f-20ca-4d02-a5ef-0f084eb0b66e@github.com> On Mon, 19 May 2025 20:17:43 GMT, Shaojin Wen wrote: >> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. > > 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 16 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into optim_uuid_to_string_202501 > - simplify code > - Remove redundant comments > - use Long.expand > - Merge remote-tracking branch 'upstream/master' into optim_uuid_to_string_202501 > - refactor > - from j3graham > - add comments > - use ByteArrayLittleEndian > - ues Long.expand > - ... and 6 more: https://git.openjdk.org/jdk/compare/f9f2be52...878a3cb7 The latest performance test numbers show that under AMD X64, the performance is improved by about 21%, and under MacBook M1 Pro, the performance is improved by about 7%. ## performance test scripts git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao # origin git checkout bd99525633e4d3d3f180a6678eedb8780dbb6139 make test TEST="micro:java.util.UUIDBench.toString" # current git checkout 878a3cb7c73b777eb5385b3e4d158c998cd9be46 make test TEST="micro:java.util.UUIDBench.toString" ## aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa) -# origin bd99525633e4d3d3f180a6678eedb8780dbb6139 -Benchmark (size) Mode Cnt Score Error Units -UUIDBench.toString 20000 thrpt 15 93.320 ? 0.359 ops/us +# current 878a3cb7c73b777eb5385b3e4d158c998cd9be46 +Benchmark (size) Mode Cnt Score Error Units +UUIDBench.toString 20000 thrpt 15 113.508 ? 1.372 ops/us +21.63% ## Apple MackBook M1 Pro -# origin bd99525633e4d3d3f180a6678eedb8780dbb6139 -Benchmark (size) Mode Cnt Score Error Units -UUIDBench.toString 20000 thrpt 15 106.199 ? 0.568 ops/us +# current 878a3cb7c73b777eb5385b3e4d158c998cd9be46 +Benchmark (size) Mode Cnt Score Error Units +UUIDBench.toString 20000 thrpt 15 113.911 ? 0.628 ops/us +7.34% ------------- PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2892476915 From swen at openjdk.org Mon May 19 23:34:34 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 19 May 2025 23:34:34 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v5] In-Reply-To: References: Message-ID: > Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: hex8 comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22928/files - new: https://git.openjdk.org/jdk/pull/22928/files/878a3cb7..4e62d43c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=03-04 Stats: 44 lines in 1 file changed: 38 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928 PR: https://git.openjdk.org/jdk/pull/22928 From naoto at openjdk.org Mon May 19 23:43:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 19 May 2025 23:43:51 GMT Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly state extlangs are allowed In-Reply-To: References: Message-ID: On Mon, 19 May 2025 20:56:55 GMT, Justin Lu wrote: > It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification. src/java.base/share/classes/java/util/Locale.java line 2792: > 2790: * tag). {@code languageTag} may contain up to three extlang subtags. > 2791: + For such occurrences, the first extlang subtag is used as the language, > 2792: * and the primary language subtag and other extlang subtags are ignored. Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096613695 From swen at openjdk.org Mon May 19 23:53:07 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 19 May 2025 23:53:07 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6] In-Reply-To: References: Message-ID: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com> > Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: hex8 comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22928/files - new: https://git.openjdk.org/jdk/pull/22928/files/4e62d43c..3b94f81f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=04-05 Stats: 69 lines in 1 file changed: 11 ins; 5 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/22928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928 PR: https://git.openjdk.org/jdk/pull/22928 From jlu at openjdk.org Mon May 19 23:55:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 19 May 2025 23:55:51 GMT Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly state extlangs are allowed In-Reply-To: References: Message-ID: On Mon, 19 May 2025 23:41:25 GMT, Naoto Sato wrote: >> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification. > > src/java.base/share/classes/java/util/Locale.java line 2792: > >> 2790: * tag). {@code languageTag} may contain up to three extlang subtags. >> 2791: + For such occurrences, the first extlang subtag is used as the language, >> 2792: * and the primary language subtag and other extlang subtags are ignored. > > Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag. An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example, `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // ==> yue_CN i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096619811 From naoto at openjdk.org Tue May 20 00:41:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 May 2025 00:41:51 GMT Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly state extlangs are allowed In-Reply-To: References: Message-ID: On Mon, 19 May 2025 23:50:59 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/util/Locale.java line 2792: >> >>> 2790: * tag). {@code languageTag} may contain up to three extlang subtags. >>> 2791: + For such occurrences, the first extlang subtag is used as the language, >>> 2792: * and the primary language subtag and other extlang subtags are ignored. >> >> Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag. > > An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example, > > `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws > `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-CN").build()` // ==> yue_CN > > i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags. (Edit: Forgot to adjust the example) OK. I would add these examples here too, which may be more helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096650651 From henryjen at openjdk.org Tue May 20 00:51:51 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 20 May 2025 00:51:51 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou wrote: >> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description: >> >> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. Marked as reviewed by henryjen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25220#pullrequestreview-2852249506 From henryjen at openjdk.org Tue May 20 00:51:52 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 20 May 2025 00:51:52 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: <40zDBK-DvbpQPX1ColLdmfgGA1yTeUtidbOQV22QZCg=.93953b52-747c-4f8a-9ef4-5ad45d30f6d5@github.com> References: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com> <40zDBK-DvbpQPX1ColLdmfgGA1yTeUtidbOQV22QZCg=.93953b52-747c-4f8a-9ef4-5ad45d30f6d5@github.com> Message-ID: On Mon, 19 May 2025 19:56:52 GMT, Jiangli Zhou wrote: >> @sendaoYan Please let me know if you have any additional review comments, thanks. >> >> Also looking for a 'R'eviewer for reviewing. Thanks! > > A friendly ping LGTM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2096657809 From swen at openjdk.org Tue May 20 00:52:53 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 00:52:53 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v3] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 18:30:20 GMT, Roger Riggs wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> simplify code > > src/java.base/share/classes/java/util/UUID.java line 491: > >> 489: * hexadecimal representation, concatenate these hexadecimal strings into one continuous string, and then interpret >> 490: * this string as a hexadecimal number to form and return a long value. >> 491: */ > > Is there a reference describing this technique? Such as the Hacker's Delight citation used in java.lang.Long? > If not a longer descriptive comment would be good for maintainability. This algorithm was researched and implemented by me, and I have added detailed description and comments ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2096658412 From almatvee at openjdk.org Tue May 20 00:53:29 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 20 May 2025 00:53:29 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles Message-ID: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Fixed jpackage to produce valid Java runtimes based on description below: Definitions: - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". - JDK image defined as content of "Contents/Home". - Signed JDK image does not exist, since it cannot be signed as bundle. jpackage output based on input: 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: - jpackage will copy all files as is from provided path and run ad-hoc codesign. 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. 5. "--runtime-image" points to JDK image and --mac-sign is not provided: - jpackage will check for libjli.dylib presence in "lib" folder. - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. - Ad-hoc signing will done. 6. "--runtime-image" points to JDK image and --mac-sign is provided: - 2 first steps from 5 and certificate signing will be done. ------------- Commit messages: - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles Changes: https://git.openjdk.org/jdk/pull/25314/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351073 Stats: 689 lines in 14 files changed: 608 ins; 50 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/25314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25314/head:pull/25314 PR: https://git.openjdk.org/jdk/pull/25314 From swen at openjdk.org Tue May 20 01:01:30 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 01:01:30 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods Message-ID: Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. The following is the output information of PrintInlining: @ 9 java.lang.String:: (12 bytes) inline (hot) !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big In Java code, the big method that cannot be inlined is the following constructor String(Charset charset, byte[] bytes, int offset, int length) {} The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. ------------- Commit messages: - bug fix - code style, from @liach - remove record - make create method codeSize < 325 - split String constructor Changes: https://git.openjdk.org/jdk/pull/25290/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357289 Stats: 206 lines in 1 file changed: 62 ins; 74 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/25290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290 PR: https://git.openjdk.org/jdk/pull/25290 From swen at openjdk.org Tue May 20 01:01:31 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 01:01:31 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods In-Reply-To: References: Message-ID: On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen wrote: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. Below are the performance numbers on the MacBook M1 Max. The numbers show that after the small split method, the performance has been significantly improved. -# master 6c42856b8d5 -Benchmark (size) Mode Cnt Score Error Units -StringConstructor.newStringFromBytes 7 avgt 15 6.628 ? 0.048 ns/op -StringConstructor.newStringFromBytes 64 avgt 15 10.182 ? 0.079 ns/op -StringConstructor.newStringFromBytesRanged 7 avgt 15 10.187 ? 0.871 ns/op -StringConstructor.newStringFromBytesRanged 64 avgt 15 11.304 ? 0.111 ns/op -StringConstructor.newStringFromBytesRangedWithCharsetUTF8 7 avgt 15 10.869 ? 0.753 ns/op -StringConstructor.newStringFromBytesRangedWithCharsetUTF8 64 avgt 15 11.348 ? 0.134 ns/op -StringConstructor.newStringFromBytesWithCharsetNameUTF8 7 avgt 15 9.483 ? 0.119 ns/op -StringConstructor.newStringFromBytesWithCharsetNameUTF8 64 avgt 15 12.755 ? 0.089 ns/op -StringConstructor.newStringFromBytesWithCharsetUTF8 7 avgt 15 6.721 ? 0.107 ns/op -StringConstructor.newStringFromBytesWithCharsetUTF8 64 avgt 15 10.208 ? 0.065 ns/op +# current 4ebac0ddc64 +Benchmark (size) Mode Cnt Score Error Units +StringConstructor.newStringFromBytes 7 avgt 15 4.715 ? 0.029 ns/op +40.57% +StringConstructor.newStringFromBytes 64 avgt 15 8.019 ? 0.152 ns/op +26.97% +StringConstructor.newStringFromBytesRanged 7 avgt 15 5.563 ? 0.059 ns/op +83.12% +StringConstructor.newStringFromBytesRanged 64 avgt 15 9.549 ? 0.217 ns/op +18.37% +StringConstructor.newStringFromBytesRangedWithCharsetUTF8 7 avgt 15 5.579 ? 0.076 ns/op +94.81% +StringConstructor.newStringFromBytesRangedWithCharsetUTF8 64 avgt 15 9.407 ? 0.047 ns/op +20.63% +StringConstructor.newStringFromBytesWithCharsetNameUTF8 7 avgt 15 8.168 ? 0.084 ns/op +16.09% +StringConstructor.newStringFromBytesWithCharsetNameUTF8 64 avgt 15 12.574 ? 0.268 ns/op + 1.43% +StringConstructor.newStringFromBytesWithCharsetUTF8 7 avgt 15 4.722 ? 0.043 ns/op +42.33% +StringConstructor.newStringFromBytesWithCharsetUTF8 64 avgt 15 8.077 ? 0.144 ns/op +26.38% ------------- PR Comment: https://git.openjdk.org/jdk/pull/25290#issuecomment-2889044580 From jiangli at openjdk.org Tue May 20 01:08:51 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 20 May 2025 01:08:51 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 00:49:28 GMT, Henry Jen wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. > > Marked as reviewed by henryjen (Committer). @slowhog Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25220#issuecomment-2892617923 From liach at openjdk.org Tue May 20 01:12:52 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 May 2025 01:12:52 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods In-Reply-To: References: Message-ID: On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen wrote: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. src/java.base/share/classes/java/lang/String.java line 690: > 688: .onUnmappableCharacter(CodingErrorAction.REPLACE); > 689: char[] ca = new char[en]; > 690: int caLen = decodeWithDecoder(cd, ca, bytes, offset, length); Let's restore the CharacterCodingException for now. I don't think we should change the exceptions as part of the break down. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2094621982 From swen at openjdk.org Tue May 20 01:23:51 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 01:23:51 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods In-Reply-To: References: Message-ID: On Sun, 18 May 2025 20:44:12 GMT, Chen Liang wrote: >> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. >> >> The following is the output information of PrintInlining: >> >> @ 9 java.lang.String:: (12 bytes) inline (hot) >> !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) >> ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big >> >> >> In Java code, the big method that cannot be inlined is the following constructor >> >> >> String(Charset charset, byte[] bytes, int offset, int length) {} >> >> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. > > src/java.base/share/classes/java/lang/String.java line 690: > >> 688: .onUnmappableCharacter(CodingErrorAction.REPLACE); >> 689: char[] ca = new char[en]; >> 690: int caLen = decodeWithDecoder(cd, ca, bytes, offset, length); > > Let's restore the CharacterCodingException for now. I don't think we should change the exceptions as part of the break down. Restoring the exception handling here will cause the codeSize of the create method to be greater than 325. This exception will not occur here, so the exception handling is moved to decodeWithDecoder. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2096683192 From liach at openjdk.org Tue May 20 01:39:00 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 May 2025 01:39:00 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods In-Reply-To: References: Message-ID: On Tue, 20 May 2025 01:21:34 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/String.java line 690: >> >>> 688: .onUnmappableCharacter(CodingErrorAction.REPLACE); >>> 689: char[] ca = new char[en]; >>> 690: int caLen = decodeWithDecoder(cd, ca, bytes, offset, length); >> >> Let's restore the CharacterCodingException for now. I don't think we should change the exceptions as part of the break down. > > Restoring the exception handling here will cause the codeSize of the create method to be greater than 325. This exception will not occur here, so the exception handling is moved to decodeWithDecoder. I think in this case, a better approach might be declaring `char[] ca` and `int cLen`/`caLen` -> the array decoder and the regular decoder can initialize these two variables, and share the final code that compress the strings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2096694772 From iklam at openjdk.org Tue May 20 02:02:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 20 May 2025 02:02:44 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v10] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 - Added param to makefile function SetupAOT for choosing onestep vs twostep - Allow one-step training even when -XX:AOTMode=auto is specified - ... and 14 more: https://git.openjdk.org/jdk/compare/890456f0...0956fcad ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09 Stats: 2088 lines in 24 files changed: 1564 ins; 459 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From swen at openjdk.org Tue May 20 02:04:24 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 02:04:24 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v2] In-Reply-To: References: Message-ID: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: create method share variant val & coder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25290/files - new: https://git.openjdk.org/jdk/pull/25290/files/f7abb552..b6f0a2db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=00-01 Stats: 67 lines in 1 file changed: 31 ins; 16 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/25290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290 PR: https://git.openjdk.org/jdk/pull/25290 From swen at openjdk.org Tue May 20 02:11:34 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 02:11:34 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: create method share variant val & coder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25290/files - new: https://git.openjdk.org/jdk/pull/25290/files/b6f0a2db..fab7728b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=01-02 Stats: 38 lines in 1 file changed: 14 ins; 11 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290 PR: https://git.openjdk.org/jdk/pull/25290 From xgong at openjdk.org Tue May 20 02:24:51 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 20 May 2025 02:24:51 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Mon, 19 May 2025 03:10:46 GMT, Xiaohong Gong wrote: >> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). >> >> Two key areas require improvement: >> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. >> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. >> >> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. >> >> Main changes: >> 1. Java-side API refactoring: >> - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on >> architectures like AArch64. >> 2. C2 compiler IR refactoring: >> - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. >> 3. Backend changes: >> - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. >> >> Performance: >> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: >> >> Benchmark Mode Cnt Unit SIZE Before After Gain >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.31... > > Ping again~ could any one please take a look at this PR? Thanks a lot! > Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing and get back. > > Do you have any idea about following regression? > > ``` > GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 64 55844.814 48311.847 0.86 > GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 256 15139.459 13009.848 0.85 > GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 1024 3861.834 3284.944 0.85 > GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 4096 938.665 817.673 0.87 > ``` > > Best Regards Yes, I also observed such regression. After analyzing, I found it was caused by the java side changes, which influences the range check elimination inside `IntVector.fromArray()` and `ByteVector.intoArray()` in the benchmark. The root cause is the counted loop in following benchmark case is not recognized by compiler as expected: public void microByteGather256() { for (int i = 0; i < SIZE; i += B256.length()) { ByteVector.fromArray(B256, barr, 0, index, i) .intoArray(bres, i); } } ``` The loop iv phi node is not recognized successfully when C2 recognize the counted loop pattern, because it was casted twice with `CastII` in this case. The ideal graph looks like: Loop \ \ / ------------------------- \ / | Phi | | | CastII | | | CastII | | | \ ConI | \ | | AddVI | |--------------------| Relative code is https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1667. Before the change, the graph should be: Loop \ \ / ------------------------- \ / | Phi | | | CastII | | | | \ ConI | \ | | AddVI | |--------------------| ``` The difference comes from the index generation in `ByteVector.fromArray()` (I mean calling of `IntVector.fromArray()` in java). Before, the `i` in above loop is not directly used by `IntVector.fromArray()`. Instead, it was used by another loop phi node. Hence, there is no additional `CastII`. But after my change, the loop in the java implementation of `ByteVector.fromArray()` is removed, and `i` is directly used by `IntVector.fromArray()` . It will be used by boundary check before loading the indexes. Hence another `CastII` is generated. When recognizing the loop iv phi node, it will check whether the `Phi` is used by a `CastII` first. And get the input of the `CastII` if then. But this check only happens once. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1659 if (xphi->Opcode() == Op_Cast(iv_bt)) { xphi = xphi->in(1); } Once the `PhiNode` is casted more than one times, the pattern is not recognized. I think we should refine the logic of recognizing the counted loop, by changing above `if` to `while` to make the iv phi node is recognized successfully. Potential change should be: while (xphi->Opcode() == Op_Cast(iv_bt)) { xphi = xphi->in(1); } I'v tested this change, and found the benchmarks with regression can be improved as before. Consider I'm not familiar with C2's loop transform code, I prefer to do more investigation for this issue, and may fix it with a followed-up patch. Any suggestions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2892720654 From d.ukhlov at gmail.com Tue May 20 02:42:19 2025 From: d.ukhlov at gmail.com (Dmytro Ukhlov) Date: Tue, 20 May 2025 05:42:19 +0300 Subject: Reducing Classloader's parallelLockMap memory consumption proposal Message-ID: Hello! I created PR is scope of jenkins-core project: https://github.com/jenkinsci/jenkins/pull/10659 Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675 In this PR i propped to override protected Object getClassLoadingLock(String className) method and use weak references for lock objects Jenkins is a plugable platform, each plugin has its own class loader and its parallelLockMap may consume 10mb of RAM. As a result it might have 2gb overhead if ~200 plugins installed. Jenkins maintainers ask me to consider making this improvement in base From iklam at openjdk.org Tue May 20 03:43:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 20 May 2025 03:43:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v11] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/0956fcad..502d1c07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From epeter at openjdk.org Tue May 20 05:37:51 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 20 May 2025 05:37:51 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Tue, 20 May 2025 02:22:13 GMT, Xiaohong Gong wrote: >> Ping again~ could any one please take a look at this PR? Thanks a lot! > >> Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing and get back. >> >> Do you have any idea about following regression? >> >> ``` >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 64 55844.814 48311.847 0.86 >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 256 15139.459 13009.848 0.85 >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 1024 3861.834 3284.944 0.85 >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 4096 938.665 817.673 0.87 >> ``` >> >> Best Regards > > Yes, I also observed such regression. After analyzing, I found it was caused by the java side changes, which influences the range check elimination inside `IntVector.fromArray()` and `ByteVector.intoArray()` in the benchmark. The root cause is the counted loop in following benchmark case is not recognized by compiler as expected: > > public void microByteGather256() { > for (int i = 0; i < SIZE; i += B256.length()) { > ByteVector.fromArray(B256, barr, 0, index, i) > .intoArray(bres, i); > } > } > ``` > The loop iv phi node is not recognized successfully when C2 recognize the counted loop pattern, because it was casted twice with `CastII` in this case. The ideal graph looks like: > > Loop > \ > \ / ----------------------------- > \ / | > Phi | > | | > CastII | > | | > CastII | > | | > \ ConI | > \ | | > AddVI | > |-------------------------| > > Relative code is https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1667. > > Befor... @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here. Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted): https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661 I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that. > Yes, I also observed such regression. It would be nice if you proactively mentioned regressions, so it does not have to be pointed out by reviewers. For me, it could be ok to fix it in a follow-up patch. I think we are too close to RDP1 for JDK25 now anyway, and so we could push this patch here into JDK26, and then we have enough time in JDK26 to investigate the regression. Even better would be if we could do the other patch first, so we never even encounter a regression. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2893017948 From xgong at openjdk.org Tue May 20 05:42:51 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 20 May 2025 05:42:51 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Tue, 20 May 2025 02:22:13 GMT, Xiaohong Gong wrote: >> Ping again~ could any one please take a look at this PR? Thanks a lot! > >> Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing and get back. >> >> Do you have any idea about following regression? >> >> ``` >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 64 55844.814 48311.847 0.86 >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 256 15139.459 13009.848 0.85 >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 1024 3861.834 3284.944 0.85 >> GatherOperationsBenchmark.microByteGather256 thrpt 30 ops/ms 4096 938.665 817.673 0.87 >> ``` >> >> Best Regards > > Yes, I also observed such regression. After analyzing, I found it was caused by the java side changes, which influences the range check elimination inside `IntVector.fromArray()` and `ByteVector.intoArray()` in the benchmark. The root cause is the counted loop in following benchmark case is not recognized by compiler as expected: > > public void microByteGather256() { > for (int i = 0; i < SIZE; i += B256.length()) { > ByteVector.fromArray(B256, barr, 0, index, i) > .intoArray(bres, i); > } > } > ``` > The loop iv phi node is not recognized successfully when C2 recognize the counted loop pattern, because it was casted twice with `CastII` in this case. The ideal graph looks like: > > Loop > \ > \ / ----------------------------- > \ / | > Phi | > | | > CastII | > | | > CastII | > | | > \ ConI | > \ | | > AddVI | > |-------------------------| > > Relative code is https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1667. > > Befor... > @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here. > > Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted): > > https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661 > > I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that. Sounds good to me. I will have a deep investigation for it. Thanks! > > Yes, I also observed such regression. > > It would be nice if you proactively mentioned regressions, so it does not have to be pointed out by reviewers. > > For me, it could be ok to fix it in a follow-up patch. I think we are too close to RDP1 for JDK25 now anyway, and so we could push this patch here into JDK26, and then we have enough time in JDK26 to investigate the regression. Even better would be if we could do the other patch first, so we never even encounter a regression. Sounds good to me. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2893026228 From jpai at openjdk.org Tue May 20 06:10:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 20 May 2025 06:10:55 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Move intrinsic to be a subsection; just one most common function of the annotation > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java > > Co-authored-by: Raffaello Giulietti > - Shorter first sentence > - Updates, thanks to John > - Refine validation and defensive copying > - 8355223: Improve documentation on @IntrinsicCandidate src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 39: > 37: *

      Intrinsification

      > 38: * The most frequently special treatment is intrinsification, which replaces a > 39: * candidate method's body, bytecode or native, with handwritten platform Is this sentence missing the word "code" after "native"? Should it have been: > bytecode or native code, ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097002980 From jpai at openjdk.org Tue May 20 06:10:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 20 May 2025 06:10:56 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 19:55:58 GMT, John R Rose wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Move intrinsic to be a subsection; just one most common function of the annotation >> - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate >> - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate >> - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java >> >> Co-authored-by: Raffaello Giulietti >> - Shorter first sentence >> - Updates, thanks to John >> - Refine validation and defensive copying >> - 8355223: Improve documentation on @IntrinsicCandidate > > src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 47: > >> 45: * intrinsics necessary. >> 46: *

      >> 47: * Intrinsification may never happen, or happen at any moment during execution. > > s/or happen/or may happen/ (easier to parse) Hello John, are there are any hotspot VM flags that can be enabled to check whether or not intrinsification happen for a particular method during the lifetime of an application? Should any of those flags be documented in this proposed text? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097001318 From jpai at openjdk.org Tue May 20 06:21:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 20 May 2025 06:21:54 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Move intrinsic to be a subsection; just one most common function of the annotation > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java > > Co-authored-by: Raffaello Giulietti > - Shorter first sentence > - Updates, thanks to John > - Refine validation and defensive copying > - 8355223: Improve documentation on @IntrinsicCandidate src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 50: > 48: * For example, the bytecodes of a candidate method may be executed by lower > 49: * compilation tiers of VM execution, while higher compilation tiers may replace > 50: * the bytecodes with specialized assembly code and/or compiler IR. Therefore, > while higher compilation tiers may replace the bytecodes with specialized assembly code and/or compiler IR Is there ever a case, where for a `@IntrinsicCandidate` method, the runtime will choose to execute the instrinsic for that method for a certain duration and then at a later point in time replace the intrinsic with compiler generated code? In other words, once the runtime executes the intrinsic implementation for a `@IntrinsicCandidate` method, will the method's implementation be switched to anything else during the lifetime of an application? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097016882 From alanb at openjdk.org Tue May 20 06:50:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 May 2025 06:50:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 138: > 136: * {@link #isCompletedAbnormally} is true if a task was either > 137: * cancelled or encountered an exception, in which case {@link > 138: * #getException()} will return either the encountered exception or Looks right too, the private overload of getException was added in JDK 22. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097113958 From alanb at openjdk.org Tue May 20 06:54:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 May 2025 06:54:58 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: <2ZTFvRUO5p9CkTijR0qS6x9bwgbI3o4C286Wk9HvHVU=.04f8ca7b-cdf9-4a09-9d3d-587a414d51e1@github.com> On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2023: > 2021: /** > 2022: * Provides a service with one or more implementations. The package for > 2023: * each {@link Provides#providers() provider} (or provider factory) is okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097120353 From stuefe at openjdk.org Tue May 20 07:33:14 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 May 2025 07:33:14 GMT Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() Message-ID: Hi, please consider the following patch. This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors (the fail pipe fd needs to be kept open right up to the execve(), and we have internal file descriptors in use during iteration of the proc file system to find open file descriptors). This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem of needing to keep a log file descriptor open right until execve happens). Note: Using fcntl with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409 This patch also fixes two subtle bugs: - we didn't check the return value of the close() inside closeAllFileDescriptors - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it) ---- Testing: We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and with out without FD_CLOEXEC. - in the parent JVM, the test opens a file in native code without FD_CLOEXEC - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open I verified that the test correctly detects a broken implementation that leaks file descriptors. I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX). I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green. ------------- Commit messages: - close dir fd on fcntl error - Mark fds with cloexec, plus test Changes: https://git.openjdk.org/jdk/pull/25301/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8210549 Stats: 204 lines in 5 files changed: 181 ins; 9 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301 PR: https://git.openjdk.org/jdk/pull/25301 From sarma.swaranga at gmail.com Tue May 20 07:53:39 2025 From: sarma.swaranga at gmail.com (Swaranga Sarma) Date: Tue, 20 May 2025 00:53:39 -0700 Subject: Towards a JSON API for the JDK In-Reply-To: <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hello, I am not a language or a library developer by any means but I wanted to offer my perspective as a prospective user of such an API. I am sure this was considered but feel compelled to raise it regardless - instead of the low level tree API (and baking whatever design choice is made forever into the JDK), was a higher level data binding API considered while keeping any low-level tree implementation private to the JDK? Basically a way to take a Json document (String/Reader/...) and deserialize it into an instance of a user-defined Record (and vice versa). From my perspective, this would be a more useful addition for the simpler and most common cases and if there are more complex requirements around flexibility/performance then there are lots of 3rd party options available in Java. I do not have data to back my hunch that this will be more valuable but I am offering my real production use-case where I would find it useful: I have a bunch of rest APIs for which my callers want me to vend a Java client that has the Java POJO classes for the request and response shapes; they don't want to write it by hand which is a reasonable ask. I usually create a Java library that uses the standard Java Http client under the hood to make the calls and serialize and deserialize the DTOs using Jackson. The problem is that as soon as I add Jackson to the client library's dependencies, it is no longer a zero-runtime dependency library and the callers have to deal with multiple versions, version incompatibility etc (in case they also use Jackson in the client app). With a Json api with support for data binding in the standard library, I could vend a very thin zero additional dependencies Java client to my callers. This is not quite what JEP 198 is stating as its goals but I am also not sure if this discussion is towards an implementation for that JEP. Thank you Swaranga On Mon, May 19, 2025 at 2:56?PM wrote: > > > ------------------------------ > > *From: *"Paul Sandoz" > *To: *"Remi Forax" > *Cc: *"Brian Goetz" , "core-libs-dev" < > core-libs-dev at openjdk.org> > *Sent: *Monday, May 19, 2025 11:18:26 PM > *Subject: *Re: Towards a JSON API for the JDK > > Those extending the non-sealed subtypes of JsonValue must conform to the > requirements that are specified. The current documentation could be more > clearly written as to what those requirements are. Of course we cannot > enforce those requirements any more than we can enforce the requirements > specified for implementations of List. > > > List is such a good example. > For a List, like for a JsonValue, you have no idea if the implementation > is mutable or not, > so you can use a defensive copy using List.copyOf() (or > Collections.unmodifiableList(new ArrayList<>(list)) in the older version of > Java). > > How to do a defensive copy of a JsonValue ? > > The other issue I see is lazyness in Json.parse(). The API is restricted > to String/char[], so restricted to JSON document that are not big. > If the document is not big, lazyness usually make things slower and it > also delays the moment you know if the document is a valid JSON document or > not. > With the actual design, you have no way to know if a JSON document is > valid. > > If you combine both things, the fact that you have a big list of > requirements for each subtypes and eager parsing, you are not far from > having only one implementation possible, > hence the idea of implementing real ADTs using records. > > > Paul. > > > R?mi > > > > On May 19, 2025, at 1:56?PM, forax at univ-mlv.fr wrote: > > > > ------------------------------ > > *From:*"Paul Sandoz" > *To:*"Remi Forax" > *Cc:*"Brian Goetz" , "core-libs-dev" < > core-libs-dev at openjdk.org> > *Sent:*Monday, May 19, 2025 10:02:50 PM > *Subject:*Re: Towards a JSON API for the JDK > > > > On May 19, 2025, at 8:16?AM, Remi Forax wrote: > > Okay, > i've taken a look to the design and this is not pretty. > > > That seems an exaggerated statement to me. It's a trade-off, a compromise, > allowing others to implement their own parsers, perhaps from non-textual > representations. So of course we cannot enforce certain constraints and we > need to specify how implementations must behave. > > > The main issue is that the javadoc claims that > "BothJsonValueinstances and their underlying values are immutable." > but at the same time any subtypes of JsonValue is non-sealed so anyone can > implement let say JsonString and adds it's own mutable implementation. > > > You can not claim that JsonValue instances are immutable while obviously > they are not. > You can not claim that JsonValue subtypes are ADTs while obviously > JsonValue is not algebraic. > > You allow anybody to write their own class inside the JsonValue hierarchy, > so there is no safety, strings can be not escaped correctly, number can > represent invalid values, etc. > > The minute I write a method that takes a JsonValue as parameter i'm > writing unsafe code, > > You are hoping that nobody will ever extend JsonValue subtypes, that's > wishful thinking, this is not a safe design ... this is not pretty. > > R?mi > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Tue May 20 08:28:51 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 20 May 2025 08:28:51 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 02:11:34 GMT, Shaojin Wen wrote: >> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. >> >> The following is the output information of PrintInlining: >> >> @ 9 java.lang.String:: (12 bytes) inline (hot) >> !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) >> ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big >> >> >> In Java code, the big method that cannot be inlined is the following constructor >> >> >> String(Charset charset, byte[] bytes, int offset, int length) {} >> >> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > create method share variant val & coder I wonder if it would be better to first check `COMPACT_STRINGS` in a first-level `if` and then branch off to separate support methods? Looking at the comments near the declaration of `COMPACT_STRINGS`, this might provide additional benefits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25290#issuecomment-2893426860 From azeller at openjdk.org Tue May 20 08:34:51 2025 From: azeller at openjdk.org (Arno Zeller) Date: Tue, 20 May 2025 08:34:51 GMT Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in exception In-Reply-To: References: Message-ID: <_2c3O7v_NV_9PHUw0wVrniD2DrMlK2oBFPq7Wralu9Q=.aa61f5d4-a046-4db5-a29c-df75fa7c3648@github.com> On Mon, 19 May 2025 20:19:25 GMT, Brian Burkhalter wrote: > @ArnoZeller Please issue the `/integrate` command so that this request may be sponsored. Thanks for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25250#issuecomment-2893448783 From duke at openjdk.org Tue May 20 08:34:51 2025 From: duke at openjdk.org (duke) Date: Tue, 20 May 2025 08:34:51 GMT Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in exception In-Reply-To: References: Message-ID: On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller wrote: > When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones. @ArnoZeller Your change (at version 8506932622f713e0a21dda7150128773718d283a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25250#issuecomment-2893454910 From swen at openjdk.org Tue May 20 08:48:53 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 08:48:53 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 08:26:20 GMT, Per Minborg wrote: > I wonder if it would be better to first check `COMPACT_STRINGS` in a first-level `if` and then branch off to separate support methods? Looking at the comments near the declaration of `COMPACT_STRINGS`, this might provide additional benefits. Now all the broken methods have CodeSize < 325 and can be inlined by C2. If we check COMPACT_STRINGS at the first level, we need to change more. I want to achieve the goal with minimal changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25290#issuecomment-2893507842 From mik3hall at gmail.com Tue May 20 09:13:19 2025 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 20 May 2025 04:13:19 -0500 Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: > On May 19, 2025, at 7:53?PM, Alexander Matveev wrote: > > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: Thanks for the follow-up. To the comments on the issue of would it be useful for jpackage to do this. The runtime images that you get with make images doesn?t work for applications. So it can?t be used to test applications. I assume your changes make that possible. How often you might want to test jdk builds against applications I don?t know. Validation again seemed to me to be important. In trying this out I attempted different ways to use the ?runtime-image parameter. All of them succeeded in creating dmg?s but the images were not valid. Is there some test being added? From mik3hall at gmail.com Tue May 20 09:27:57 2025 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 20 May 2025 04:27:57 -0500 Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: > On May 20, 2025, at 4:13?AM, Michael Hall wrote: > > The runtime images that you get with make images doesn?t work for applications. I might be misremembering on this. It might be useable as a runtime image to embed in applications with jpackage? It is not valid as a system runtime image that can be installed into JavaVirtualMachines and become the default system runtime for command line and applications. This would sort of seem the purpose of a jpackage option that allows putting a runtime into a dmg that can be drag and drop installed into JavaVirtualMachines. It should be a valid runtime for this purpose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Tue May 20 09:34:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 20 May 2025 09:34:51 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com> On Mon, 19 May 2025 19:08:31 GMT, Roger Riggs wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> move jdk.internal.nio.Cleaner to sun.nio > > src/java.base/share/classes/java/nio/Bits.java line 170: > >> 168: // without it that test likely fails. Since failure here >> 169: // ends in OOME, there's no need to hurry. >> 170: for (int sleeps = 0; true; ) { > > More typical coding pattern in openjdk code. Here and elsewhere in this PR. > Suggestion: > > while (true) { > int sleeps = 0; That's not the same thing, and doesn't do what's needed here. Perhaps you meant int sleeps = 0; while (true) { I like limiting the scope of the variable. Is that a suggestion or a request to change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2097487954 From vklang at openjdk.org Tue May 20 10:14:03 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 20 May 2025 10:14:03 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: References: Message-ID: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com> On Tue, 11 Feb 2025 03:54:56 GMT, He-Pin(kerr) wrote: >> Motivation: >> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. >> >> Modification: >> Add detail error messages. >> >> Result: >> Helpful messages. > > It would be much nicer if you take this one:), we are on JDK 21 and want to have this in the next LTS. @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2893787581 From azeller at openjdk.org Tue May 20 10:22:01 2025 From: azeller at openjdk.org (Arno Zeller) Date: Tue, 20 May 2025 10:22:01 GMT Subject: Integrated: 8357052: java/io/File/GetXSpace.java prints wrong values in exception In-Reply-To: References: Message-ID: On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller wrote: > When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones. This pull request has now been integrated. Changeset: f8fc7eeb Author: Arno Zeller Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/f8fc7eeb24156f9c38ddd478b026074f522e39c4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8357052: java/io/File/GetXSpace.java prints wrong values in exception Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/25250 From liach at openjdk.org Tue May 20 10:38:51 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 May 2025 10:38:51 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 06:07:07 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 47: >> >>> 45: * intrinsics necessary. >>> 46: *

      >>> 47: * Intrinsification may never happen, or happen at any moment during execution. >> >> s/or happen/or may happen/ (easier to parse) > > Hello John, are there are any hotspot VM flags that can be enabled to check whether or not intrinsification happen for a particular method during the lifetime of an application? Should any of those flags be documented in this proposed text? I see there is a `ControlIntrinsic` flag in `globals.hpp`, but I am not sure how it actually interacts with intrinsics. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097622562 From duke at openjdk.org Tue May 20 10:54:44 2025 From: duke at openjdk.org (He-Pin (kerr)) Date: Tue, 20 May 2025 10:54:44 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v5] In-Reply-To: References: Message-ID: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> > Motivation: > When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. > > Modification: > Add detail error messages. > > Result: > Helpful messages. He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java Co-authored-by: Viktor Klang - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java Co-authored-by: Viktor Klang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23050/files - new: https://git.openjdk.org/jdk/pull/23050/files/b4a10d1c..ad67bd17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23050/head:pull/23050 PR: https://git.openjdk.org/jdk/pull/23050 From vyazici at openjdk.org Tue May 20 11:34:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 May 2025 11:34:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods In-Reply-To: References: Message-ID: On Fri, 16 May 2025 18:11:39 GMT, Naoto Sato wrote: > `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. src/java.base/share/classes/java/io/Console.java line 560: > 558: static final Charset STDIN_CHARSET = > 559: Charset.forName(System.getProperty("stdin.encoding"), UTF_8.INSTANCE); > 560: static final Charset STDOUT_CHARSET = I guess these can be marked `private`? Suggestion: private static final Charset STDIN_CHARSET = Charset.forName(System.getProperty("stdin.encoding"), UTF_8.INSTANCE); private static final Charset STDOUT_CHARSET = src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160: > 158: > 159: try { > 160: Terminal terminal = TerminalBuilder.builder().encoding(outCharset) Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants? test/jdk/java/io/Console/CharsetTest.java line 1: > 1: /* Copyright year update is missing. test/jdk/java/io/Console/StdinEncodingTest.java line 46: > 44: * @run junit StdinEncodingTest > 45: */ > 46: public class StdinEncodingTest { AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.) test/jdk/java/io/Console/StdinEncodingTest.java line 49: > 47: > 48: @Test > 49: @EnabledOnOs({OS.LINUX, OS.MAC}) Shall we replace `@EnabledOnOs` with the `@requires (os.family == "linux" | os.family == "mac")` JTreg directive instead per [JDK-8211673](https://bugs.openjdk.org/browse/JDK-8211673)? test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 36: > 34: > 35: // A test charset provider that decodes every input byte into its uppercase > 36: public class MockCharsetProvider extends CharsetProvider { *Nit:* Maybe a more self-explanatory name, e.g., `UpperCasingCharsetProvider`? test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 83: > 81: while (in.remaining() > 0) { > 82: char c = (char)in.get(); > 83: if (c != '\n') { `Character.toUpperCase('\n') == '\n'`, not? If so, do we still need this `if`-branching? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097641573 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097630717 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097578092 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097718253 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097671831 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097711653 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097704883 From rgiulietti at openjdk.org Tue May 20 11:35:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 20 May 2025 11:35:54 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com> Message-ID: On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 wrote: >> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck? > >> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck? > > @rgiulietti It seems there is a slowdown in the creation of large pseudoprimes, maybe due to `BitSieve` methods. @fabioromano1 I'm ready to approve. Please keep in mind that rampdown is on 2025-06-05, so there is time for other small changes you might want to add to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2894008015 From duke at openjdk.org Tue May 20 11:58:30 2025 From: duke at openjdk.org (kieran-farrell) Date: Tue, 20 May 2025 11:58:30 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: update RFC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/b0b4f7a8..922869b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From duke at openjdk.org Tue May 20 12:02:53 2025 From: duke at openjdk.org (kieran-farrell) Date: Tue, 20 May 2025 12:02:53 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 18:08:18 GMT, Roger Riggs wrote: >> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> update RFC > > src/java.base/share/classes/java/util/UUID.java line 195: > >> 193: * >> 194: * @return A {@code UUID} generated from the current system time >> 195: */ > > Seems like there should be a reference to the RFC somewhere here using the @spec javadoc tag. > > And also in the class javadoc. spec updated in class javadoc to RFC 9562 which obsolete RFC 4122, @spec tag also added above the method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097772811 From aturbanov at openjdk.org Tue May 20 12:09:52 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 20 May 2025 12:09:52 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 11:58:30 GMT, kieran-farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: > > update RFC src/java.base/share/classes/java/util/UUID.java line 213: > 211: int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096); > 212: > 213: // Set version and increased percision time bits Suggestion: // Set version and increased precision time bits ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097785581 From duke at openjdk.org Tue May 20 12:57:34 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 12:57:34 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v10] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Small code simplifications ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/b74fefa5..ed2e7c35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From jlahoda at openjdk.org Tue May 20 13:12:28 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 20 May 2025 13:12:28 GMT Subject: RFR: 8347050: Console.readLine() drops '\' when reading through JLine Message-ID: JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine(). This PR proposes to disable the history expansion. ------------- Commit messages: - Adding bug number - 8347050: Console.readLine() drops '\' when reading through JLine Changes: https://git.openjdk.org/jdk/pull/25326/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25326&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347050 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25326.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25326/head:pull/25326 PR: https://git.openjdk.org/jdk/pull/25326 From duke at openjdk.org Tue May 20 13:20:10 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 13:20:10 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v11] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Removed redundant code for choosing division's algorithm logic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/ed2e7c35..7a0b0211 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=09-10 Stats: 72 lines in 1 file changed: 0 ins; 69 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From duke at openjdk.org Tue May 20 13:37:51 2025 From: duke at openjdk.org (kieran-farrell) Date: Tue, 20 May 2025 13:37:51 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 18:17:09 GMT, Roger Riggs wrote: > Can the sub-microsecond value just be truncated and avoid the expensive divide operation?' method 3 of secion 6.2 of https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters states > start with the portion of the timestamp expressed as a fraction of the clock's tick value (fraction of a millisecond for UUIDv7). Compute the count of possible values that can be represented in the available bit space, 4096 for the UUIDv7 rand_a field. Using floating point or scaled integer arithmetic, multiply this fraction of a millisecond value by 4096 and round down (toward zero) to an integer result to arrive at a number between 0 and the maximum allowed for the indicated bits, which sorts monotonically based on time. ' so i think we might have to keep the division? though i re-shuffled the equation to `int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);` which gives scaled integer division rather than floating point and gave a very slight imporved perfomance to 143.758 ? 2.135 ns/op ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097994819 From duke at openjdk.org Tue May 20 13:59:54 2025 From: duke at openjdk.org (kieran-farrell) Date: Tue, 20 May 2025 13:59:54 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 13:35:32 GMT, kieran-farrell wrote: >> src/java.base/share/classes/java/util/UUID.java line 219: >> >>> 217: randomBytes[8] |= (byte) 0x80; >>> 218: >>> 219: return new UUID(randomBytes); >> >> This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next(). >> Can the sub-microsecond value just be truncated and avoid the expensive divide operation? > >> Can the sub-microsecond value just be truncated and avoid the expensive divide operation?' > > method 3 of secion 6.2 of https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters states > >> start with the portion of the timestamp expressed as a fraction of the clock's tick value (fraction of a millisecond for UUIDv7). Compute the count of possible values that can be represented in the available bit space, 4096 for the UUIDv7 rand_a field. Using floating point or scaled integer arithmetic, multiply this fraction of a millisecond value by 4096 and round down (toward zero) to an integer result to arrive at a number between 0 and the maximum allowed for the indicated bits, which sorts monotonically based on time. ' > > so i think we might have to keep the division? though i re-shuffled the equation to > > `int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);` > > which gives scaled integer division rather than floating point and gave a very slight imporved perfomance to 143.758 ? 2.135 ns/op > This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next(). do you mean to create the UUID using most and least significant bytes? if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method, but the below implemntation keeping with the nextByte(byte[]) api brings a performance increase to 121.128 ? 30.486 ns/op, though the code might appear a little roundabout. public static UUID timestampUUID() { long msTime = System.currentTimeMillis(); long nsTime = System.nanoTime(); // Scale sub-ms nanoseconds to a 12-bit value int nsBits = (int) ((nsTime % 1_000_000L) * 4096L / 1_000_000L); // Compose the 64 most significant bits: [48-bit msTime | 4-bit version | 12-bit nsBits] long mostSigBits = ((msTime & 0xFFFFFFFFFFFFL) << 16) | (0x7L << 12) | nsBits; // Generate 8 random bytes for least significant bits byte[] randomBytes = new byte[8]; SecureRandom ng = UUID.Holder.numberGenerator; ng.nextBytes(randomBytes); long leastSigBits = 0; for (int i = 0; i < 8; i++) { leastSigBits = (leastSigBits << 8) | (randomBytes[i] & 0xFF); } // Set variant (bits 62?63) to '10' leastSigBits &= 0x3FFFFFFFFFFFFFFFL; leastSigBits |= 0x8000000000000000L; return new UUID(mostSigBits, leastSigBits); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098044396 From dfuchs at openjdk.org Tue May 20 14:04:51 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 20 May 2025 14:04:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA Changes to `java.net.Socket` LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2854340236 From rgiulietti at openjdk.org Tue May 20 14:11:57 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 20 May 2025 14:11:57 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v11] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: On Tue, 20 May 2025 13:20:10 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Removed redundant code for choosing division's algorithm logic The last commit about `divide` is a bit out of scope. While it is simple, I suggest deferring it to another PR. I've long planned a reorganization of `BigInteger`s implementation to shift the heavy-lifting work to `MutableBigInteger` (in particular, the multiplication algorithms) and leave `BigInteger` as a simple wrapper of `MutableBigInteger` (the thinner, the better). The `divide` simplifications could be part of that work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2894578950 From nbenalla at openjdk.org Tue May 20 14:27:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 20 May 2025 14:27:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Mon, 19 May 2025 20:41:13 GMT, Joe Darcy wrote: >> They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) > > Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be. > > As it is, if the see tags are going to stay, I don't think `foo` markup should be used. I will revert the changes to `MethoType.java` and try to make the links to the private methods resolvable. (In a future patch) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2098123931 From rriggs at openjdk.org Tue May 20 14:42:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 20 May 2025 14:42:54 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com> References: <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com> Message-ID: On Tue, 20 May 2025 09:32:08 GMT, Kim Barrett wrote: >> src/java.base/share/classes/java/nio/Bits.java line 170: >> >>> 168: // without it that test likely fails. Since failure here >>> 169: // ends in OOME, there's no need to hurry. >>> 170: for (int sleeps = 0; true; ) { >> >> More typical coding pattern in openjdk code. Here and elsewhere in this PR. >> Suggestion: >> >> while (true) { >> int sleeps = 0; > > That's not the same thing, and doesn't do what's needed here. Perhaps you meant > > int sleeps = 0; > while (true) { > > I like limiting the scope of the variable. Is that a suggestion or a request to change? right, your form does better limit the scope of the loop, and is correct as is; (just looks unusual) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2098160773 From duke at openjdk.org Tue May 20 15:05:17 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 20 May 2025 15:05:17 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v10] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Tweaking exact wording. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/e5725599..793e1856 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=08-09 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From michaelm at openjdk.org Tue May 20 15:31:12 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 20 May 2025 15:31:12 GMT Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug Message-ID: Hi, This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines. A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable. Thanks, Michael ------------- Commit messages: - test update Changes: https://git.openjdk.org/jdk/pull/25331/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25331&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353124 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25331/head:pull/25331 PR: https://git.openjdk.org/jdk/pull/25331 From paul.sandoz at oracle.com Tue May 20 15:53:16 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 May 2025 15:53:16 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <3DE8F8D4-C203-481D-91E6-414698D43A86@oracle.com> I think I see what you mean, although to me the general characterization as construction/deconstruction is too narrow - there are a zillion ways to pack-in and pack-out the tree, some partial, and some lossy etc. The canonical pack-in/out is arguably parsing and writing from and to JSON documents. fromUptyped is way to ?pack-in? the tree, transforming maps and lists, where leaf elements are directly input to the construction of JSON (leaf) values. toUptyped is the functional inverse to "pack-out?, and when we have deconstructor patterns we can more clearly and concisely express the deconstruction relationship in the switch statement e.g., perhaps like [1]. I think it a feature that they directly lean into construction and (currently implement) deconstruction of JSON values without much or any embellishment. This of course punts on the problem of dealing with present, absent, or null values of a field. Perhaps that is more suited for data binding use cases? Paul. [1] public static Object toUntyped(JsonValue src) { Objects.requireNonNull(src); return switch (src) { case JsonObject(Map members)) -> members.entrySet().stream() .collect(LinkedHashMap::new, // to allow `null` value (m, e) -> m.put(e.getKey(), Json.toUntyped(e.getValue())), HashMap::putAll); case JsonArray(List values)) -> values.stream() .map(Json::toUntyped) .toList(); case JsonBoolean(boolean value) -> value; case JsonNull _ -> null; case JsonNumber(Number value) -> value; case JsonString(String value) -> value; }; } On May 19, 2025, at 3:46?PM, Ethan McCue wrote: What I mean by central in this context isn't that it's at the core of things and features are built on top of it - as you note it is a valid transformation of the hierarchy. What I mean is that absent other construction/deconstruction apis it is the most convenient avenue for those tasks. So code using the API would trend towards using it. See Remi's usage of fromUntyped elsewhere in the discussion tree. The thing that the language doesn't have yet is patterns. We have all the mechanism for creating objects. The broad issue I see is that, if we take the view that >in general< deconstruction should be the dual of construction - the mechanics for construction should probably be influenced by how you want people pulling these things apart. Basic example - JsonString.of - that is null hostile for good reason, but it is very easy to imagine wanting to write code that deals uniformly with absent, null, and string values for a field in an object. So that puts a pressure - beyond creation ergonomics - on a Json.of that is null-tolerant. Since that would be a good place for a dual pattern for pulling out a possibly nullable object member. (but still wouldn't solve for absent ones - I have a doc somewhere with like 15 options none of which inspire joy and many of which are conditional on exactly how patterns ship) On Mon, May 19, 2025, 3:55?PM Paul Sandoz > wrote: > > This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing one particular encoding of JSON and making it central to the API. Is that really the most important encoding? > It's one opinionated kind, a simple bi-directional mapping (embedding-projection pair) based on what the json values contain. The implementations can be entirely written less than 100 lines of code using the public API (there are more lines for the documentation). Users can easily write their own and can serve as an example with a bit more exposition in the documentation. The methods could be removed and it would not affect anything else, so it's not fundamental nor central. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Tue May 20 15:53:16 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 20 May 2025 15:53:16 GMT Subject: Integrated: 8355954: File.delete removes read-only files (win) In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 23:38:02 GMT, Brian Burkhalter wrote: > This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired. This pull request has now been integrated. Changeset: bcf5cd69 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/bcf5cd69413abd95bf7c3a0249fe1c9b713c85a6 Stats: 132 lines in 5 files changed: 106 ins; 4 del; 22 mod 8355954: File.delete removes read-only files (win) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/24977 From duke at openjdk.org Tue May 20 15:53:17 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 15:53:17 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v12] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Revert "Removed redundant code for choosing division's algorithm logic" This reverts commit 7a0b0211c658014f8c3736f6032e7d3ef35fb820. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/7a0b0211..8c4587bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=10-11 Stats: 72 lines in 1 file changed: 69 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From jpai at openjdk.org Tue May 20 15:56:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 20 May 2025 15:56:02 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v4] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > warning src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 348: > 346: */ > 347: public static int getChars(long i, int index, char[] buf) { > 348: // Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Hello Shaojin, I think this was a misplaced comment previously. Looking at the implementation of this method, there's no "unsafe" access happening in this method's implementation. It ends up calling `putChar` which does a Java style array access and thus is backed by the language's bounds checking. Removing this comment I believe is the right thing. Having said that, I am unsure the javadoc comment of this method should refer to `DecimalDigits#uncheckedGetCharsUTF16` because that is confusing and misleading. Should we change the javadoc text of this method to: > Places characters representing the long i into the character array buf. The characters are placed into the buffer backwards starting with the least significant digit at the specified index (exclusive), and working backwards from there. Would that accurately describe what this method's implementation currently does? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2098328985 From lancea at openjdk.org Tue May 20 16:07:57 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 20 May 2025 16:07:57 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> Message-ID: On Sat, 17 May 2025 01:27:38 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 285: > 283: \ versions.\n\ > 284: \ Warn if there are duplicate or invalid file names > 285: Would probably be clearer if: > main.help.opt.main.validate=\ > \ --validate Validate the contents of the jar archive. This option: \n\ > \ - Validates that the API exported by a multi-release\n\ > \ jar archive is consistent across all different release\n\ > \ versions.` > \ - Issues a warning if there are invalid or duplicate file names > src/jdk.jartool/share/man/jar.md line 222: > 220: ## Integrity of a jar Archive > 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools > 222: other than the `jar` command. The `--validate` option performs the following integrity checks: I would simplify to: The `--validate` option may be used to perform the following integrity checks against a jar archive: src/jdk.jartool/share/man/jar.md line 239: > 237: > 238: Check with the developer to ensure the jar archive integrity when warnings observed after using > 239: the `--validate` option. I don't see a need for this last sentence given the last sentence in the paragraph above. I would not know who "the developer" is (though the same could be said of "the original source of the jar file" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098323828 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098341490 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098346535 From duke at openjdk.org Tue May 20 16:16:43 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 16:16:43 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v13] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Small code simplifications ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/8c4587bf..d6b4d2e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=11-12 Stats: 15 lines in 1 file changed: 0 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From swen at openjdk.org Tue May 20 16:22:58 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 16:22:58 GMT Subject: RFR: 8357063: Document preconditions for DecimalDigits methods [v4] In-Reply-To: References: Message-ID: <9so71TcpEGWXLnsBLZmWHPhmg3-9doY9YgsbUoce02c=.ed9cfb78-3edf-4ff1-91cc-22a7b747de27@github.com> On Tue, 20 May 2025 15:53:34 GMT, Jaikiran Pai wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> warning > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 348: > >> 346: */ >> 347: public static int getChars(long i, int index, char[] buf) { >> 348: // Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. > > Hello Shaojin, I think this was a misplaced comment previously. Looking at the implementation of this method, there's no "unsafe" access happening in this method's implementation. It ends up calling `putChar` which does a Java style array access and thus is backed by the language's bounds checking. > > Removing this comment I believe is the right thing. Having said that, I am unsure the javadoc comment of this method should refer to `DecimalDigits#uncheckedGetCharsUTF16` because that is confusing and misleading. > > Should we change the javadoc text of this method to: > >> Places characters representing the long i into the character array buf. The characters are placed into the buffer backwards starting with the least significant digit at the specified index (exclusive), and working backwards from there. > > Would that accurately describe what this method's implementation currently does? This method has the same algorithm as uncheckedGetCharsUTF16, the only difference is the safe array access of char[] and the unsafe access of byte[] by uncheckedPutPairUTF16. This method was also copied from uncheckedGetCharsUTF16 and then modified when the code was written, so I think the reference here is OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2098387154 From duke at openjdk.org Tue May 20 16:41:08 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 16:41:08 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v14] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Avoid redundance of stripLeadingZeroInts() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/d6b4d2e1..f3ef2601 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=12-13 Stats: 31 lines in 1 file changed: 0 ins; 14 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From asemenyuk at openjdk.org Tue May 20 16:44:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 May 2025 16:44:54 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 246: > 244: > 245: public static String getPropertyFromFile(Path filename, String name) { > 246: // load properties file That is a bad idea to expose jpackage API that uses jpackage's Log class. Where will these log messages go? src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 251: > 249: properties.load(reader); > 250: } catch (IOException e) { > 251: Log.error("Exception: " + e.getMessage()); This is an exception swallow, not good. Logging it in place doesn't make it right. If this is an unrecoverable error, it should be forwarded to the caller. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098429635 PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098434269 From asemenyuk at openjdk.org Tue May 20 16:38:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 May 2025 16:38:54 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 45: > 43: resource.app-info-plist=Application Info.plist > 44: resource.runtime-info-plist=Java Runtime Info.plist > 45: resource.runtime-image-info-plist=Java Runtime Bundle Info.plist `resource.runtime-bundle-info-plist` would be a better name as the list file belongs to a bundle, not the image. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88: > 86: message.codesign.failed.reason.xcode.tools=Possible reason for "codesign" failure is missing Xcode with command line developer tools. Install Xcode with command line developer tools to see if it resolves the problem. > 87: message.runtime-image-invalid=Provided runtime image at "{0}" is invalid or corrupted. > 88: message.runtime-image-invalid.advice=Runtime image should be valid JDK bundle or JDK image. We need negative test cases for these new error conditions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098422966 PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098425687 From asemenyuk at openjdk.org Tue May 20 16:56:58 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 May 2025 16:56:58 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps In-Reply-To: References: Message-ID: <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com> On Fri, 14 Feb 2025 15:01:35 GMT, Stefan Lobbenmeier wrote: > The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space > > You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298: > 296: \ --linux-menu-group \n\ > 297: \ Menu group this application is placed in\n\ > 298: \ --linux-package-deps [, ...]\n\ The value of this CLI option is a string, not a comma-separated string list. For jpackage it is a "pass through" value. Maybe --linux-package-deps \n\ ? ------------- PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2816429421 PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2074396184 From henryjen at openjdk.org Tue May 20 16:57:56 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 20 May 2025 16:57:56 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> Message-ID: On Sat, 17 May 2025 01:27:38 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback src/jdk.jartool/share/man/jar.md line 235: > 233: > 234: The jar tool will return a status code of 0 if there were no integrity issues encountered and a > 235: status code of 1 an issue was found. When an integrity issue is reported, it will often require I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098459726 From asemenyuk at openjdk.org Tue May 20 16:59:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 May 2025 16:59:50 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 199: > 197: } > 198: return version; > 199: }, I guess, this is a workaround for the case when the version comes from JDK's release file. This is the wrong place for this workaround. It should be a part of the code reading version from JDK's release file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098462753 From asemenyuk at openjdk.org Tue May 20 17:02:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 May 2025 17:02:53 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 1004: > 1002: // External runtime image should be R/O unless it is on macOS. > 1003: // On macOS it will be signed ad-hoc or with real certificate. > 1004: return !TKit.isOSX(); Should be return !(TKit.isOSX() && MacHelper.signPredefinedAppImage(cmd)); Otherwise, it will be turned off for macOS entirely. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098467190 From duke at openjdk.org Tue May 20 17:04:24 2025 From: duke at openjdk.org (kieran-farrell) Date: Tue, 20 May 2025 17:04:24 GMT Subject: RFR: 8347027: String replaceAll with Function Message-ID: New API to the String.java class - replaceAllMapped(String, Function) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function). ------------- Commit messages: - whitespace - updates - replaceAllMapped and test Changes: https://git.openjdk.org/jdk/pull/25335/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25335&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347027 Stats: 61 lines in 3 files changed: 61 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25335/head:pull/25335 PR: https://git.openjdk.org/jdk/pull/25335 From asemenyuk at openjdk.org Tue May 20 17:08:59 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 May 2025 17:08:59 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: <1xpPgU-jZVXZaBrp0A7CSqzSSNt8GqgoAvnp3tcLt_g=.8e7cd068-407f-442e-a596-0a9f6f3d4d9f@github.com> On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 337: > 335: } > 336: > 337: return installLocation.resolve(cmd.name() + (cmd.isRuntime() ? ".jdk" : ".app")); Why the ".jdk" suffix and not ".app"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098475988 From duke at openjdk.org Tue May 20 17:12:08 2025 From: duke at openjdk.org (kieran-farrell) Date: Tue, 20 May 2025 17:12:08 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/util/UUID.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/922869b3..c7efd528 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From duke at openjdk.org Tue May 20 17:15:15 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 17:15:15 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v15] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Simplify two's complement in makePositive(int[]) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/f3ef2601..69d24210 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=13-14 Stats: 15 lines in 1 file changed: 5 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From fweimer at redhat.com Tue May 20 17:16:33 2025 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 20 May 2025 19:16:33 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: (Brian Goetz's message of "Fri, 16 May 2025 09:17:16 -0400") References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <87tt5f5hji.fsf@oldenburg.str.redhat.com> * Brian Goetz: > But then we discovered that JSON5 also sneaks in some semantics, by > also supporting the exotic numeric values (NaN, infinities, signed > zero), which now has consequences for "what is a number", the numeric > representation, the API for unpacking numeric values, etc. (Having > multiple parsers is one thing; having multiple parsers that produce > different semantics is entirely another.) But that's independent of JSON5: some data sources expected their numbers to be parsed as integers that require more than 53 bits to represent. That means double as the universal numerical type is out. BigDecimal would work, but may result in unexpected overhead. Thanks, Florian From jlu at openjdk.org Tue May 20 17:19:32 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 20 May 2025 17:19:32 GMT Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly state extlangs are allowed [v2] In-Reply-To: References: Message-ID: > It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: setLanguageTag should mention all conversions, not just extlang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25309/files - new: https://git.openjdk.org/jdk/pull/25309/files/204338ae..2d70bf79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309 PR: https://git.openjdk.org/jdk/pull/25309 From jlu at openjdk.org Tue May 20 17:19:32 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 20 May 2025 17:19:32 GMT Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly state extlangs are allowed [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 00:39:16 GMT, Naoto Sato wrote: >> An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example, >> >> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws >> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-CN").build()` // ==> yue_CN >> >> i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags. (Edit: Forgot to adjust the example) > > OK. I would add these examples here too, which may be more helpful. Actually, `Locale.Builder.setLanguageTag` should mention all of the conversions that are made on the language tag, not just _extlang_ specifically. I'll link to the conversions section in `Locale.forLanguageTag` instead. I also adjusted the _extlang_ example in `forLanguageTag` to indicate that the 4 _extlang_ example is "ill-formed" which should imply `Locale.Builder.setLanguageTag` throws an exception for that respective example. Please see https://github.com/openjdk/jdk/pull/25309/commits/2d70bf799ba1285d599067c3d174dd8bd227db1f. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2098491604 From asemenyuk at openjdk.org Tue May 20 17:20:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 May 2025 17:20:52 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. The description is missing some important changes: - jpackage will attempt to get a package version from the JDK's release file if the `--version` option is not specified. - The bundle's top directory name will have the ".jdk" suffix. I like the idea of reading the package's version from the JDK's release file when bundling a runtime package, but it is out of the scope of the "jpackage produces invalid Java runtime DMG bundles" fix. It should be a separate fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2895251471 From henryjen at openjdk.org Tue May 20 17:32:15 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 20 May 2025 17:32:15 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v10] In-Reply-To: References: Message-ID: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Adapt review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/da4a9139..0caecfcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=08-09 Stats: 12 lines in 2 files changed: 2 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From bpb at openjdk.org Tue May 20 17:35:14 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 20 May 2025 17:35:14 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v24] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Revert previous commit and remove first comma in the change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/a86610d0..0880af29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=22-23 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From bpb at openjdk.org Tue May 20 17:35:14 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 20 May 2025 17:35:14 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22] In-Reply-To: <8SJl_mDv3MuJGgTfW3pc4adoVxHpbwVyPEgD0n2nguM=.d9845fcc-cf54-46e8-b2af-a2ce16f4b991@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <8SJl_mDv3MuJGgTfW3pc4adoVxHpbwVyPEgD0n2nguM=.d9845fcc-cf54-46e8-b2af-a2ce16f4b991@github.com> Message-ID: On Mon, 19 May 2025 07:15:00 GMT, Alan Bateman wrote: >> Thank you Brian, the updated text for this section looks good to me. Once this PR gets integrated, I'll go through the Files.readXXX methods and file an issue to have that text simplified too. > > I see this has been changed to "then some characters, but not all" but it doesn't flow very well. The original sentence, which was copied/modified from InputStream.readAllBytes, is much cleaner and I think I would prefer to go back to that. Maybe Jai's issue could be address by dropping the first comma from the sentence? In 0880af2 reverted previous commit then removed first comma from the modified sentence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2098520689 From duke at openjdk.org Tue May 20 17:41:14 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 17:41:14 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v16] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Some code simplifications for *ValueExact() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/69d24210..9a8678bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=14-15 Stats: 19 lines in 1 file changed: 0 ins; 6 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From duke at openjdk.org Tue May 20 17:52:32 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 17:52:32 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v17] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Use bitwise or instead of + in longValue() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/9a8678bf..1fa0c9e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From duke at openjdk.org Tue May 20 18:02:10 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 20 May 2025 18:02:10 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v18] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: <_LFzlaMFEaJO4FzFpS11uyZev2ReP34ii2QSa-Pn1rU=.456015bc-d718-4c00-9510-5e3d7836c51e@github.com> > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: A minor change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/1fa0c9e0..46114836 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From lancea at openjdk.org Tue May 20 18:03:54 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 20 May 2025 18:03:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> Message-ID: On Tue, 20 May 2025 16:55:44 GMT, Henry Jen wrote: > I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098574945 From rgiulietti at openjdk.org Tue May 20 18:05:55 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 20 May 2025 18:05:55 GMT Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6] In-Reply-To: <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com> Message-ID: On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 wrote: >> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck? > >> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck? > > @rgiulietti It seems there is a slowdown in the creation of large pseudoprimes, maybe due to `BitSieve` methods. @fabioromano1 Please either restrict the changes to "bit operations", like the subject of this PR, or else change the title to something more encompassing, like "8356891: Some code simplifications in BigInteger". ------------- PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2895364988 From henryjen at openjdk.org Tue May 20 18:16:56 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 20 May 2025 18:16:56 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> Message-ID: <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com> On Tue, 20 May 2025 18:00:47 GMT, Lance Andersen wrote: >> src/jdk.jartool/share/man/jar.md line 235: >> >>> 233: >>> 234: The jar tool will return a status code of 0 if there were no integrity issues encountered and a >>> 235: status code of 1 an issue was found. When an integrity issue is reported, it will often require >> >> I am wondering if we should not explicitly said status code of 1 to be more flexible. >> s/status code of 1/non-zero status code > >> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code > > Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc... We report all issues, not just one, so that would also involve what do we prioritized for the exit code... In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order. Also the process could fail with other issues like I/O or non-zip file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098596892 From lancea at openjdk.org Tue May 20 18:33:53 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 20 May 2025 18:33:53 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com> References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com> Message-ID: On Tue, 20 May 2025 18:14:15 GMT, Henry Jen wrote: >>> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code >> >> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc... > > We report all issues, not just one, so that would also involve what do we prioritized for the exit code... > In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order. > Also the process could fail with other issues like I/O or non-zip file. Yes I understand and currently we have no documentation as to what the return values might be. An inconsistency in the order should also be 1 based we only return a 0 if there are no issues. Any warning should be treated the same My point is that it is worth considering with these changes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098625246 From vlivanov at openjdk.org Tue May 20 18:45:56 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 20 May 2025 18:45:56 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v6] In-Reply-To: <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com> References: <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com> Message-ID: On Fri, 9 May 2025 15:59:38 GMT, Kim Barrett wrote: >> Please review this change which adds a native method providing the >> implementation of Reference::get. Referece::get is an intrinsic candidate, so >> this native method implementation is only used when the intrinsic is not. >> >> Currently there is intrinsic support by the interpreter, C1, C2, and graal, >> which are always used. With this change we can later remove all the >> per-platform interpreter intrinsic implementations, and might also remove the >> C1 intrinsic implementation. >> >> Testing: >> (1) mach5 tier1-6 normal (so using all the existing intrinsics). >> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. > > Kim Barrett 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 native-reference-get > - use new waitForRefProc, some tidying > - Merge branch 'master' into native-reference-get > - remove timeout by using waitForReferenceProcessing > - make ill-timed gc in non-concurrent case less likely > - fix test package use > - add package decl to test > - parameterized return type of native get0 > - test native method > - native Reference.get helper Overall, looks good. src/java.base/share/classes/java/lang/ref/Reference.java line 366: > 364: > 365: /* Implementation of unintrinsified get(). Making get() native may lead > 366: * C2 to sometimes prefer the native implementation over the intrinsic. Can you share more details on this? ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24315#pullrequestreview-2855249526 PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2098645006 From paul.sandoz at oracle.com Tue May 20 18:49:02 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 May 2025 18:49:02 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> Message-ID: JEP 198 will likely be withdrawn and a new JEP will be drafted aligned with the document sent in this email thread. It?s a not a goal to solve the dependency problem (a very hard problem!) even in a narrow sense. A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0, and potentially so with further out features. This has a number of advantages: 1. It should enable us to devise a simpler API that naturally gains more power as it is used in combination with those features; 2. It provides feedback to those features and perhaps the other way around too; and 3. It provides a template for others to copy in their own libraries. Paul. > On May 20, 2025, at 12:53?AM, Swaranga Sarma wrote: > > Hello, I am not a language or a library developer by any means but I wanted to offer my perspective as a prospective user of such an API. > > I am sure this was considered but feel compelled to raise it regardless - instead of the low level tree API (and baking whatever design choice is made forever into the JDK), was a higher level data binding API considered while keeping any low-level tree implementation private to the JDK? Basically a way to take a Json document (String/Reader/...) and deserialize it into an instance of a user-defined Record (and vice versa). From my perspective, this would be a more useful addition for the simpler and most common cases and if there are more complex requirements around flexibility/performance then there are lots of 3rd party options available in Java. I do not have data to back my hunch that this will be more valuable but I am offering my real production use-case where I would find it useful: > > I have a bunch of rest APIs for which my callers want me to vend a Java client that has the Java POJO classes for the request and response shapes; they don't want to write it by hand which is a reasonable ask. I usually create a Java library that uses the standard Java Http client under the hood to make the calls and serialize and deserialize the DTOs using Jackson. The problem is that as soon as I add Jackson to the client library's dependencies, it is no longer a zero-runtime dependency library and the callers have to deal with multiple versions, version incompatibility etc (in case they also use Jackson in the client app). With a Json api with support for data binding in the standard library, I could vend a very thin zero additional dependencies Java client to my callers. > > This is not quite what JEP 198 is stating as its goals but I am also not sure if this discussion is towards an implementation for that JEP. > > Thank you > Swaranga From rriggs at openjdk.org Tue May 20 18:58:51 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 20 May 2025 18:58:51 GMT Subject: RFR: 8347027: String replaceAll with Function In-Reply-To: References: Message-ID: On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell wrote: > New API to the String.java class - replaceAllMapped(String, Function) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function). Please elaborate on the rationale and use cases. I don't this a compelling API or functionality. Tnx. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25335#issuecomment-2895494882 From rriggs at openjdk.org Tue May 20 19:01:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 20 May 2025 19:01:54 GMT Subject: RFR: 8347027: String replaceAll with Function In-Reply-To: References: Message-ID: On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell wrote: > New API to the String.java class - replaceAllMapped(String, Function) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function). Since its implemented as 1-one function, it doesn't add much value and requires recompiling the regex on each use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25335#issuecomment-2895499907 From vyazici at openjdk.org Tue May 20 19:20:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 May 2025 19:20:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods In-Reply-To: References: Message-ID: On Tue, 20 May 2025 10:40:39 GMT, Volkan Yazici wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160: > >> 158: >> 159: try { >> 160: Terminal terminal = TerminalBuilder.builder().encoding(outCharset) > > Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants? Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098698322 From sarma.swaranga at gmail.com Tue May 20 19:21:47 2025 From: sarma.swaranga at gmail.com (Swaranga Sarma) Date: Tue, 20 May 2025 12:21:47 -0700 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> Message-ID: > It?s a not a goal to solve the dependency problem (a very hard problem!) even in a narrow sense. That was only an example where a data-binding API would be useful - it wasn't a meant to be the only use-case or even a suggestion that it should be solved in the general case. > A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: ``` var jsonStr = "..." var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants var serialized = Json.serialize(myRecord) ``` This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. Regards Swaranga On Tue, May 20, 2025 at 11:49?AM Paul Sandoz wrote: > JEP 198 will likely be withdrawn and a new JEP will be drafted aligned > with the document sent in this email thread. > > It?s a not a goal to solve the dependency problem (a very hard problem!) > even in a narrow sense. > > A potential advantage that we (the OpenJDK community) can more easily do > is devise an API that resonates with direction the Java platform is > heading, specifically around the pattern matching and serialization 2.0, > and potentially so with further out features. This has a number of > advantages: > > 1. It should enable us to devise a simpler API that naturally gains more > power as it is used in combination with those features; > 2. It provides feedback to those features and perhaps the other way around > too; and > 3. It provides a template for others to copy in their own libraries. > > Paul. > > > On May 20, 2025, at 12:53?AM, Swaranga Sarma > wrote: > > > > Hello, I am not a language or a library developer by any means but I > wanted to offer my perspective as a prospective user of such an API. > > > > I am sure this was considered but feel compelled to raise it regardless > - instead of the low level tree API (and baking whatever design choice is > made forever into the JDK), was a higher level data binding API considered > while keeping any low-level tree implementation private to the JDK? > Basically a way to take a Json document (String/Reader/...) and deserialize > it into an instance of a user-defined Record (and vice versa). From my > perspective, this would be a more useful addition for the simpler and most > common cases and if there are more complex requirements around > flexibility/performance then there are lots of 3rd party options available > in Java. I do not have data to back my hunch that this will be more > valuable but I am offering my real production use-case where I would find > it useful: > > > > I have a bunch of rest APIs for which my callers want me to vend a Java > client that has the Java POJO classes for the request and response shapes; > they don't want to write it by hand which is a reasonable ask. I usually > create a Java library that uses the standard Java Http client under the > hood to make the calls and serialize and deserialize the DTOs using > Jackson. The problem is that as soon as I add Jackson to the client > library's dependencies, it is no longer a zero-runtime dependency library > and the callers have to deal with multiple versions, version > incompatibility etc (in case they also use Jackson in the client app). With > a Json api with support for data binding in the standard library, I could > vend a very thin zero additional dependencies Java client to my callers. > > > > This is not quite what JEP 198 is stating as its goals but I am also not > sure if this discussion is towards an implementation for that JEP. > > > > Thank you > > Swaranga > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyazici at openjdk.org Tue May 20 19:26:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 May 2025 19:26:52 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods In-Reply-To: References: Message-ID: On Tue, 20 May 2025 19:18:43 GMT, Volkan Yazici wrote: >> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160: >> >>> 158: >>> 159: try { >>> 160: Terminal terminal = TerminalBuilder.builder().encoding(outCharset) >> >> Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants? > > Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings. All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention: src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098707061 From rriggs at openjdk.org Tue May 20 19:35:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 20 May 2025 19:35:55 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 13:56:42 GMT, kieran-farrell wrote: >>> Can the sub-microsecond value just be truncated and avoid the expensive divide operation?' >> >> method 3 of secion 6.2 of https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters states >> >>> start with the portion of the timestamp expressed as a fraction of the clock's tick value (fraction of a millisecond for UUIDv7). Compute the count of possible values that can be represented in the available bit space, 4096 for the UUIDv7 rand_a field. Using floating point or scaled integer arithmetic, multiply this fraction of a millisecond value by 4096 and round down (toward zero) to an integer result to arrive at a number between 0 and the maximum allowed for the indicated bits, which sorts monotonically based on time. ' >> >> so i think we might have to keep the division? though i re-shuffled the equation to >> >> `int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);` >> >> which gives scaled integer division rather than floating point and gave a very slight imporved perfomance to 143.758 ? 2.135 ns/op > >> This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next(). > > do you mean to create the UUID using most and least significant bytes? if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method, but the below implemntation keeping with the nextByte(byte[]) api brings a performance increase to 121.128 ? 30.486 ns/op, though the code might appear a little roundabout. > > > public static UUID timestampUUID() { > long msTime = System.currentTimeMillis(); > long nsTime = System.nanoTime(); > > // Scale sub-ms nanoseconds to a 12-bit value > int nsBits = (int) ((nsTime % 1_000_000L) * 4096L / 1_000_000L); > > // Compose the 64 most significant bits: [48-bit msTime | 4-bit version | 12-bit nsBits] > long mostSigBits = > ((msTime & 0xFFFFFFFFFFFFL) << 16) | > (0x7L << 12) | > nsBits; > > // Generate 8 random bytes for least significant bits > byte[] randomBytes = new byte[8]; > SecureRandom ng = UUID.Holder.numberGenerator; > ng.nextBytes(randomBytes); > > long leastSigBits = 0; > for (int i = 0; i < 8; i++) { > leastSigBits = (leastSigBits << 8) | (randomBytes[i] & 0xFF); > } > > // Set variant (bits 62?63) to '10' > leastSigBits &= 0x3FFFFFFFFFFFFFFFL; > leastSigBits |= 0x8000000000000000L; > > return new UUID(mostSigBits, leastSigBits); > } There's no (time-based) relationship between the currentTimeMillis() value and the nanoTime value. They are independent clocks and are read separately and are un-correlated. They won't be usable as lsb of the millis value. I'm surprised that the `nextBytes` is slower, since it looks like it calls `nextLong` and puts it in a newly allocated byte[8]. Normal perf measurements won't account for the gc overhead to recover it. The nsBits computation looks odd, nanoTme returns nanoseconds (10^9), the remainder (% 1_000_000) is then milliseconds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098719719 From duke at openjdk.org Tue May 20 19:41:59 2025 From: duke at openjdk.org (Philippe Marschall) Date: Tue, 20 May 2025 19:41:59 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 17:12:08 GMT, kieran-farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/util/UUID.java > > Co-authored-by: Andrey Turbanov src/java.base/share/classes/java/util/UUID.java line 200: > 198: public static UUID timestampUUID() { > 199: long msTime = System.currentTimeMillis(); > 200: long nsTime = System.nanoTime(); I is my understanding that `System#nanoTime()` does not provide the nanosecond fraction and is not guaranteed to have nanosecond resolution. You'd have to look at `VM#getNanoTimeAdjustment(long)` to get the nanotime adjustment. However the resolution of this is OS dependent, usually microseconds, likely 10 microseconds on Windows. src/java.base/share/classes/java/util/UUID.java line 203: > 201: SecureRandom ng = Holder.numberGenerator; > 202: byte[] randomBytes = new byte[16]; > 203: ng.nextBytes(randomBytes); It's a bit unfortunate that `SecureRandom#nextBytes(byte[])` does not allow us to pass an offset and length. Here we generate 16 bytes of random data but throw the first 8 bytes away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098704776 PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098708696 From duke at openjdk.org Tue May 20 19:41:59 2025 From: duke at openjdk.org (Philippe Marschall) Date: Tue, 20 May 2025 19:41:59 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 19:32:54 GMT, Roger Riggs wrote: >>> This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next(). >> >> do you mean to create the UUID using most and least significant bytes? if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method, but the below implemntation keeping with the nextByte(byte[]) api brings a performance increase to 121.128 ? 30.486 ns/op, though the code might appear a little roundabout. >> >> >> public static UUID timestampUUID() { >> long msTime = System.currentTimeMillis(); >> long nsTime = System.nanoTime(); >> >> // Scale sub-ms nanoseconds to a 12-bit value >> int nsBits = (int) ((nsTime % 1_000_000L) * 4096L / 1_000_000L); >> >> // Compose the 64 most significant bits: [48-bit msTime | 4-bit version | 12-bit nsBits] >> long mostSigBits = >> ((msTime & 0xFFFFFFFFFFFFL) << 16) | >> (0x7L << 12) | >> nsBits; >> >> // Generate 8 random bytes for least significant bits >> byte[] randomBytes = new byte[8]; >> SecureRandom ng = UUID.Holder.numberGenerator; >> ng.nextBytes(randomBytes); >> >> long leastSigBits = 0; >> for (int i = 0; i < 8; i++) { >> leastSigBits = (leastSigBits << 8) | (randomBytes[i] & 0xFF); >> } >> >> // Set variant (bits 62?63) to '10' >> leastSigBits &= 0x3FFFFFFFFFFFFFFFL; >> leastSigBits |= 0x8000000000000000L; >> >> return new UUID(mostSigBits, leastSigBits); >> } > > There's no (time-based) relationship between the currentTimeMillis() value and the nanoTime value. > They are independent clocks and are read separately and are un-correlated. They won't be usable as lsb of the millis value. > > I'm surprised that the `nextBytes` is slower, since it looks like it calls `nextLong` and puts it in a newly allocated byte[8]. Normal perf measurements won't account for the gc overhead to recover it. > > The nsBits computation looks odd, nanoTme returns nanoseconds (10^9), the remainder (% 1_000_000) is then milliseconds. > if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method Probably because `SecureRandom` gets `#nextLong()` from `Random`, which ends up calling `#next(int)` twice, so it allocates twice. Overriding `#nextLong()` in `SecureRandom` may help a little but will still have to allocate as long as `SecureRandomSpi` is not updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098727054 From paul.sandoz at oracle.com Tue May 20 19:46:12 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 May 2025 19:46:12 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic. Paul. > On May 20, 2025, at 12:21?PM, Swaranga Sarma wrote: > > > A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 > > Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: > > ``` > var jsonStr = "..." > var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants > var serialized = Json.serialize(myRecord) > ``` > > This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. > > > Regards > Swaranga From erikj at openjdk.org Tue May 20 19:50:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 20 May 2025 19:50:53 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v11] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 03:43:39 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> [...] >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed merge make/RunTests.gmk line 753: > 751: $$(call MakeDir, $$($1_AOT_JDK_OUTPUT_DIR)) > 752: > 753: ifeq ($$($1_TRAINING), onestep) Sorry for not noticing this earlier. This is a conditional within a recipe. The preferred style for those are to align the `ifeq`, `else` and `endif` with the recipe itself, using spaces (as it's not a recipe line), and then indent the body with 2 extra spaces for logical indentation. See points 5 and 6 in https://openjdk.org/groups/build/doc/code-conventions.html. You can find an example of this in `make/Bundles.gmk`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2098741011 From rriggs at openjdk.org Tue May 20 19:53:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 20 May 2025 19:53:52 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6] In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com> References: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com> Message-ID: On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen wrote: >> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > hex8 comments src/java.base/share/classes/java/util/UUID.java line 528: > 526: *

      > 527:      * Input:  0x0123456789ABCDEF
      > 528:      * Output: 0x3031323334353637 ('0','1','2','3','4','5','6','7' in ASCII)
      
      Only the low 32 bits are used, the example only needs to show the input ox 0x0123457.
      Or change the signature to accept an `int`.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2098745362
      
      From duke at openjdk.org  Tue May 20 20:41:12 2025
      From: duke at openjdk.org (fabioromano1)
      Date: Tue, 20 May 2025 20:41:12 GMT
      Subject: RFR: 8356891: Some code simplifications in BigInteger [v19]
      In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
      References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
      Message-ID: <0OgjI18h6PpSgw2z1vkfcpv3yTQxzUegZBqU64ScRaQ=.205ab0a2-7b0f-47bc-872d-25ccc3f5a5ae@github.com>
      
      > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
      
      fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
      
        Simplify two's complement in makePositive(int[])
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/25166/files
        - new: https://git.openjdk.org/jdk/pull/25166/files/46114836..6267a258
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=18
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=17-18
      
        Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod
        Patch: https://git.openjdk.org/jdk/pull/25166.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166
      
      PR: https://git.openjdk.org/jdk/pull/25166
      
      From swen at openjdk.org  Tue May 20 21:55:52 2025
      From: swen at openjdk.org (Shaojin Wen)
      Date: Tue, 20 May 2025 21:55:52 GMT
      Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
      In-Reply-To: 
      References: 
       <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
       
      Message-ID: 
      
      On Tue, 20 May 2025 19:51:14 GMT, Roger Riggs  wrote:
      
      >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
      >> 
      >>   hex8 comments
      >
      > src/java.base/share/classes/java/util/UUID.java line 528:
      > 
      >> 526:      * 
      >> 527:      * Input:  0x0123456789ABCDEF
      >> 528:      * Output: 0x3031323334353637 ('0','1','2','3','4','5','6','7' in ASCII)
      > 
      > Only the low 32 bits are used, the example only needs to show the input ox 0x0123457.
      > Or change the signature to accept an `int`.
      
      Because the input of Long.expand is long, if the parameter is int, it will cause a redundant conversion process of long -> int -> long.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2098934998
      
      From naoto at openjdk.org  Tue May 20 21:57:45 2025
      From: naoto at openjdk.org (Naoto Sato)
      Date: Tue, 20 May 2025 21:57:45 GMT
      Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
       [v2]
      In-Reply-To: 
      References: 
      Message-ID: 
      
      > `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
      
      Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
      
        Reflects review comments
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/25271/files
        - new: https://git.openjdk.org/jdk/pull/25271/files/f2eb1ad8..ec420654
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=01
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=00-01
      
        Stats: 218 lines in 7 files changed: 108 ins; 93 del; 17 mod
        Patch: https://git.openjdk.org/jdk/pull/25271.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271
      
      PR: https://git.openjdk.org/jdk/pull/25271
      
      From henryjen at openjdk.org  Tue May 20 22:02:54 2025
      From: henryjen at openjdk.org (Henry Jen)
      Date: Tue, 20 May 2025 22:02:54 GMT
      Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
       invalid entries [v9]
      In-Reply-To: 
      References: 
       <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
       
       
       <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
       
      Message-ID: 
      
      On Tue, 20 May 2025 18:30:46 GMT, Lance Andersen  wrote:
      
      >> We report all issues, not just one, so that would also involve what do we prioritized for the exit code...
      >> In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order.
      >> Also the process could fail with other issues like I/O or non-zip file.
      >
      > Yes I understand and currently we have no documentation as to what the return values might be.  An inconsistency in the order should also be 1 based we only return a 0 if there are no issues.  Any warning should be treated the same
      > 
      > My point is that it is worth considering with these changes
      
      Point taken. For documentation wise, I don't think it's necessary to specify at this point.
      For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098943146
      
      From naoto at openjdk.org  Tue May 20 22:06:50 2025
      From: naoto at openjdk.org (Naoto Sato)
      Date: Tue, 20 May 2025 22:06:50 GMT
      Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
       [v2]
      In-Reply-To: 
      References: 
       
       
       
      Message-ID: 
      
      On Tue, 20 May 2025 19:24:16 GMT, Volkan Yazici  wrote:
      
      >> Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings.
      >
      > All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention:
      > 
      > src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
      > src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
      > src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java
      
      JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947104
      
      From naoto at openjdk.org  Tue May 20 22:06:52 2025
      From: naoto at openjdk.org (Naoto Sato)
      Date: Tue, 20 May 2025 22:06:52 GMT
      Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
       [v2]
      In-Reply-To: 
      References: 
       
      Message-ID: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
      
      On Tue, 20 May 2025 11:29:42 GMT, Volkan Yazici  wrote:
      
      >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
      >> 
      >>   Reflects review comments
      >
      > test/jdk/java/io/Console/StdinEncodingTest.java line 46:
      > 
      >> 44:  * @run junit StdinEncodingTest
      >> 45:  */
      >> 46: public class StdinEncodingTest {
      > 
      > AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)
      
      `stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`
      
      > test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 83:
      > 
      >> 81:             while (in.remaining() > 0) {
      >> 82:                 char c = (char)in.get();
      >> 83:                 if (c != '\n') {
      > 
      > `Character.toUpperCase('\n') == '\n'`, not? If so, do we still need this `if`-branching?
      
      Eliminating newlines was a hack to ignore them in the expect responses so that it can check the combined output in one shot. Now I think it is better to check the result separately, so modified as such.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947409
      PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947338
      
      From kbarrett at openjdk.org  Tue May 20 22:16:55 2025
      From: kbarrett at openjdk.org (Kim Barrett)
      Date: Tue, 20 May 2025 22:16:55 GMT
      Subject: RFR: 8352565: Add native method implementation of Reference.get()
       [v6]
      In-Reply-To: 
      References: 
       <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
       
      Message-ID: 
      
      On Tue, 20 May 2025 18:43:16 GMT, Vladimir Ivanov  wrote:
      
      >> Kim Barrett 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 native-reference-get
      >>  - use new waitForRefProc, some tidying
      >>  - Merge branch 'master' into native-reference-get
      >>  - remove timeout by using waitForReferenceProcessing
      >>  - make ill-timed gc in non-concurrent case less likely
      >>  - fix test package use
      >>  - add package decl to test
      >>  - parameterized return type of native get0
      >>  - test native method
      >>  - native Reference.get helper
      >
      > src/java.base/share/classes/java/lang/ref/Reference.java line 366:
      > 
      >> 364: 
      >> 365:     /* Implementation of unintrinsified get().  Making get() native may lead
      >> 366:      * C2 to sometimes prefer the native implementation over the intrinsic.
      > 
      > Can you share more details on this?
      
      See review thread slightly above here, specifically https://github.com/openjdk/jdk/pull/24315/files#r2094884157.
      I've looked at the intrinsics for Object.clone() and Object.hashCode(), but only enough to decide I
      understand the approach being taken here better than what's in those.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2098956661
      
      From naoto at openjdk.org  Tue May 20 23:05:52 2025
      From: naoto at openjdk.org (Naoto Sato)
      Date: Tue, 20 May 2025 23:05:52 GMT
      Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
       conversions made on language tag [v2]
      In-Reply-To: 
      References: 
       
      Message-ID: <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>
      
      On Tue, 20 May 2025 17:19:32 GMT, Justin Lu  wrote:
      
      >> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
      >
      > Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   setLanguageTag should mention all conversions, not just extlang
      
      src/java.base/share/classes/java/util/Locale.java line 1837:
      
      > 1835:      *     Locale.forLanguageTag("en-abc-def-us").toString(); // returns "abc_US"
      > 1836:      *     Locale.forLanguageTag("zh-yue-gan-cmn-czh-CN").toString();
      > 1837:      *     // returns "yue"; the rest of the tag is considered ill-formed
      
      I'd rather not use "ill-formed" here, or change the wording, as "the rest of the tag" implies subtags other than "yue" which include "zh." If this "zh" is considered ill-formed, following "yue" should be discarded according to the prior definition.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2098999406
      
      From swen at openjdk.org  Tue May 20 23:10:56 2025
      From: swen at openjdk.org (Shaojin Wen)
      Date: Tue, 20 May 2025 23:10:56 GMT
      Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
       empty file data [v3]
      In-Reply-To: 
      References: 
       
      Message-ID: 
      
      On Mon, 12 May 2025 11:27:35 GMT, Jaikiran Pai  wrote:
      
      >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
      >> 
      >> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
      >> 
      >> tier testing is currently in progress.
      >
      > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   Lance's suggestion - simplify argument creation, given just a handful number of argument values
      
      src/java.base/share/classes/java/util/zip/ZipInputStream.java line 430:
      
      > 428:                     throw new ZipException("invalid entry CRC (expected 0x"
      > 429:                             + Long.toHexString(currentEntry.crc)
      > 430:                             + " but got 0x" + Long.toHexString(crc.getValue()) + ")");
      
      Suggestion:
      
                          throw new ZipException("invalid entry CRC (expected 0x%x but got 0x%x)".formatted(currentEntry.crc, crc.getValue()));
      
      Can String::formatted be used here?
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25116#discussion_r2099003883
      
      From jlu at openjdk.org  Tue May 20 23:24:33 2025
      From: jlu at openjdk.org (Justin Lu)
      Date: Tue, 20 May 2025 23:24:33 GMT
      Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
       conversions made on language tag [v3]
      In-Reply-To: 
      References: 
      Message-ID: 
      
      > It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
      
      Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
      
        adjust example wording
      
      -------------
      
      Changes:
        - all: https://git.openjdk.org/jdk/pull/25309/files
        - new: https://git.openjdk.org/jdk/pull/25309/files/2d70bf79..62714a26
      
      Webrevs:
       - full: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=02
       - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=01-02
      
        Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
        Patch: https://git.openjdk.org/jdk/pull/25309.diff
        Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309
      
      PR: https://git.openjdk.org/jdk/pull/25309
      
      From jlu at openjdk.org  Tue May 20 23:24:33 2025
      From: jlu at openjdk.org (Justin Lu)
      Date: Tue, 20 May 2025 23:24:33 GMT
      Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
       conversions made on language tag [v2]
      In-Reply-To: <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>
      References: 
       
       <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>
      Message-ID: 
      
      On Tue, 20 May 2025 23:02:45 GMT, Naoto Sato  wrote:
      
      >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
      >> 
      >>   setLanguageTag should mention all conversions, not just extlang
      >
      > src/java.base/share/classes/java/util/Locale.java line 1837:
      > 
      >> 1835:      *     Locale.forLanguageTag("en-abc-def-us").toString(); // returns "abc_US"
      >> 1836:      *     Locale.forLanguageTag("zh-yue-gan-cmn-czh-CN").toString();
      >> 1837:      *     // returns "yue"; the rest of the tag is considered ill-formed
      > 
      > I'd rather not use "ill-formed" here, or change the wording, as "the rest of the tag" implies subtags other than "yue" which include "zh." If this "zh" is considered ill-formed, following "yue" should be discarded according to the prior definition.
      
      OK, I'd like to keep "ill-formed" because it allows the example to have meaning for both `[for/set]LanguageTag`.
      I updated the wording so that it is clear that "czh", (the fourth extlang) and subsequent subtags are what is considered ill-formed.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2099018994
      
      From duke at openjdk.org  Wed May 21 00:23:52 2025
      From: duke at openjdk.org (Johannes Graham)
      Date: Wed, 21 May 2025 00:23:52 GMT
      Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
      In-Reply-To: 
      References: 
       <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
       
       
      Message-ID: 
      
      On Tue, 20 May 2025 21:53:21 GMT, Shaojin Wen  wrote:
      
      >> src/java.base/share/classes/java/util/UUID.java line 528:
      >> 
      >>> 526:      * 
      >>> 527:      * Input:  0x0123456789ABCDEF
      >>> 528:      * Output: 0x3031323334353637 ('0','1','2','3','4','5','6','7' in ASCII)
      >> 
      >> Only the low 32 bits are used, the example only needs to show the input ox 0x0123457.
      >> Or change the signature to accept an `int`.
      >
      > Because the input of Long.expand is long, if the parameter is int, it will cause a redundant conversion process of long -> int -> long.
      
      I think the issue is just the example input and output should be something like:
      
      Input: 0xABCDEF01
      Output: 0x3130666564636261
      
      to demonstrate that it is the low-order bits that are used, as well as that the digit order is reversed in the result.
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099071960
      
      From duke at openjdk.org  Wed May 21 00:29:55 2025
      From: duke at openjdk.org (Johannes Graham)
      Date: Wed, 21 May 2025 00:29:55 GMT
      Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
      In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
      References: 
       <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
      Message-ID: 
      
      On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen  wrote:
      
      >> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.
      >
      > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   hex8 comments
      
      src/java.base/share/classes/java/util/UUID.java line 534:
      
      > 532:      */
      > 533:     private static long hex8(long i) {
      > 534:         // Expand each 4-bit group into 8 bits, spreading them out in the long value: 0xAABBCCDD -> 0x0A0B0C0D0A0B0C0D
      
      should be `0xAABBCCDD -> 0xA0A0B0B0C0C0D0D`
      
      -------------
      
      PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099076402
      
      From duke at openjdk.org  Wed May 21 00:33:53 2025
      From: duke at openjdk.org (Johannes Graham)
      Date: Wed, 21 May 2025 00:33:53 GMT
      Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
      In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
      References: 
       <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
      Message-ID: 
      
      On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen  wrote:
      
      >> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.
      >
      > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
      > 
      >   hex8 comments
      
      src/java.base/share/classes/java/util/UUID.java line 492:
      
      > 490:      * achieving significantly better performance compared to traditional loop-based conversion.
      > 491:      *
      > 492:      * 

      The conversion algorithm works as follows: I think the in-line comment describing the algorithm is enough - doesn't need the details in the javadoc as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099078808 From duke at openjdk.org Wed May 21 00:37:52 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 21 May 2025 00:37:52 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6] In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com> References: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com> Message-ID: On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen wrote: >> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > hex8 comments src/java.base/share/classes/java/util/UUID.java line 469: > 467: buf[18] = '-'; > 468: buf[23] = '-'; > 469: I would suggest a comment here along the lines of "Although the UUID byte ordering is defined to be big-endian, LittleEndian is used here to optimize for the most common architectures. `hex8` reverses the order internally." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099081840 From swen at openjdk.org Wed May 21 00:50:10 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 21 May 2025 00:50:10 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v7] In-Reply-To: References: Message-ID: > Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - add comments, from @j3graham - fix comments, from @j3graham ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22928/files - new: https://git.openjdk.org/jdk/pull/22928/files/3b94f81f..61e3faee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=05-06 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928 PR: https://git.openjdk.org/jdk/pull/22928 From swen at openjdk.org Wed May 21 00:57:30 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 21 May 2025 00:57:30 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v8] In-Reply-To: References: Message-ID: > Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix comments, from @j3graham ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22928/files - new: https://git.openjdk.org/jdk/pull/22928/files/61e3faee..8d0e8fd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928 PR: https://git.openjdk.org/jdk/pull/22928 From almatvee at openjdk.org Wed May 21 01:27:01 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 01:27:01 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 16:35:57 GMT, Alexey Semenyuk wrote: >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 45: > >> 43: resource.app-info-plist=Application Info.plist >> 44: resource.runtime-info-plist=Java Runtime Info.plist >> 45: resource.runtime-image-info-plist=Java Runtime Bundle Info.plist > > `resource.runtime-bundle-info-plist` would be a better name as the list file belongs to a bundle, not the image. Fixed. > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88: > >> 86: message.codesign.failed.reason.xcode.tools=Possible reason for "codesign" failure is missing Xcode with command line developer tools. Install Xcode with command line developer tools to see if it resolves the problem. >> 87: message.runtime-image-invalid=Provided runtime image at "{0}" is invalid or corrupted. >> 88: message.runtime-image-invalid.advice=Runtime image should be valid JDK bundle or JDK image. > > We need negative test cases for these new error conditions. Test cases are added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099120626 PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099120720 From asemenyuk at openjdk.org Wed May 21 01:41:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 01:41:55 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Wed, 21 May 2025 01:24:16 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88: >> >>> 86: message.codesign.failed.reason.xcode.tools=Possible reason for "codesign" failure is missing Xcode with command line developer tools. Install Xcode with command line developer tools to see if it resolves the problem. >>> 87: message.runtime-image-invalid=Provided runtime image at "{0}" is invalid or corrupted. >>> 88: message.runtime-image-invalid.advice=Runtime image should be valid JDK bundle or JDK image. >> >> We need negative test cases for these new error conditions. > > Test cases are added. Can you give a reference to a test that expects jpackage to fail with `message.runtime-image-invalid` error in the output? I can't find it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099135430 From almatvee at openjdk.org Wed May 21 01:41:56 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 01:41:56 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 16:39:02 GMT, Alexey Semenyuk wrote: >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 246: > >> 244: >> 245: public static String getPropertyFromFile(Path filename, String name) { >> 246: // load properties file > > That is a bad idea to expose jpackage API that uses jpackage's Log class. Where will these log messages go? Fixed. > src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 251: > >> 249: properties.load(reader); >> 250: } catch (IOException e) { >> 251: Log.error("Exception: " + e.getMessage()); > > This is an exception swallow, not good. Logging it in place doesn't make it right. If this is an unrecoverable error, it should be forwarded to the caller. Fixed. Yes, we should consider it as an unrecoverable error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099133805 PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099134380 From almatvee at openjdk.org Wed May 21 01:47:53 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 01:47:53 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 16:57:34 GMT, Alexey Semenyuk wrote: >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 199: > >> 197: } >> 198: return version; >> 199: }, > > I guess, this is a workaround for the case when the version comes from JDK's release file. This is the wrong place for this workaround. It should be a part of the code reading version from JDK's release file. Yes, this is workaround when the version comes from JDK's release file. In this case name will be customeJDK-25.0.0.0 for example if we change it when we read version form file. Other platform do not need it. Only PRODUCT_VERSION in MSI needs to be 2 or 4 components, so I think it is correct location for it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099140330 From almatvee at openjdk.org Wed May 21 01:53:50 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 01:53:50 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: <0XxbdYMVs8a-EgJzzgRw2afvoTGeKRxDhybE8YrqcVw=.d3f88818-848d-4d33-9442-ea9e9f9f01af@github.com> On Tue, 20 May 2025 17:00:21 GMT, Alexey Semenyuk wrote: >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 1004: > >> 1002: // External runtime image should be R/O unless it is on macOS. >> 1003: // On macOS it will be signed ad-hoc or with real certificate. >> 1004: return !TKit.isOSX(); > > Do I get the comment right, and jpackage will modify the image supplied with `--runtime-image` parameter? This is wrong. jpackage must not modify any externally supplied files/directories unless this is app image signing on macos. Yes, you get the comment right. We do sign runtime image as well (same as app image). We do ad-hoc signing for runtime image if signing is not requested. Ad-hoc signing will modify runtime image. I think you mean case when "--app-image" and "--runtime-image" is specified, then yes we should not modify it, but when we packaging just runtime it will be modify due to signature. I will update test to reflect it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099145308 From almatvee at openjdk.org Wed May 21 01:59:58 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 01:59:58 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <1xpPgU-jZVXZaBrp0A7CSqzSSNt8GqgoAvnp3tcLt_g=.8e7cd068-407f-442e-a596-0a9f6f3d4d9f@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> <1xpPgU-jZVXZaBrp0A7CSqzSSNt8GqgoAvnp3tcLt_g=.8e7cd068-407f-442e-a596-0a9f6f3d4d9f@github.com> Message-ID: On Tue, 20 May 2025 17:05:55 GMT, Alexey Semenyuk wrote: >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified. >> - The bundle's top directory name will have the ".jdk" suffix. > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 337: > >> 335: } >> 336: >> 337: return installLocation.resolve(cmd.name() + (cmd.isRuntime() ? ".jdk" : ".app")); > > Why the ".jdk" suffix and not ".app"? Because JDK bundles has ".jdk" suffix. Why it should be ".app"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099150610 From almatvee at openjdk.org Wed May 21 02:04:49 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 02:04:49 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. > > Additional changes: > - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified. > - The bundle's top directory name will have the ".jdk" suffix. I updated description. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2896251592 From almatvee at openjdk.org Wed May 21 02:19:31 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 02:19:31 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. > > Additional changes: > - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified. > - The bundle's top directory name will have the ".jdk" suffix. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25314/files - new: https://git.openjdk.org/jdk/pull/25314/files/74dd9917..182a9ddf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=00-01 Stats: 64 lines in 6 files changed: 51 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/25314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25314/head:pull/25314 PR: https://git.openjdk.org/jdk/pull/25314 From almatvee at openjdk.org Wed May 21 02:19:31 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 02:19:31 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. > > Additional changes: > - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified. > - The bundle's top directory name will have the ".jdk" suffix. 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] - Addresses the above comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2896270130 From almatvee at openjdk.org Wed May 21 02:19:31 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 02:19:31 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Wed, 21 May 2025 01:39:16 GMT, Alexey Semenyuk wrote: >> Test cases are added. > > Can you give a reference to a test that expects jpackage to fail with `message.runtime-image-invalid` error in the output? I can't find it. I just push it. See ErrorTest.java. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099164323 From asemenyuk at openjdk.org Wed May 21 02:35:59 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 02:35:59 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Wed, 21 May 2025 01:44:48 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 199: >> >>> 197: } >>> 198: return version; >>> 199: }, >> >> I guess, this is a workaround for the case when the version comes from JDK's release file. This is the wrong place for this workaround. It should be a part of the code reading version from JDK's release file. > > Yes, this is workaround when the version comes from JDK's release file. In this case name will be customeJDK-25.0.0.0 for example if we change it when we read version form file. Other platform do not need it. Only PRODUCT_VERSION in MSI needs to be 2 or 4 components, so I think it is correct location for it. For runtime packaging, the version can be taken from the command line or the "release" file. In the latter case the version should be valid for the current platform and packaging type. Version adjustments should be isolated in a function that reads a version from the "release" file. The result of this function call should be such that it will be used as-is without any modifications. Ideally, we should have `Optional readVersionFromRuntimeReleaseFile(String packageType, Path pathToReleaseFile)` function that we can unit test and that will return a valid version for the given packaging type ("packageType" parameter). It should return an empty Optional instance if it fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099180763 From kbarrett at openjdk.org Wed May 21 02:36:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 May 2025 02:36:16 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v3] In-Reply-To: References: Message-ID: > This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage > native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences > and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to > use java.lang.ref.Cleaner. > > This change is algorithmically similar to the two previous versions: > JDK-6857566 and JDK-8156500 (current mainline). The critical function is > Bits::reserveMemory(). For both of those versions and this change, a thread > calls that function and tries to reserve some space. If it fails, then it > keeps trying until all cleaners deactivated (cleared) by prior GCs have been > cleaned. If reservation still fails, then it invokes the GC to try to > deactivate more cleaners for cleaning. After that GC it keeps trying the > reservation and waiting for cleaning, with sleeps to avoid a spin loop, > eventually either succeeding or giving up and throwing OOME. > > Retaining that algorithmic approach is one of the goals of this change, since > it has been successfully in use since JDK 9 (and was originally developed and > extensively tested in JDK 8). > > The key to this approach is having a way to determine that deactivated > cleaners have been cleaned. JDK-6857566 accomplished this by having waiting > threads help the reference processor until there was no available work. > JDK-8156500 waits for the reference processor to quiesce, relying on its > immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way > to do this, which is why this change rolls its own Cleaner-like mechanism from > the underlying primitives. Like JDK-6857566, this change has waiting threads > help with cleaning references. This was a potentially undesirable feature of > JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. > (Though by the time of JDK-6857566 the cleaners were only used by DBB, and > became internal-only somewhere around that time as well.) That's not a concern > here, as the cleaners involved are only from DBB, and we know what they look > like. > > As noted in the discussion of JDK-6857566, it's good to have DBB cleaning > being done off the reference processing thread, as it may be expensive and > slow down enqueuing other pending references. JDK-6857566 only did some of > that, and JDK-8156500 lost that feature. This change moves all of the DBB > cleaning off of the reference processing thread. (So does PR 22165.) > > Neither JDK-6857566 nor this change are completely precise. For both, a thread > may find there is no available work whil... Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: - add description of BufferCleaner class - exception handling in cleaner for backward consistency - detabify ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25289/files - new: https://git.openjdk.org/jdk/pull/25289/files/45d0b1ef..be3312cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=01-02 Stats: 40 lines in 2 files changed: 28 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25289.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289 PR: https://git.openjdk.org/jdk/pull/25289 From kbarrett at openjdk.org Wed May 21 02:36:17 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 May 2025 02:36:17 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 19:16:14 GMT, Roger Riggs wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> move jdk.internal.nio.Cleaner to sun.nio > > src/java.base/share/classes/java/nio/BufferCleaner.java line 33: > >> 31: import java.util.Objects; >> 32: import sun.nio.Cleaner; >> 33: > > A class cleaner describing the overall objective (an excerpt from the PR description) would be useful. Assume you meant "class comment". I've added such. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2099181042 From almatvee at openjdk.org Wed May 21 02:47:09 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 02:47:09 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3] In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: <2RB3dSbaiqhRS-x45Syo3bO6-Fr7o9NT8icBUbumRls=.43ef27c3-4793-493a-93a4-cc7d65f19c99@github.com> > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. > > Additional changes: > - The bundle's top directory name will have the ".jdk" suffix. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25314/files - new: https://git.openjdk.org/jdk/pull/25314/files/182a9ddf..dfdec21f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=01-02 Stats: 147 lines in 6 files changed: 19 ins; 121 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25314.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25314/head:pull/25314 PR: https://git.openjdk.org/jdk/pull/25314 From asemenyuk at openjdk.org Wed May 21 02:47:10 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 02:47:10 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Wed, 21 May 2025 02:19:31 GMT, Alexander Matveev wrote: >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/share/ErrorTest.java line 93: > 91: return appImageCmd.outputBundle().toString(); > 92: }), > 93: INVALID_JDK_BUNDLE(cmd -> { Would `INVALID_MAC_JDK_BUNDLE` name be more accurate? test/jdk/tools/jpackage/share/ErrorTest.java line 102: > 100: } catch (IOException ex) { > 101: TKit.error(ex.getMessage()); > 102: return null; What is the point of this exception "handling"? What problem does it solve? What is the caller supposed to do with the `null`? ------------- PR Review: https://git.openjdk.org/jdk/pull/25314#pullrequestreview-2856070441 PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099185510 PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099184978 From almatvee at openjdk.org Wed May 21 02:47:10 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 02:47:10 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: On Wed, 21 May 2025 02:19:31 GMT, Alexander Matveev wrote: >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3] - Removed "jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified". It will be fixed as separate issue under: [JDK-8357404](https://bugs.openjdk.org/browse/JDK-8357404). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2896397761 From david.vidal.escudero at gmail.com Tue May 20 23:47:21 2025 From: david.vidal.escudero at gmail.com (David Vidal Escudero) Date: Tue, 20 May 2025 18:47:21 -0500 Subject: Towards a JSON API for the JDK In-Reply-To: <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> Message-ID: Hello, So, if such a Json library is added to the JDK, the Java Http module now should accept a JsonDocument implementing something like BodyPublishers.ofJsonDocument, or better yet BodyPublishers.ofJsonEncodable (assuming Eteh proposal). I think also JDBC API should be modified so prepared statements can implement .setJson and .getJson for DBMS supporting Json type (like Postgres). David. ---------- Forwarded message --------- De: Paul Sandoz Date: mar, 20 de may de 2025, 14:46 Subject: Re: Towards a JSON API for the JDK To: Swaranga Sarma Cc: Remi Forax , Brian Goetz , core-libs-dev Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic. Paul. > On May 20, 2025, at 12:21?PM, Swaranga Sarma wrote: > > > A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 > > Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: > > ``` > var jsonStr = "..." > var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants > var serialized = Json.serialize(myRecord) > ``` > > This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. > > > Regards > Swaranga -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.org Wed May 21 04:42:01 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 May 2025 04:42:01 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe wrote: >> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. >> >> We plan to deprecate this in JDK 25 and to remove it in JDK 26. >> >> This patch just writes a deprecation message to stderr: >> >> >> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls >> VFORK MODE DEPRECATED >> The VFORK launch mechanism has been deprecated for being dangerous. >> It will be removed in a future java version. Either remove the >> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode >> instead (-Djdk.lang.Process.launchMechanism=FORK). >> ... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > use string block Thanks all ------------- PR Comment: https://git.openjdk.org/jdk/pull/25282#issuecomment-2896543420 From stuefe at openjdk.org Wed May 21 04:42:01 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 May 2025 04:42:01 GMT Subject: Integrated: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) In-Reply-To: References: Message-ID: On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe wrote: > For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. > > We plan to deprecate this in JDK 25 and to remove it in JDK 26. > > This patch just writes a deprecation message to stderr: > > > 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls > VFORK MODE DEPRECATED > The VFORK launch mechanism has been deprecated for being dangerous. > It will be removed in a future java version. Either remove the > jdk.lang.Process.launchMechanism property (preferred) or use FORK mode > instead (-Djdk.lang.Process.launchMechanism=FORK). > ... This pull request has now been integrated. Changeset: 74fc4e4e Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/74fc4e4ee7f2e44d9c8339ff6665d4171d298f8f Stats: 16 lines in 1 file changed: 12 ins; 2 del; 2 mod 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/25282 From stuefe at openjdk.org Wed May 21 04:55:53 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 May 2025 04:55:53 GMT Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe wrote: > Hi, please consider the following patch. > > This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc. > > This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens). > > Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409 > > This patch also fixes two subtle bugs: > - we didn't check the return value of the close() inside closeAllFileDescriptors > - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it) > > ---- > > Testing: > > We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC. > > - in the parent JVM, the test opens a file in native code without FD_CLOEXEC > - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open > > I verified that the test correctly detects a broken implementation that leaks file descriptors. > > I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX). > > I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green. Ping @RogerRiggs ? And @simonis, perhaps? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25301#issuecomment-2896570218 From kbarrett at openjdk.org Wed May 21 05:44:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 21 May 2025 05:44:52 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 02:36:16 GMT, Kim Barrett wrote: >> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage >> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences >> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to >> use java.lang.ref.Cleaner. >> >> This change is algorithmically similar to the two previous versions: >> JDK-6857566 and JDK-8156500 (current mainline). The critical function is >> Bits::reserveMemory(). For both of those versions and this change, a thread >> calls that function and tries to reserve some space. If it fails, then it >> keeps trying until all cleaners deactivated (cleared) by prior GCs have been >> cleaned. If reservation still fails, then it invokes the GC to try to >> deactivate more cleaners for cleaning. After that GC it keeps trying the >> reservation and waiting for cleaning, with sleeps to avoid a spin loop, >> eventually either succeeding or giving up and throwing OOME. >> >> Retaining that algorithmic approach is one of the goals of this change, since >> it has been successfully in use since JDK 9 (and was originally developed and >> extensively tested in JDK 8). >> >> The key to this approach is having a way to determine that deactivated >> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting >> threads help the reference processor until there was no available work. >> JDK-8156500 waits for the reference processor to quiesce, relying on its >> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way >> to do this, which is why this change rolls its own Cleaner-like mechanism from >> the underlying primitives. Like JDK-6857566, this change has waiting threads >> help with cleaning references. This was a potentially undesirable feature of >> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. >> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and >> became internal-only somewhere around that time as well.) That's not a concern >> here, as the cleaners involved are only from DBB, and we know what they look >> like. >> >> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning >> being done off the reference processing thread, as it may be expensive and >> slow down enqueuing other pending references. JDK-6857566 only did some of >> that, and JDK-8156500 lost that feature. This change moves all of the DBB >> cleaning off of the reference processing thread. (So does PR 22165.) >> >> Neither JDK-6857566 nor this change are... > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - add description of BufferCleaner class > - exception handling in cleaner for backward consistency > - detabify src/java.base/share/classes/java/nio/BufferCleaner.java line 82: > 80: new Error("nio Cleaner terminated abnormally", x).printStackTrace(); > 81: } > 82: System.exit(1); This is the same behavior as jdk.internal.ref.Cleaner, for which this class is substituting in the new regime for DBB management. PR 22165 (and earlier versions of this PR) put this in the DBB's Deallocator::run method, but I think it's both clearer here, and better to leave the Deallocator as it was in mainline and be more consistent with the mainline code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2099400318 From jlu at openjdk.org Wed May 21 06:28:54 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 21 May 2025 06:28:54 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 21:57:45 GMT, Naoto Sato wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects review comments src/java.base/share/classes/java/io/Console.java line 67: > 65: * stdout.encoding}, in which case read operations use the {@code Charset} > 66: * designated by {@code stdin.encoding}. > 67: *

      `Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well. test/jdk/java/io/Console/StdinEncodingTest.java line 38: > 36: * @test > 37: * @bug 8356985 > 38: * @summary Tests if "stdin.encoding" is reflected for reading Would be helpful to include why the test is limited to only linux and mac, > "expect" command in Windows/Cygwin does not work as expected. Ignoring tests on Windows. test/jdk/java/io/Console/StdinEncodingTest.java line 51: > 49: // check "expect" command availability > 50: var expect = Paths.get("/usr/bin/expect"); > 51: if (!Files.exists(expect) || !Files.isExecutable(expect)) { Could use `Assumptions.assumeTrue` here. Condition becomes more readable as: `Files.exists(expect) && Files.isExecutable(expect)` test/jdk/java/io/Console/StdinEncodingTest.java line 56: > 54: > 55: // invoking "expect" command > 56: var testSrc = System.getProperty("test.src", "."); The test already imports the JDK test lib, can we just replace this and the below ocurrences with `jdk.test.lib.Utils.TEST_SRC/JDK/CLASSES` directly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099438513 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099441523 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099447047 PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099443105 From duke at openjdk.org Wed May 21 06:54:37 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Wed, 21 May 2025 06:54:37 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: References: Message-ID: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY 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/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/b3ccffd7..5e1f9240 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04-05 Stats: 51 lines in 3 files changed: 12 ins; 17 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From duke at openjdk.org Wed May 21 06:54:37 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Wed, 21 May 2025 06:54:37 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 16:21:56 GMT, Leonid Mesnik wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused import > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73: > >> 71: return; >> 72: } >> 73: if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) { > > Better to replace this with > `isContainerVersionSupported()` > ... > and implement all logic in the the ContainerRuntimeVersionTestUtils created checkContainerVersionSupported() > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38: > >> 36: private final int micro; >> 37: private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0); >> 38: public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0); > > Please add comment about meaning of the version or even better rename > DOCKER_MINIMAL_SUPPORTED_VERSION = .... updated name to DOCKER_MINIMAL_SUPPORTED_VERSION_CGROUPNS and PODMAN_MINIMAL_SUPPORTED_VERSION_CGROUPNS > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53: > >> 51: } else if (this.major < other.major) { >> 52: return -1; >> 53: } else { // equal major > > no need to add `else {` here updated > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58: > >> 56: } else if (this.minor < other.minor) { >> 57: return -1; >> 58: } else { // equal majors and minors > > no need to add `else {` here updated > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81: > >> 79: } catch (Exception e) { >> 80: System.out.println("Failed to parse container runtime version: " + version); >> 81: return DEFAULT; > > Any reason to don't fail here? updated > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94: > >> 92: } catch (Exception e) { >> 93: System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null"); >> 94: return null; > > Any reason to don't fail here? updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494838 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099496846 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494004 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494142 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497419 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497254 From jlahoda at openjdk.org Wed May 21 07:07:55 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 21 May 2025 07:07:55 GMT Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler [v3] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 09:56:31 GMT, Aggelos Biboudis wrote: >> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. >> >> For example this is not valid Java (and protected) by javac: >> >> >> byte b = 1; >> switch (b) { >> case String s -> System.out.println("How did we get here? byte is " + s.getClass()); >> } >> >> >> but this is a valid call (and not protected): >> >> >> CallSite shortSwitch = SwitchBootstraps.typeSwitch( >> MethodHandles.lookup(), >> "", >> MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int >> String.class); >> >> >> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. >> >> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Simplify unconditional exactness in both Types and SwitchBootstraps Looks reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25090#pullrequestreview-2856549641 From jlahoda at openjdk.org Wed May 21 07:23:07 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 21 May 2025 07:23:07 GMT Subject: RFR: 8347050: Console.readLine() drops '\' when reading through JLine [v2] In-Reply-To: References: Message-ID: > JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine(). > > This PR proposes to disable the history expansion. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing test on Windows. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25326/files - new: https://git.openjdk.org/jdk/pull/25326/files/fbf17434..392cede8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25326&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25326&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25326.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25326/head:pull/25326 PR: https://git.openjdk.org/jdk/pull/25326 From alanb at openjdk.org Wed May 21 07:54:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 May 2025 07:54:05 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v10] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 15:05:17 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweaking exact wording. src/jdk.zipfs/share/classes/module-info.java line 264: > 262: * {@linkplain Runtime.Version Java SE Platform version number}, > 263: * an {@code IllegalArgumentException} will be thrown when the Zip > 264: * filesystem is created. Minor comment, I think you want "when creating the ZIP file system" here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2099609806 From cay.horstmann at gmail.com Wed May 21 07:55:07 2025 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Wed, 21 May 2025 09:55:07 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> Message-ID: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is { "strings": [..., ..., ... ] } or { "pairs": [ { "first", ..., "second", ... }, ..., ... ] The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON. I deserialize into a record Content(List strings, List> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure. Could that work with Serialization 2.0? I suppose. Looking at https://www.youtube.com/watch?v=mIbA2ymCWDs, a marshaller can't dynamically produce either a List or a List>, so it would offer both in the Marshalled object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson. Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled?. So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier. My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive. Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension. Cheers, Cay Il 20/05/25 21:46, Paul Sandoz ha scritto: > Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic. > > Paul. > >> On May 20, 2025, at 12:21?PM, Swaranga Sarma wrote: >> >>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 >> >> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: >> >> ``` >> var jsonStr = "..." >> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants >> var serialized = Json.serialize(myRecord) >> ``` >> >> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. >> >> >> Regards >> Swaranga > -- Cay S. Horstmann | https://horstmann.com From vyazici at openjdk.org Wed May 21 08:23:54 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 21 May 2025 08:23:54 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 22:04:24 GMT, Naoto Sato wrote: >> All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention: >> >> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java >> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java >> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java > > JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR Created jline/jline3#1282. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099671435 From shade at openjdk.org Wed May 21 08:28:57 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 May 2025 08:28:57 GMT Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux) [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe wrote: >> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. >> >> We plan to deprecate this in JDK 25 and to remove it in JDK 26. >> >> This patch just writes a deprecation message to stderr: >> >> >> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls >> VFORK MODE DEPRECATED >> The VFORK launch mechanism has been deprecated for being dangerous. >> It will be removed in a future java version. Either remove the >> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode >> instead (-Djdk.lang.Process.launchMechanism=FORK). >> ... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > use string block `VFORK` deprecation sneaked up on me. I filed [JDK-8357436](https://bugs.openjdk.org/browse/JDK-8357436) to amend `jspawnhelper` warning message. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25282#issuecomment-2897063928 From vyazici at openjdk.org Wed May 21 08:32:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 21 May 2025 08:32:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2] In-Reply-To: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com> References: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com> Message-ID: <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com> On Tue, 20 May 2025 22:04:41 GMT, Naoto Sato wrote: >> test/jdk/java/io/Console/StdinEncodingTest.java line 46: >> >>> 44: * @run junit StdinEncodingTest >>> 45: */ >>> 46: public class StdinEncodingTest { >> >> AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.) > > `stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java` Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none1 that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too. For the record, AFAICT, there are no tests for `stderr.encoding`. 1 There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099692717 From shade at openjdk.org Wed May 21 08:39:30 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 May 2025 08:39:30 GMT Subject: RFR: 8357436: Change jspawnhelper warning recommendation from VFORK to FORK Message-ID: In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note. Additional testing: - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/25344/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357436 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25344/head:pull/25344 PR: https://git.openjdk.org/jdk/pull/25344 From shade at openjdk.org Wed May 21 08:39:30 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 May 2025 08:39:30 GMT Subject: RFR: 8357436: Change jspawnhelper warning recommendation from VFORK to FORK In-Reply-To: References: Message-ID: On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote: > In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder` @tstuefe ^ ------------- PR Comment: https://git.openjdk.org/jdk/pull/25344#issuecomment-2897095489 From viktor.klang at oracle.com Wed May 21 08:56:07 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Wed, 21 May 2025 08:56:07 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Message-ID: Hi, The way to layer a cake like this is as follows: [ class ] <- describes the general structure of the type (the types, names, and order of the parameter lists) [ instance ] <- describes the specific structure of the instance (the values) [ structure ] <- converts to/from structure to instance (think constructor / deconstructor pairs) [ specific format ] <- converts to/from structure to specific format (think MyCompany JSON Order format version 5) [ general format] <- parses / generates the general format (think XML / JSON / CSV / etc) [ IO ] <- reads / writes the general format (think file / socket / etc) As for the question how to represent a Timestamp or similar, is answered in the [specific format] layer of this cake. Why? Because the next version of the specification of that layer might change how timestamps should be represented at that layer. Now, while it is possible to short-circuit some of the layers of the cake by embedding specific format decisions at the class level, it means that there's now a tight (and somewhat exclusive) link between a specific format and class, with the implication that you cannot output the same instance as both XML and JSON (as it embeds the decisions of a specific json schema. If that was the default, and only, way to go about this, what specific format should a library decide to adhere to? The cake layering at the beginning of this email allows types to be used by many different specific formats and even general formats, such that you could read something from JSON-over-HTTPS and output it as XML-over-SFTP. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Cay Horstmann Sent: Wednesday, 21 May 2025 09:55 To: core-libs-dev at openjdk.org Subject: Re: Towards a JSON API for the JDK Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is { "strings": [..., ..., ... ] } or { "pairs": [ { "first", ..., "second", ... }, ..., ... ] The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON. I deserialize into a record Content(List strings, List> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure. Could that work with Serialization 2.0? I suppose. Looking at https://www.youtube.com/watch?v=mIbA2ymCWDs, a marshaller can't dynamically produce either a List or a List>, so it would offer both in the Marshalled object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson. Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled?. So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier. My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive. Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension. Cheers, Cay Il 20/05/25 21:46, Paul Sandoz ha scritto: > Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic. > > Paul. > >> On May 20, 2025, at 12:21?PM, Swaranga Sarma wrote: >> >>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 >> >> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: >> >> ``` >> var jsonStr = "..." >> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants >> var serialized = Json.serialize(myRecord) >> ``` >> >> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. >> >> >> Regards >> Swaranga > -- Cay S. Horstmann | https://horstmann.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.org Wed May 21 08:56:50 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 May 2025 08:56:50 GMT Subject: RFR: 8357436: Change jspawnhelper warning recommendation from VFORK to FORK In-Reply-To: References: Message-ID: On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote: > In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder` Good and trivial ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25344#pullrequestreview-2856881363 From duke at openjdk.org Wed May 21 09:04:34 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 21 May 2025 09:04:34 GMT Subject: RFR: 8356891: Some code simplifications in BigInteger [v20] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: <3FTt6zYsaifvbJyGHiZ1D4-1RB4wjnzv7FtE9haF8Zw=.43b952b0-283a-4765-8173-628da63ad519@github.com> > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Use one less counter in makePositive(int[]) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/6267a258..9a354abf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=18-19 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From duke at openjdk.org Wed May 21 09:07:35 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 21 May 2025 09:07:35 GMT Subject: RFR: 8356891: Some code simplifications in BigInteger [v21] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Correct typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/9a354abf..85f03605 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=19-20 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From tvaleev at openjdk.org Wed May 21 09:09:15 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 21 May 2025 09:09:15 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: References: Message-ID: > Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: > https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html > The specification is mostly composed of Math.min/max and Collections.min/max specifications. > > The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. > > I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Return first argument in case of tie (to be consistent with BinaryOperator); junit tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25297/files - new: https://git.openjdk.org/jdk/pull/25297/files/2cda59b7..9edc73e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=00-01 Stats: 20 lines in 2 files changed: 6 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297 PR: https://git.openjdk.org/jdk/pull/25297 From duke at openjdk.org Wed May 21 09:12:49 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 21 May 2025 09:12:49 GMT Subject: RFR: 8356891: Some code simplifications in BigInteger [v22] In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: > Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Correct typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25166/files - new: https://git.openjdk.org/jdk/pull/25166/files/85f03605..eb3834e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=20-21 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166 PR: https://git.openjdk.org/jdk/pull/25166 From tvaleev at openjdk.org Wed May 21 09:13:55 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 21 May 2025 09:13:55 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface In-Reply-To: References: Message-ID: On Mon, 19 May 2025 17:06:17 GMT, Raffaello Giulietti wrote: >> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max specifications. >> >> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. > > @amaembo Could you please switch the test class to make use of [JUnit](https://junit.org/junit5/)? For new tests we now prefer JUnit over TestNG. > Thanks! @rgiulietti I tried to mimic the nearby tests which use testng. Converted to junit 5. @archiecobbs > IMHO it makes sense. It's the min/max analog to a stable sort On the second thought, there is a consistency argument. We already have BinaryOperator.minBy and BinaryOperator.maxBy, which always return the first argument in case of tie (though this is not specified, probably it should be?). So it looks like it will be better to have both APIs consistent. One more point is that Guava's [`Ordering`](https://guava.dev/releases/snapshot-jre/api/docs/com/google/common/collect/Ordering.html#max(E,E)) (which extends `Comparator`) also returns the first argument in case of tie, so if we do the same, `Ordering` will not violate the `Comparator` contract. Thus I've changed the implementation to be in sync with both BinaryOperator and Ordering. This also addresses the @RogerRiggs comment: now implementations use `>=` and `<=`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2897204193 From duke at openjdk.org Wed May 21 10:02:54 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Wed, 21 May 2025 10:02:54 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com> References: <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com> <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com> Message-ID: On Wed, 21 May 2025 09:57:10 GMT, Stefan Lobbenmeier wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298: >> >>> 296: \ --linux-menu-group \n\ >>> 297: \ Menu group this application is placed in\n\ >>> 298: \ --linux-package-deps [, ...]\n\ >> >> The value of this CLI option is a string, not a comma-separated string list. For jpackage it is a "pass through" value. >> Maybe >> >> --linux-package-deps \n\ >> >> ? > > it is a comma separated string list for the underlying implementation but you would need to quote it so it is passed as a single arg. But I agree we can simplify this to > > Suggestion: > > \ --linux-package-deps \n\ As in, this worked in my testing: `--linux-package-deps "foo, bar"`, see https://github.com/JetBrains/compose-multiplatform/pull/5227#issuecomment-2659470908 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2099882692 From alanb at openjdk.org Wed May 21 10:12:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 May 2025 10:12:58 GMT Subject: RFR: 8357436: Change jspawnhelper warning recommendation from VFORK to FORK In-Reply-To: References: Message-ID: On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote: > In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder` Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25344#pullrequestreview-2857120972 From markus at headcrashing.eu Wed May 21 10:41:42 2025 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 21 May 2025 12:41:42 +0200 Subject: RFR: 8347027: String replaceAll with Function In-Reply-To: References: Message-ID: What is the benefit over the existing replacement methods? Is it easier to use, uses less resources, runs quicker...? Am 20.05.2025 um 19:04 schrieb kieran-farrell: > New API to the String.java class - replaceAllMapped(String, Function) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function). > > ------------- > > Commit messages: > - whitespace > - updates > - replaceAllMapped and test > > Changes: https://git.openjdk.org/jdk/pull/25335/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25335&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8347027 > Stats: 61 lines in 3 files changed: 61 ins; 0 del; 0 mod > Patch: https://git.openjdk.org/jdk/pull/25335.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/25335/head:pull/25335 > > PR: https://git.openjdk.org/jdk/pull/25335 From duke at openjdk.org Wed May 21 10:43:12 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 21 May 2025 10:43:12 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v11] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Tweaking exact wording. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/793e1856..ab15123a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=09-10 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From shade at openjdk.org Wed May 21 10:56:59 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 May 2025 10:56:59 GMT Subject: RFR: 8357436: Change jspawnhelper warning recommendation from VFORK to FORK In-Reply-To: References: Message-ID: On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote: > In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder` Thanks! GHA is green. Integrating under triviality rule. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25344#issuecomment-2897507616 From shade at openjdk.org Wed May 21 10:57:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 May 2025 10:57:00 GMT Subject: Integrated: 8357436: Change jspawnhelper warning recommendation from VFORK to FORK In-Reply-To: References: Message-ID: <2SylRci5Iu6U0ktfhgysI5cAHjG2ADdkHagF1lviV-M=.feb2f2a7-70fa-4df1-9ed8-3a329d03e398@github.com> On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote: > In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder` This pull request has now been integrated. Changeset: b8057cf1 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/b8057cf103bff6f8e2600c098519289a43227362 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8357436: Change jspawnhelper warning recommendation from VFORK to FORK Reviewed-by: stuefe, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25344 From jpai at openjdk.org Wed May 21 11:05:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 11:05:52 GMT Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently In-Reply-To: References: Message-ID: On Sun, 18 May 2025 21:58:04 GMT, Chen Liang wrote: > The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail. > > Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well. > > Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug. Hello Chen, in general for tests like these we don't use any explicit timeout value for waiting on certain condition. It's based on our past experiences in the CI and various other test runtime environments where no timeout value is a "right" timeout and can cause intermittent timeouts like here. In this test, I think we should just switch to using `await()` and `join()` i.e. no specific timeouts. If there is any bug (either in the test or the product code) and the test doesn't complete, then the jtreg's timeout infrastructure will fail the test and at the same time has the necessary features to collect all necessary details to help debug those unexpected timeout failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25292#issuecomment-2897532321 From duke at openjdk.org Wed May 21 11:17:56 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Wed, 21 May 2025 11:17:56 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier wrote: >> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space >> >> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 > > Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: > > change cli option to single string as suggested in PR review Also maybe one follow up question - what do I need to do so the change appears in older versions like - https://docs.oracle.com/en/java/javase/21/docs/specs/man/jpackage.html - https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpackage.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897563188 From cay.horstmann at gmail.com Wed May 21 11:46:34 2025 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Wed, 21 May 2025 13:46:34 +0200 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Message-ID: <72885797-8da3-4da2-a73b-898d62021283@gmail.com> That's exactly my point. The "specific format" issue doesn't get easier or harder with "serialization 2.0". Il 21/05/25 10:56, Viktor Klang ha scritto: > Hi, > > The way to layer a cake like this is as follows: > > [ class ]? ? ? ? ? ? ? ? ? ? ? ? ?<- describes the general structure of the type (the types, names, and order of the parameter lists) > [ instance ]? ? ? ? ? ? ? ? ? <- describes the specific structure of the instance (the values) > [ structure ]? ? ? ? ? ? ? ? ?<- converts to/from structure to instance (think constructor / deconstructor pairs) > [ specific format ]? ? <-? converts to/from structure to specific format (think MyCompany JSON Order format version 5) > [ general format]? ? ? <- parses / generates the general format (think XML / JSON / CSV / etc) > [ IO ]? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<- reads / writes the general format (think file / socket / etc) > > > As for the question how to represent a Timestamp or similar, is answered in the [specific format] layer of this cake. Why? Because the next version of the specification of that layer might change how timestamps should be represented at that layer. > > Now, while it is possible to short-circuit some of the layers of the cake by embedding *specific format*?decisions at the *class*?level, it means that there's now a tight (and somewhat exclusive) link between a *specific format*?and *class*, with the implication that you cannot output the same *instance*?as both XML and JSON (as it embeds the decisions of a specific *json schema*. If that was the default, and only, way to go about this, what *specific format*?should a library decide to adhere to? > > The cake layering at the beginning of this email allows types to be used by many different *specific formats*?and even *general formats*, such that you could read something from JSON-over-HTTPS and output it as XML-over-SFTP. > > Cheers, > ? > > * > * > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* core-libs-dev on behalf of Cay Horstmann > *Sent:* Wednesday, 21 May 2025 09:55 > *To:* core-libs-dev at openjdk.org > *Subject:* Re: Towards a JSON API for the JDK > Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is > > { "strings": [..., ..., ... ] } > > or > > { "pairs": [ { "first", ..., "second", ... },? ..., ... ] > > The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON. > > I deserialize into a record Content(List strings, List> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure. > > Could that work with Serialization 2.0? I suppose. Looking at https://www.youtube.com/watch?v=mIbA2ymCWDs , a marshaller can't dynamically produce either a List or a List>, so it would offer both in the Marshalled object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson. > > Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled?. > > So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier. > > My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive. > > Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension. > > Cheers, > > Cay > > Il 20/05/25 21:46, Paul Sandoz ha scritto: >> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic. >> >> Paul. >> >>> On May 20, 2025, at 12:21?PM, Swaranga Sarma wrote: >>> >>>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 >>> >>> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: >>> >>> ``` >>> var jsonStr = "..." >>> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants >>> var serialized = Json.serialize(myRecord) >>> ``` >>> >>> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. >>> >>> >>> Regards >>> Swaranga >> > > -- > > Cay S. Horstmann | https://horstmann.com > -- Cay S. Horstmann | https://horstmann.com From rgiulietti at openjdk.org Wed May 21 11:57:56 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 21 May 2025 11:57:56 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: References: Message-ID: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com> On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev wrote: >> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max specifications. >> >> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Return first argument in case of tie (to be consistent with BinaryOperator); junit tests A couple of nits. src/java.base/share/classes/java/util/Comparator.java line 200: > 198: * @return the larger of {@code a} and {@code b} according to this comparator. > 199: * @throws ClassCastException if the collection contains elements that are > 200: * not mutually comparable (for example, strings and `` is more intent revealing. Suggestion: * not mutually comparable (for example, strings and test/jdk/java/util/Comparator/MinMaxTest.java line 39: > 37: public class MinMaxTest { > 38: @Test > 39: public void testMin() { According to [this](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods), test methods do not need to be `public` (but cannot be `private`). Suggestion: void testMin() { ------------- PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-2857412002 PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2100089152 PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2100089409 From asemenyuk at openjdk.org Wed May 21 11:59:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 11:59:50 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier wrote: >> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space >> >> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 > > Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: > > change cli option to single string as suggested in PR review Thank you for making the change! Other property files and jpackage.md should also be updated to sync them with HelpResources.properties. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897674146 From asemenyuk at openjdk.org Wed May 21 11:59:51 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 11:59:51 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: References: Message-ID: <_iudidZ-9mKp7ED0Kae-FaxpxGnlOBLWC5frD64WIKo=.a3c262c1-31ea-474a-af86-eee909dcf191@github.com> On Wed, 21 May 2025 11:15:08 GMT, Stefan Lobbenmeier wrote: > Also maybe one follow up question - what do I need to do so the change appears in older versions like You need to backport this fix once it is integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897676692 From asemenyuk at openjdk.org Wed May 21 12:05:59 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 12:05:59 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: References: <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com> <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com> Message-ID: On Wed, 21 May 2025 10:00:03 GMT, Stefan Lobbenmeier wrote: > As in, this worked in my testing: --linux-package-deps "foo, bar" Of course. You can put any string for `--linux-package-deps` option, jpackage will pass it as-is to the underlying tool. Unlike, e.g. `--arguments`, for which jpackage will tokenize the value into a string array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100114692 From asemenyuk at openjdk.org Wed May 21 12:11:56 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 12:11:56 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier wrote: >> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space >> >> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 > > Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: > > change cli option to single string as suggested in PR review Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties line 36: > 34: MSG_Help_mac_install=\ --mac-dmg-content [,...]\n Nimmt den gesamten referenzierten Inhalt in die DMG-Datei auf.\n Diese Option kann mehrmals verwendet werden. \n > 35: MSG_Help_mac_launcher=\ --mac-package-identifier \n Eine ID, die die Anwendung f??r macOS eindeutig identifiziert\n Standardwert ist der Hauptklassenname.\n Es d??rfen nur alphanumerische Zeichen (A-Z, a-z, 0-9), Bindestriche (-)\n und Punkte (.) verwendet werden.\n --mac-package-name \n Name der Anwendung, wie in der Men??leiste angezeigt\n Dieser kann vom Anwendungsnamen abweichen.\n Er darf maximal 15 Zeichen enthalten und muss f??r die Anzeige\n in der Men??leiste und im Infofenster der Anwendung geeignet sein.\n Standardwert: Anwendungsname.\n --mac-package-signing-prefix \n Beim Signieren des Anwendungspackages wird dieser Wert\n allen zu signierenden Komponenten ohne vorhandene\n Package-ID als Pr??fix vorangestellt.\n --mac-sign\n Anforderung zum Signieren des Packages oder des vordefinierten\n Anwendungsimages\n --mac-signing-keychain \n Name des Schl??sselbundes f??r die Suche nach der Signaturidentit??t\n Bei fehlender Angabe werden die Standardschl??sselbunde verwendet.\n --mac-signing-key-user-name \n Team- oder Benutzernamensteil der Apple-Signaturidentit??ten. Um direkt zu steuern,\n welche Signaturidentit??t zum Signieren eines Anwendungsimages oder\n Installationsprogramms verwendet wird, verwenden Sie --mac-app-image-sign-identity und/oder\n --mac-installer-sign-identity. Diese Option kann nicht mit\n --mac-app-image-sign-identity oder --mac-installer-sign-identity kombiniert werden.\n --mac-app-image-sign-identity \n Zum Signieren des Anwendungsimages verwendete Identit??t. Dieser Wert wird\n direkt an die Option --sign des Tools "codesign" ??bergeben. Diese Option kann nicht\n mit --mac-signing-key-user-name kombiniert werden.\n --mac-installer-sign-identity \n Zum Signieren des Installationsprogramms "pkg" verwendete Identit??t. Dieser Wert wird\n direkt an die Option --sign des Tools "productbuild" ??bergeben. Diese Option\n kann nicht mit --mac-signing-key-user-name kombiniert werden.\n --mac-app-store\n Gibt an, dass die jpackage-Ausgabe f??r den\n Mac App Store bestimmt ist.\n --mac-entitlements \n Pfad zu einer Datei mit Berechtigungen, die beim Signieren\n von ausf??hrbaren Dateien und Librarys im Bundle verwendet werden sollen.\n --mac-app-category \n Zeichenfolge f??r das Erstellen von LSApplicationCategoryType in\n Anwendungs-plist. Standardwert: "utilities".\n > 36: MSG_Help_linux_install=\ --linux-package-name \n Name f??r das Linux-Package, Standardwert: Anwendungsname\n --linux-deb-maintainer \n Maintainer f??r .deb-Package\n --linux-menu-group \n Men??gruppe, in der diese Anwendung abgelegt wird\n --linux-package-deps [, ...]\n Erforderliche Packages oder Funktionen f??r die Anwendung\n --linux-rpm-license-type \n Typ der Lizenz ("License: " der RPM-SPEC-Datei)\n --linux-app-release \n Releasewert der RPM-SPEC-Datei oder \n Debian-Revisionswert der DEB-Kontrolldatei\n --linux-app-category \n Gruppenwert der RPM-SPEC-Datei oder \n Abschnittswert der DEB-Kontrolldatei\n --linux-shortcut\n Erstellt eine Verkn??pfung f??r die Anwendung.\n `--linux-package-deps ` to sync with HelpResources.properties src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties line 39: > 37: MSG_Help_mac_launcher=\ --mac-package-identifier \n macOS???????????????????????????????????????????????????ID\n ?????????????????????????????????????????????????????????????????????\n ?????????(A-Z???a-z???0-9)???????????????(-)?????????????????????(.)????????????\n ?????????????????????\n --mac-package-name \n ????????????????????????????????????????????????????????????????????????\n ???????????????????????????????????????????????????\n ???????????????16?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????\n ?????????????????????????????????????????????????????????\n ????????????????????????????????????????????????????????????????????????\n --mac-package-signing-prefix \n ???????????????????????????????????????????????????????????????\n ????????????????????????ID???????????? ??????????????????????????????????????????????????????\n ???????????????????????????????????????????????????\n --mac-sign\n ???????????????????????????????????????????????????????????????????????????????????????????????????\n ???????????????????????????\n --mac-signing-keychain \n ????????????????????????????????????????????????????????????????????????\n ?????????????????????????????????????????????????????????????????????????????????\n --mac-signing-key-user-name \n Apple???????????????????????????????????????????????????????????????????????????\n ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????\n ?????????????????????--mac-app-image-sign-identity?????????\n --mac-installer-sign-identity(??????????????????)?????????????????????????????????????????????\n --mac-app-image-sign-identity????????? --mac-installer-sign-identity?????????????????????????????????????????????\n --mac-app-image-sign-identity \n ????????????????????????????????????????????????????????????????????????????????????????????????????????????\n "codesign"????????????--sign????????????????????????????????????????????????????????????\n \ > 38: --mac-signing-key-user-name?????????????????????????????????????????????\n --mac-installer-sign-identity \n "pkg"???????????????????????????????????????????????????????????????????????????????????????\n "productbuild"????????????--sign????????????????????????????????????????????????????????????\n --mac-signing-key-user-name?????????????????????????????????????????????\n --mac-app-store\n jpackage?????????Mac App Store??????????????????\n ??????????????????\n --mac-entitlements \n ??????????????????????????????????????????????????????????????????????????????\n ???????????????????????????????????????????????????\n --mac-app-category \n ???????????????????????????plist???LSApplicationCategoryType?????????????????????????????????????????????\n ?????????????????????"utilities"?????????\n > 39: MSG_Help_linux_install=\ --linux-package-name \n Linux????????????????????????????????????????????????????????????????????????????????????????????????\n --linux-deb-maintainer \n .deb??????????????????Maintainer\n --linux-menu-group \n ?????????????????????????????????????????????????????????????????????????????????\n --linux-package-deps [, ...]\n ??????????????????????????????????????????????????????????????????\n --linux-rpm-license-type \n ???????????????????????????(RPM .spec???"License: ")\n --linux-app-release \n RPM .spec???????????????????????????????????????\n DEB????????????????????????????????????Debian?????????????????????\n --linux-app-category \n RPM .spec??????????????????????????????????????? \n DEB??????????????????????????????????????????? ???????????\n --linux-shortcut\n ?????????????????????????????????????????????????????????????????????\n `--linux-package-deps ` to sync with HelpResources.properties src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties line 37: > 35: MSG_Help_mac_install=\ --mac-dmg-content [,...]\n ?????? DMG ???????????????????????????\n ??????????????????????????????\n > 36: MSG_Help_mac_launcher=\ --mac-package-identifier \n ????????????????????? macOS ????????????????????????\n ????????????????????????\n ???????????????????????? (A-Z,a-z,0-9)???????????? (-) ???\n ?????? (.) ?????????\n --mac-package-name \n ??????????????????????????????????????????\n ???????????????????????????????????????\n ?????????????????????????????? 16 ??????????????????\n ????????????????????????????????????????????????????????????\n ??????????????????????????????\n --mac-package-signing-prefix \n ?????????????????????????????????????????????????????????\n ?????????????????????????????????????????????\n ?????????????????????\n --mac-sign\n ???????????????????????????????????????????????????\n ???????????????\n --mac-signing-keychain \n ????????????????????????????????????????????? ???\n ????????????????????????????????????????????????\n --mac-signing-key-user-name \n Apple ?????????????????????????????????????????????????????????\n ???????????????????????????????????????????????????????????????\n ???????????????????????? --mac-app-image-sign-identity ???/???\n --mac-installer-sign-identity?????????????????????\n --mac-app-image-sign-identity ??? --mac-installer-sign-identity ???????????????\n --mac-app-image-sign-identity \n ??????????????????????????????????????????????????????????????????\n ????????? "codesign" ????????? --sign ????????????????????????\n ??? --mac-signing-key-user-name ???????????????\n --mac-installer-sign-identity \n ????????? "pkg" ???????????????????????????????????????????????????\n ????????? "productbuild" ????????? --sign ????????????????????????\n ??? --mac-signing-key-user-name ?????????????? ?\n --mac-app-store\n ?????? jpackage ????????????\n Mac App Store???\n --mac-entitlements \n ???????????????????????????????????????????????????????????????????????????\n ?????????????????????????????????????????????\n --mac-app-category \n ???????????????????????? plist ??? LSApplicationCategoryType ???\n ???????????????????????? "utilities"???\n > 37: MSG_Help_linux_install=\ --linux-package-name \n Linux ????????????????????????????????????????????????\n --linux-deb-maintainer \n .deb ????????????????????????\n --linux-menu-group \n ?????????????????????????????????\n --linux-package-deps [, ...]\n ???????????????????????????????????????\n --linux-rpm-license-type \n ?????????????????????RPM .spec ??? "License: "???\n --linux-app-release \n RPM .spec ???????????????????????? \n DEB ??????????????? Debian ????????????\n --linux-app-category \n RPM .spec ?????????????????? \n DEB ?????????????????????\n --linux-shortcut\n ????????????????????????????????????\n `--linux-package-deps ` to sync with HelpResources.properties src/jdk.jpackage/share/man/jpackage.md line 426: > 424: : Menu group this application is placed in > 425: > 426: `--linux-package-deps *package-dep* \[`,`*package-dep*...\]` Should be *package-dep-string* to sync with HelpResources.properties ------------- PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2857464848 PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100125034 PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100125279 PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100125547 PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100122529 From viktor.klang at oracle.com Wed May 21 12:34:04 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Wed, 21 May 2025 12:34:04 +0000 Subject: [External] : Re: Towards a JSON API for the JDK In-Reply-To: <72885797-8da3-4da2-a73b-898d62021283@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> <72885797-8da3-4da2-a73b-898d62021283@gmail.com> Message-ID: I'd say it's more nuanced than that?Serialization 2.0 can improve over Serializion 1.0 by allowing users to decide what their formats should be. With Serialization 1.0, it's Java Serialization. Now, the act of defining (possibly bidirectional) conversions between the in-memory structure of classes and specific output formats typically needs to adhere to some form of specification (hence the word specific) so it definitely does help to know where such translation needs to occur, which is something Serialization 2.0 can make clear. That was my point ? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Cay Horstmann Sent: Wednesday, 21 May 2025 13:46 To: Viktor Klang ; core-libs-dev at openjdk.org Subject: [External] : Re: Towards a JSON API for the JDK That's exactly my point. The "specific format" issue doesn't get easier or harder with "serialization 2.0". Il 21/05/25 10:56, Viktor Klang ha scritto: > Hi, > > The way to layer a cake like this is as follows: > > [ class ] <- describes the general structure of the type (the types, names, and order of the parameter lists) > [ instance ] <- describes the specific structure of the instance (the values) > [ structure ] <- converts to/from structure to instance (think constructor / deconstructor pairs) > [ specific format ] <- converts to/from structure to specific format (think MyCompany JSON Order format version 5) > [ general format] <- parses / generates the general format (think XML / JSON / CSV / etc) > [ IO ] <- reads / writes the general format (think file / socket / etc) > > > As for the question how to represent a Timestamp or similar, is answered in the [specific format] layer of this cake. Why? Because the next version of the specification of that layer might change how timestamps should be represented at that layer. > > Now, while it is possible to short-circuit some of the layers of the cake by embedding *specific format* decisions at the *class* level, it means that there's now a tight (and somewhat exclusive) link between a *specific format* and *class*, with the implication that you cannot output the same *instance* as both XML and JSON (as it embeds the decisions of a specific *json schema*. If that was the default, and only, way to go about this, what *specific format* should a library decide to adhere to? > > The cake layering at the beginning of this email allows types to be used by many different *specific formats* and even *general formats*, such that you could read something from JSON-over-HTTPS and output it as XML-over-SFTP. > > Cheers, > ? > > * > * > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* core-libs-dev on behalf of Cay Horstmann > *Sent:* Wednesday, 21 May 2025 09:55 > *To:* core-libs-dev at openjdk.org > *Subject:* Re: Towards a JSON API for the JDK > Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is > > { "strings": [..., ..., ... ] } > > or > > { "pairs": [ { "first", ..., "second", ... }, ..., ... ] > > The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON. > > I deserialize into a record Content(List strings, List> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure. > > Could that work with Serialization 2.0? I suppose. Looking at https://urldefense.com/v3/__https://www.youtube.com/watch?v=mIbA2ymCWDs__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkfsczV05g$ , a marshaller can't dynamically produce either a List or a List>, so it would offer both in the Marshalled object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson. > > Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled?. > > So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier. > > My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive. > > Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension. > > Cheers, > > Cay > > Il 20/05/25 21:46, Paul Sandoz ha scritto: >> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic. >> >> Paul. >> >>> On May 20, 2025, at 12:21?PM, Swaranga Sarma wrote: >>> >>>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 >>> >>> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: >>> >>> ``` >>> var jsonStr = "..." >>> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants >>> var serialized = Json.serialize(myRecord) >>> ``` >>> >>> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. >>> >>> >>> Regards >>> Swaranga >> > > -- > > Cay S. Horstmann | https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$ > -- Cay S. Horstmann | https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed May 21 12:34:55 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Wed, 21 May 2025 12:34:55 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 12:07:52 GMT, Alexey Semenyuk wrote: >> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: >> >> change cli option to single string as suggested in PR review > > src/jdk.jpackage/share/man/jpackage.md line 426: > >> 424: : Menu group this application is placed in >> 425: >> 426: `--linux-package-deps *package-dep* \[`,`*package-dep*...\]` > > Should be *package-dep-string* to sync with HelpResources.properties Suggestion: `--linux-package-deps *package-dep-string*` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100173717 From duke at openjdk.org Wed May 21 12:41:24 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Wed, 21 May 2025 12:41:24 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3] In-Reply-To: References: Message-ID: > The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space > > You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: also use in other locations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23638/files - new: https://git.openjdk.org/jdk/pull/23638/files/062239e7..91831e7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23638&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23638&range=01-02 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23638/head:pull/23638 PR: https://git.openjdk.org/jdk/pull/23638 From duke at openjdk.org Wed May 21 12:41:24 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Wed, 21 May 2025 12:41:24 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 11:56:31 GMT, Alexey Semenyuk wrote: > Thank you for making the change! Other property files and jpackage.md should also be updated to sync them with HelpResources.properties. Done, sorry I missed them ------------- PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897820039 From ethan at mccue.dev Wed May 21 12:47:44 2025 From: ethan at mccue.dev (Ethan McCue) Date: Wed, 21 May 2025 08:47:44 -0400 Subject: Towards a JSON API for the JDK In-Reply-To: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Message-ID: In the my world - which I am again very interested in revisiting once there is a version of patterns I can touch - you may approach that problem in the following way: sealed interface Content extends JsonEncodable { static Content fromJson(Json json) { return switch (json) { case JsonObject obj when obj.get("pairs") != null -> new Pairs( field( obj, "pairs", pairs -> array(pairs, pair -> Pair.fromJson(pair, string())) ) ); case JsonObject obj when obj.get("strings") != null -> new Strings( field(obj, "strings", array(string())) ); default -> throw JsonDecodeException.of("Expected a top-level \"pairs\" or \"strings\".", json); }; } } record Pair(T first, T second) { Json toJson(Function f) { return Json.objectBuilder() .put("first", f.apply(first)) .put("second", f.apply(second)) .build(); } static Pair fromJson(Json json, JsonDecoder decoder) { return new Pair<>( field(json, "first", decoder), field(json, "second", decoder) ); } } record Pairs(List> value) implements Content { @Override public Json toJson() { return Json.objectBuilder() .put("pairs", Json.of(value, pair -> pair.toJson(JsonString::of))) .build(); } } record Strings(List value) implements Content { @Override public Json toJson() { return Json.objectBuilder() .put("strings", Json.of(value, JsonString::of)) .build(); } } I think it is reasonable to expect/hope patterns can be an improvement on the "yield value or throw" strategy of decoders, but I think this is sufficient to show that this sort of task is not solely solvable via databinding. JSON is different from other "core capabilities" the JDK adds in that the important factor here isn't only whether "there is an API which can represent a JSON document," but also what form solving problems that require JSON takes absent third-party APIs. On Wed, May 21, 2025 at 3:56?AM Cay Horstmann wrote: > Data binding is indeed complex because real-life JSON is messy. I reviewed > some code in which I use Jackson data binding. Here is an example of a > sticky issue. I have Content that's either a list of strings or a list of > string pairs (don't ask). The JSON is > > { "strings": [..., ..., ... ] } > > or > > { "pairs": [ { "first", ..., "second", ... }, ..., ... ] > > The JavaScript client relies on the fact that exactly one of "strings" and > "pairs" exists. No, I can't change the JSON. > > I deserialize into a record Content(List strings, > List> pairs) {}. And tweak Jackson to not to serialize entries > with null values. It's not pretty, but it is easier than doing tree > navigation, since this sits deeply in an otherwise fairly regular structure. > > Could that work with Serialization 2.0? I suppose. Looking at > https://www.youtube.com/watch?v=mIbA2ymCWDs, a marshaller can't > dynamically produce either a List or a List>, so it > would offer both in the Marshalled object, with one of them being > null. I would need to tell the wire format generator to write the non-null > one. Which is ok--that's what I do now with Jackson. > > Here is another common issue. You have a record TimedPoint(int x, int y, > Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 > string? Millis since the epoch? Who makes that choice? Slide 29 says "Let > the class author be in charge". WHICH class author? Can java.time.Instant > make a universal choice, for all possible wire formats? Surely not. Can > TimedPoint? Maybe. Or it is the job of the wire format generator to do that > with Marshalled?. > > So here is my point. If the JDK were to include a JSON data mapper, that > data mapper is either rigid or flexible. Designing a flexible data mapper > is hard. Serialization 2.0 would not make it any easier. > > My hunch is that flexible JSON data mapping is hard to do within the scope > of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? > Or strike out on its own? Neither seems attractive. > > Ethan and R?mi have presented rigid JSON mappers. They handle nothing but > numbers, strings, booleans, maps, lists, records. Is that useful? Surely, > for simple programs. For that, there is no reason to wait for Serialization > 2.0. If and when that comes, it would be a natural extension. > > Cheers, > > Cay > > Il 20/05/25 21:46, Paul Sandoz ha scritto: > > Data binding is a complex feature, even if some examples make it appear > simple. Our intention is to explore alignment with the serialization 2.0 > effort, when we are ready to so. Hence, I would urge folks to be patience > and watch out Brian and Viktor?s Devoxx 2024 talk on the topic. > > > > Paul. > > > >> On May 20, 2025, at 12:21?PM, Swaranga Sarma > wrote: > >> > >>> A potential advantage that we (the OpenJDK community) can more easily > do is devise an API that resonates with direction the Java platform is > heading, specifically around the pattern matching and serialization 2.0 > >> > >> Right, but most of the discussion here seems to be on the low level > tree API and how one might navigate it (perhaps using pattern matching). I > am not seeing any discussion on the serialization/deserialization or any > reasoning why that is not the goal of the new JEP. Basically a very focused > and narrow API: > >> > >> ``` > >> var jsonStr = "..." > >> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a > few other variants > >> var serialized = Json.serialize(myRecord) > >> ``` > >> > >> This leaves the tree API open to reimplementation later when pattern > matching and other features are firmly in place in the JDK. I am making a > case that this would be more immediately useful for the most common and > simpler cases. > >> > >> > >> Regards > >> Swaranga > > > > -- > > Cay S. Horstmann | https://horstmann.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Wed May 21 12:49:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 12:49:55 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com> Message-ID: On Tue, 20 May 2025 22:00:39 GMT, Henry Jen wrote: >> Yes I understand and currently we have no documentation as to what the return values might be. An inconsistency in the order should also be 1 based we only return a 0 if there are no issues. Any warning should be treated the same >> >> My point is that it is worth considering with these changes > > Point taken. For documentation wise, I don't think it's necessary to specify at this point. > For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code. Hello Lance/Henry, > Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc... I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100203673 From jpai at openjdk.org Wed May 21 13:00:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 13:00:58 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com> Message-ID: On Wed, 21 May 2025 12:47:00 GMT, Jaikiran Pai wrote: >> Point taken. For documentation wise, I don't think it's necessary to specify at this point. >> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code. > > Hello Lance/Henry, > >> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc... > > I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. > > Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures. > For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code. For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it). Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100232060 From duke at openjdk.org Wed May 21 13:49:38 2025 From: duke at openjdk.org (serhiysachkov) Date: Wed, 21 May 2025 13:49:38 GMT Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual Message-ID: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual ------------- Commit messages: - 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual Changes: https://git.openjdk.org/jdk/pull/25355/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25355&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357462 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25355/head:pull/25355 PR: https://git.openjdk.org/jdk/pull/25355 From erikj at openjdk.org Wed May 21 13:53:37 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 May 2025 13:53:37 GMT Subject: RFR: 8357173: Split jtreg test group jdk tier3 [v2] In-Reply-To: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com> References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com> Message-ID: > We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split. Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: - grammar - Clarified the group split with comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25274/files - new: https://git.openjdk.org/jdk/pull/25274/files/c12c5780..dc18705a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25274&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25274&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25274.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25274/head:pull/25274 PR: https://git.openjdk.org/jdk/pull/25274 From erikj at openjdk.org Wed May 21 13:53:37 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 May 2025 13:53:37 GMT Subject: RFR: 8357173: Split jtreg test group jdk tier3 In-Reply-To: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com> References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com> Message-ID: On Fri, 16 May 2025 20:16:02 GMT, Erik Joelsson wrote: > We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split. Renamed tier3_part2 -> tier3_jpackage and added comments better detailing the reason and where to add additional tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25274#issuecomment-2898044824 From jpai at openjdk.org Wed May 21 13:55:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 13:55:53 GMT Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a ByteBuffer throw UOE if backed by shared memory segment In-Reply-To: References: Message-ID: On Tue, 20 May 2025 07:37:34 GMT, Per Minborg wrote: > This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used. > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. src/java.base/share/classes/java/util/zip/Adler32.java line 102: > 100: NIO_ACCESS.acquireSession(buffer); > 101: try { > 102: adler = updateByteBuffer(adler, NIO_ACCESS.getBufferAddress(buffer), pos, rem); Hello Per, from what I can see in the implementation of `NIO_ACCESS.getBufferAddress(...)` it merely returns `buffer.address` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/Buffer.java#L862. So if I understand this change correctly, what we are proposing here is that we want to avoid the additional checks (checks related to `MemorySegment` that can fail?) that are there in the `DirectBuffer.address()` method implementation? Is that what this change is addressing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25321#discussion_r2100361279 From lancea at openjdk.org Wed May 21 14:02:58 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 21 May 2025 14:02:58 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com> Message-ID: <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com> On Wed, 21 May 2025 12:58:37 GMT, Jaikiran Pai wrote: >> Hello Lance/Henry, >> >>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc... >> >> I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. >> >> Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures. > >> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code. > > For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it). > > Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation. > Point taken. For documentation wise, I don't think it's necessary to specify at this point. For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code. I am OK to currently specify as non-zero, it is a discussion that can be continued as to what if anything more to do (as Jai mentions) Any warnings should result in a non-zero for a return code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100377057 From duke at openjdk.org Wed May 21 14:12:57 2025 From: duke at openjdk.org (kieran-farrell) Date: Wed, 21 May 2025 14:12:57 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 19:37:31 GMT, Philippe Marschall wrote: >> There's no (time-based) relationship between the currentTimeMillis() value and the nanoTime value. >> They are independent clocks and are read separately and are un-correlated. They won't be usable as lsb of the millis value. >> >> I'm surprised that the `nextBytes` is slower, since it looks like it calls `nextLong` and puts it in a newly allocated byte[8]. Normal perf measurements won't account for the gc overhead to recover it. >> >> The nsBits computation looks odd, nanoTme returns nanoseconds (10^9), the remainder (% 1_000_000) is then milliseconds. > >> if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method > > Probably because `SecureRandom` gets `#nextLong()` from `Random`, which ends up calling `#next(int)` twice, so it allocates twice. Overriding `#nextLong()` in `SecureRandom` may help a little but will still have to allocate as long as `SecureRandomSpi` is not updated. The nsBytes were included to give some additional but not guaranteed monotonicity in the event of msTime collisions on a single instance of a JVM. I updated the method to print the msTime and nsBits for visual purposes seen below. The nsBits increase until cycling back to a lower value on the last or +/- 1 of the last instance of the same msTime value as tested on Linux and MacOS . I'm not sure of the reason why the cycles are almost in sync given that the times are not linked. However Marschall has pointed out that nanoTime() resolution is weaker on windows so maybe its not something that can be depended on. In that case I could revert to the random byte only implementation and remove the nsBytes fro random data. As for the nsBits computation, in order to align with the RFC, my understanding was to get the remainder of nsTime (% 1_000_000) to get the nanoseconds within the current millisecond, divide by 1_000_000 to convert to a fraction of a ms and multiply by 4096L to scale to the integer range to fit into the 12 bits permitted for the ns timestamp. msTime: 1747835228108, nsBits: 1336 msTime: 1747835228137, nsBits: 1333 msTime: 1747835228137, nsBits: 1794 msTime: 1747835228137, nsBits: 2206 msTime: 1747835228137, nsBits: 2766 msTime: 1747835228137, nsBits: 3040 msTime: 1747835228137, nsBits: 3485 msTime: 1747835228137, nsBits: 3901 msTime: 1747835228138, nsBits: 239 msTime: 1747835228138, nsBits: 651 msTime: 1747835228138, nsBits: 918 msTime: 1747835228138, nsBits: 1321 msTime: 1747835228138, nsBits: 1729 msTime: 1747835228138, nsBits: 2140 msTime: 1747835228138, nsBits: 2535 msTime: 1747835228138, nsBits: 2874 msTime: 1747835228138, nsBits: 3243 msTime: 1747835228138, nsBits: 3641 msTime: 1747835228138, nsBits: 3967 msTime: 1747835228139, nsBits: 227 msTime: 1747835228139, nsBits: 524 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2100405267 From alan.bateman at oracle.com Wed May 21 14:18:04 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 21 May 2025 15:18:04 +0100 Subject: Reducing Classloader's parallelLockMap memory consumption proposal In-Reply-To: References: Message-ID: <8168f8c8-75c0-4158-b8d8-fcc4d495dced@oracle.com> On 20/05/2025 03:42, Dmytro Ukhlov wrote: > Hello! > > I created PR is scope of jenkins-core project: > https://github.com/jenkinsci/jenkins/pull/10659 > Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675 > > In this PR i propped to override > protected Object getClassLoadingLock(String className) > method and use weak references for lock objects > > Jenkins is a plugable platform, each plugin has its own class loader > and its parallelLockMap may consume 10mb of RAM. As a result it might > have 2gb overhead if ~200 plugins installed. > > Jenkins maintainers ask me to consider making this improvement in base This is an issue for "parallel capable" class loaders, esp. those that don't directly delegate. I don't know what topology is used in the Jenkins plugin class loaders and whether these class loader need to parallel capable. Expunging entries isn't really feasible, at least not without changing the spec. JDK-8005233 [1] has a write-up from David Holmes on this topic and a prototype for "fully concurrent" class loaders. This work has been parked for several years. Maybe some day it will get dusted off and a JEP drafted (due to the significance). -Alan [1] https://bugs.openjdk.org/browse/JDK-8005233 From asemenyuk at openjdk.org Wed May 21 14:22:57 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 14:22:57 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 12:41:24 GMT, Stefan Lobbenmeier wrote: >> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space >> >> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 > > Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: > > also use in other locations Marked as reviewed by asemenyuk (Reviewer). Looks good! ------------- PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2857937512 PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2898151502 From asemenyuk at openjdk.org Wed May 21 14:40:09 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 14:40:09 GMT Subject: Integrated: 8333664: Decouple command line parsing and package building in jpackage In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com> Message-ID: <8PxSUb6QcJjXdWw81qH_mhRd1ZnPvbvKJfXGbPYPVWw=.ee21a33e-cc8d-4fba-8613-3f20728bbca1@github.com> On Wed, 12 Jun 2024 01:37:19 GMT, Alexey Semenyuk wrote: > Refactor jpackage to separate the configuration and execution phases. > At the configuration phase, jpackage parses command-line arguments and validates them. > At the execution phase, jpackage builds a bundle based on data collected at the configuration phase. > > There was no clear separation between these phases. Both used the same data type (`Map`), making it hard to understand and use properly. > > This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling. > > The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map` "params". > > Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers. > > jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html > > **Functional changes** > jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below. > > - Minimize copying of the source app image when doing native packaging. > > Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations. > > - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles. > > post- and pre- install PKG scripts for SimplePackageTest package before and after the change: > > > > > > > > > URL: https://git.openjdk.org/jdk/commit/21c1282207614e57138b37a7adca4ccf11cf5bef Stats: 23911 lines in 195 files changed: 17135 ins; 5686 del; 1090 mod 8333664: Decouple command line parsing and package building in jpackage Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/19668 From liach at openjdk.org Wed May 21 14:43:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 14:43:52 GMT Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently In-Reply-To: References: Message-ID: <0t1u8ufzpSnLQ-sKpoj92WNl94VKDTirlA193ujU2WA=.d53d60b1-9ab5-4689-8fb8-42afd78a16c8@github.com> On Sun, 18 May 2025 21:58:04 GMT, Chen Liang wrote: > The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail. > > Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well. > > Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug. I still wish to keep these explicit timeouts - they can be fiddled around for debugging when something stalls after a ClassValue change. In comparison, the argless variants are much harder to tweak and/or debug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25292#issuecomment-2898217956 From alanb at openjdk.org Wed May 21 14:48:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 May 2025 14:48:54 GMT Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a ByteBuffer throw UOE if backed by shared memory segment In-Reply-To: References: Message-ID: On Tue, 20 May 2025 07:37:34 GMT, Per Minborg wrote: > This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used. > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. test/jdk/java/util/zip/ChecksumBase.java line 79: > 77: checksum.update(bb); > 78: checkChecksum(checksum, expected); > 79: } The src changes look right. For the tests then I wonder if we could expand to exercise with view of byte buffers on memory segments allocated from all arenas with bounded lifetime. I think that would help the test coverage. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25321#discussion_r2100487463 From alanb at openjdk.org Wed May 21 14:53:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 May 2025 14:53:53 GMT Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a ByteBuffer throw UOE if backed by shared memory segment In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:53:15 GMT, Jaikiran Pai wrote: >> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used. >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > src/java.base/share/classes/java/util/zip/Adler32.java line 102: > >> 100: NIO_ACCESS.acquireSession(buffer); >> 101: try { >> 102: adler = updateByteBuffer(adler, NIO_ACCESS.getBufferAddress(buffer), pos, rem); > > Hello Per, from what I can see in the implementation of `NIO_ACCESS.getBufferAddress(...)` it merely returns `buffer.address` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/Buffer.java#L862. So if I understand this change correctly, what we are proposing here is that we want to avoid the additional checks (checks related to `MemorySegment` that can fail?) that are there in the `DirectBuffer.address()` method implementation? Is that what this change is addressing? All methods in the API that accept a ByteBuffer and access it as DirectBuffer should have been changed to use the acquireSession/getBufferAddress/releaseSession. Several were missed, I think because we didn't have enough tests to exercise the views. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25321#discussion_r2100500374 From lmesnik at openjdk.org Wed May 21 15:09:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 May 2025 15:09:55 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> References: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> Message-ID: <4L78FN5dBp6so8QWalypTvm2lnXb9GU6zl3Hw6hK6Go=.26715817-5092-4489-ba9a-bf3a9800c478@github.com> On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks for fixing this! ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2858114150 From henryjen at openjdk.org Wed May 21 15:24:56 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 21 May 2025 15:24:56 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9] In-Reply-To: <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com> References: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com> <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com> <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com> Message-ID: On Wed, 21 May 2025 14:00:03 GMT, Lance Andersen wrote: >>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code. >> >> For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it). >> >> Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation. > >> Point taken. For documentation wise, I don't think it's necessary to specify at this point. For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code. > > I am OK to currently specify as non-zero, it is a discussion that can be continued as to what if anything more to do (as Jai mentions) > > Any warnings should result in a non-zero for a return code. OK, I'll update the PR to consider inconsistent order to be invalid even though it won't cause issue but indeed a sign that's not created by the official `jar` tool. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100570620 From henryjen at openjdk.org Wed May 21 15:49:29 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 21 May 2025 15:49:29 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Mismatched order is considered invalid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/0caecfcd..b0df54d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=09-10 Stats: 24 lines in 2 files changed: 16 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From maurizio.cimadamore at oracle.com Wed May 21 16:01:19 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 May 2025 17:01:19 +0100 Subject: Towards a JSON API for the JDK In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Message-ID: Hi Paul, I like the emphasis on minimality, and extensibility of the proposed API. One comment/question is why the API choses to expose Json arrays and objects as List/Maps respectively, instead of e.g. providing accessor to the object members/array elements. E.g. it seems to me that creating a Map from a JSON object is a potentially expensive operation (although perhaps maybe an implementor could implement some kind of lazy list/map under the hood). If the "minimal" contract only required basic element (for arrays) or key/val (for objects) accessors, perhaps this will might leave more room for implementors to support such accessors as they see fit? And we could still have default methods which could use the accessor to provide a List/Map view of the json array/object. Cheers Maurizio On 15/05/2025 21:30, Paul Sandoz wrote: > Hi, > > We would like to share with you our thoughts and plans towards a JSON API for the JDK. > Please see the document below. > > - > > We have had the pleasure of using a clone of this API in some experiments we are conducting with > ONNX and code reflection [1]. Using the API we were able to quickly write code to ingest and convert > a JSON document representing ONNX operation schema into instances of records modeling the schema > (see here [2]). > > The overall out-of-box experience with such a minimal "batteries included? API has so far been positive. > > Thanks, > Paul. > > [1] https://openjdk.org/projects/babylon/ > [2] https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87 > > # Towards a JSON API for the JDK > > One of the most common requests for the JDK is an API for parsing and generating > JSON. While JSON originated as a text-based serialization format for JSON > objects ("JSON" stands for "JavaScript Object Notation"), because of its simple > and flexible syntax, it eventually found use outside the JavaScript ecosystem as > a general data interchange format, such as framework configuration files and web > service requests/response formats. > > While the JDK cannot, and should not, provide libraries for every conceivable > file format or protocol, the JDK philosophy is one of "batteries included", > which is to say we should be able to write basic programs that use common > protocols such as HTTP, without having to appeal to third party libraries. > The Java ecosystem already has plenty of JSON libraries, so inclusion in > the JDK is largely meant to be a convenience, rather than needing to be the "one > true" JSON library to meet the needs of all users. Users with specific needs > are always free to select one of the existing third-party libraries. > > ## Goals and requirements > > Our primary goal is that the library be simple to use for parsing, traversing, > and generating conformant JSON documents. Advanced features, such as data > binding or path-based traversal should be possible to implement as layered > features, but for simplicity are not included in the core API. We adopt a goal > that the performance should be "good enough", but where performance > considerations conflict with simplicity and usability, we will choose in favor > of the latter. > > ## API design approach > > The description of JSON at `https:://json.org` describes a JSON document using > the familiar "railroad diagram": > ![image](https://www.json.org/img/value.png) > > This diagram describes an algebraic data type (a sum of products), which we > model directly with a set of Java interfaces: > > ``` > interface JsonValue { } > interface JsonArray extends JsonValue { List values(); } > interface JsonObject extends JsonValue { Map members(); } > interface JsonNumber extends JsonValue { Number toNumber(); } > interface JsonString extends JsonValue { String value(); } > interface JsonBoolean extends JsonValue { boolean value(); } > interface JsonNull extends JsonValue { } > ``` > > These interfaces have (hidden) companion implementation classes that admit > greater flexibility of implementation than modeling them directly with records would permit. > Further, these interfaces are unsealed. We compromise on the sealed sum of products to enable > alternative implementations, for example to support alternative formats that > encode the same information in a JSON document but in a more efficient form than > text. > > The API has static methods for parsing strings into a `JsonValue`, conversion to > and from purely untyped representations (lists and maps), and factory methods > for building JSON documents. We apply composition consistently, e.g, a > JsonString has a string, a JsonObject has a map of string to JsonValue, as > opposed to extension for structural JSON values. > > It turns out that this simple API is almost all we need for traversal. It gives > us an immutable representation of a document, and we can use pattern matching to > answer the myriad questions that will come up (Does this object have key X? Does > it map to a number? Is that number representable as an integer?) when going > from an untyped format like JSON to a more strongly typed domain model. > Given a simple document like: > > ``` > { > "name": "John?, > "age": 30 > } > ``` > > we can parse and traverse the document as follows: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject o > && o.members().get("name") instanceof JsonString s > && s.value() instanceof String name > && o.members().get("age") instanceof JsonNumber n > && n.toNumber() instanceof Long l && l instanceof int age) { > // use "name" and "age" > } > ``` > > Later, when the language acquires the ability to expose deconstruction patterns > for arbitrary interfaces (similar to today's record patterns, see > https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns), > this will be simplifiable to: > > ``` > JsonValue doc = Json.parse(inputString); > if (doc instanceof JsonObject(var members) > && members.get("name") instanceof JsonString(String name) > && members.get("age") instanceof JsonNumber(int age)) { > // use "name" and "age" > } > ``` > > So, overtime, as more pattern matching features are introduced we anticipate > improved use of the API. This is a primary reason why the API is so minimal. > Convenience methods we add today, such as a method that accesses a JSON > object component as say a JSON string or throws an exception, will become > redundant in the future. > > ## JSON numbers > > The specification of JSON number makes no explicit distinction between integral > and decimal numbers, nor specifies limits on the size of those numbers. > This is a common source of interoperability issues when consuming JSON > documents. Generally users cannot always but often do assume JSON numbers are > parsable, without loss of precision, to IEEE double-precision floating point > numbers or 32-bit signed integers. > > In this respect the API provides three means to operate on the JSON number, > giving the user full control: > > 1. Underlying string representation can be obtained, if preserving syntactic > details such as leading or trailing zeros is important. > 2. The string representation can be parsed to an instance of `BigDecimal`, using > `toBigDecimal` if preserving decimal numbers is important. > 3. The string representation can be parsed into an instance of `Long`, `Double`, > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method > depends on how the representation can be parsed, possibly losing precision, > choosing a suitably convenient numeric type that can then be pattern > matched on. > > Primitive pattern matching will help as will further pattern matching features > enabling the user to partially match. > > ## Prototype implementation > > The prototype implementation is currently located into the JDK sandbox > repository > under the `json` branch, see > here https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json > The prototype API javadoc generated from the repository is also available at > https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html > > ### Testing and conformance > > The prototype implementation passes all conformance test cases but two, available > on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which the > prototype specifically prohibits, i.e, duplicated names in JSON objects > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35). > > ### Performance > > Our main focus so far has been on the API design and a functional implementation. > Hence, there has been less focus on performance even though we know there are a > number of performance enhancements we can make eventually. > We are reasonably happy with the current performance. The > implementation performs well when compared to other JSON implementations > parsing from string instances and traversing documents. > > An example of where we may choose simplicity and usability over performance > is the rejection of JSON documents containing objects that in turn contain members > with duplicate names. That may increase the cost of parsing, but simplifies the user > experience for the majority of cases since if we reasonably assume JsonObjects are > map-like, what should the user do with such members, pick one the last one? merge > the values? or reject? > > ## A JSON JEP? > > We plan to draft JEP when we are ready. Attentive readers will observe that > a JEP already exists, JEP 198: Light-Weight JSON API (https://openjdk.org/jeps/198). We will > either update this JEP, or withdraw it and draft a new one. From duke at openjdk.org Wed May 21 16:25:57 2025 From: duke at openjdk.org (kieran-farrell) Date: Wed, 21 May 2025 16:25:57 GMT Subject: Withdrawn: 8347027: String replaceAll with Function In-Reply-To: References: Message-ID: <1u_ZQV3AZ1ddh-tvh_aS1VVW8hIKj3UL_veHH6uc5tc=.6feb9cd2-16ae-415c-9ff3-ebc2d822cc61@github.com> On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell wrote: > New API to the String.java class - replaceAllMapped(String, Function) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25335 From paul.sandoz at oracle.com Wed May 21 16:29:37 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 21 May 2025 16:29:37 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Message-ID: I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We would need to explore this area throughly, which includes the interconnection with Serialization 2.0, before we really know what we can and should do in the near and long term. That?s a significant effort, and I would like to separate it out from the non-trivial effort to first get a rather modest API over the line. Paul. > On May 21, 2025, at 12:55?AM, Cay Horstmann wrote: > So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier. From jpai at openjdk.org Wed May 21 16:35:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 16:35:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 15:49:29 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Mismatched order is considered invalid src/jdk.jartool/share/man/jar.md line 106: > 104: overwriting (replacing) earlier copies unless -k is specified. > 105: > 106: `-d` or `--describe-module` I'm going to start with some trivial nits and other review comments. The copyright year on this file will need a update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100728423 From asemenyuk at openjdk.org Wed May 21 16:36:31 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 16:36:31 GMT Subject: Integrated: 8357478: Fix copyright header in src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java Message-ID: Add a missing line to the copyright header ------------- Commit messages: - 8357478: Fix copyright header in src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java Changes: https://git.openjdk.org/jdk/pull/25362/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25362&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357478 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25362.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25362/head:pull/25362 PR: https://git.openjdk.org/jdk/pull/25362 From jpai at openjdk.org Wed May 21 16:36:31 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 16:36:31 GMT Subject: Integrated: 8357478: Fix copyright header in src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java In-Reply-To: References: Message-ID: On Wed, 21 May 2025 16:26:39 GMT, Alexey Semenyuk wrote: > Add a missing line to the copyright header The change looks correct and trivial to me. Thank you Alexey. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25362#pullrequestreview-2858443207 From asemenyuk at openjdk.org Wed May 21 16:36:31 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 16:36:31 GMT Subject: Integrated: 8357478: Fix copyright header in src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java In-Reply-To: References: Message-ID: On Wed, 21 May 2025 16:26:39 GMT, Alexey Semenyuk wrote: > Add a missing line to the copyright header This pull request has now been integrated. Changeset: 6546de1d Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/6546de1d3adb8c4755950ee6fb858ec9ee1c5294 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8357478: Fix copyright header in src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/25362 From jpai at openjdk.org Wed May 21 16:44:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 16:44:58 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 15:49:29 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Mismatched order is considered invalid src/jdk.jartool/share/man/jar.md line 110: > 108: > 109: `--validate` > 110: : Validate the contents of the jar archive. Validate the contents of the JAR file. src/jdk.jartool/share/man/jar.md line 111: > 109: `--validate` > 110: : Validate the contents of the jar archive. > 111: See `Integrity of a jar Archive` section below for more details. In recent times, both in code and in API specification, we have been using `JAR` and `ZIP` (upper case) to refer to the JAR/ZIP files. For the tool itself, using the lower case jar is appropriate. Furthermore, JAR itself means Java archive, so I think we can remove the "Archive" word from that sentence. Perhaps this (and the corresponding section) should be "Integrity of a JAR file". src/jdk.jartool/share/man/jar.md line 221: > 219: > 220: ## Integrity of a jar Archive > 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools Nit - As a JAR file is based on ZIP format, it is possible to create a JAR file ... src/jdk.jartool/share/man/jar.md line 223: > 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools > 222: other than the `jar` command. The --validate option may be used to perform the following > 223: integrity checks against a jar archive: Nit - "integrity checks against a JAR file:" src/jdk.jartool/share/man/jar.md line 225: > 223: integrity checks against a jar archive: > 224: > 225: - That there are no duplicate Zip Entry file names Nit - "... ZIP entry file names" src/jdk.jartool/share/man/jar.md line 226: > 224: > 225: - That there are no duplicate Zip Entry file names > 226: - Verify that the Zip Entry file name: Nit - ".... ZIP entry file name:" src/jdk.jartool/share/man/jar.md line 237: > 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise > 236: a non-zero status code would be returned. > 237: When an integrity issue is reported, it will often require that the jar file is re-created by the Nit - "... require that the JAR file is re-created by the original source of the JAR file." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100734549 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100733984 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100742813 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100743231 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100736667 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100737171 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100740992 From jpai at openjdk.org Wed May 21 16:48:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 16:48:56 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 15:49:29 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Mismatched order is considered invalid src/jdk.jartool/share/man/jar.md line 235: > 233: versions. > 234: > 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100748899 From naoto at openjdk.org Wed May 21 16:50:12 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 16:50:12 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v3] In-Reply-To: References: Message-ID: > `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting further comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25271/files - new: https://git.openjdk.org/jdk/pull/25271/files/ec420654..dd370768 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=01-02 Stats: 22 lines in 2 files changed: 9 ins; 7 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271 PR: https://git.openjdk.org/jdk/pull/25271 From jpai at openjdk.org Wed May 21 16:55:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 16:55:53 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com> On Wed, 21 May 2025 15:49:29 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Mismatched order is considered invalid src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454: > 452: new FileInputStream(file)))) { > 453: > 454: return Validator.validate(this, zf, zis); I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate. The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem. It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100761422 From naoto at openjdk.org Wed May 21 16:57:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 16:57:52 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2] In-Reply-To: References: Message-ID: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com> On Wed, 21 May 2025 06:12:18 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflects review comments > > src/java.base/share/classes/java/io/Console.java line 67: > >> 65: * stdout.encoding}, in which case read operations use the {@code Charset} >> 66: * designated by {@code stdin.encoding}. >> 67: *

      > > `Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well. Good point. Brought the same wording to the `charset()` method description for further clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100752794 From naoto at openjdk.org Wed May 21 16:57:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 16:57:52 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 08:20:50 GMT, Volkan Yazici wrote: >> JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR > > Created jline/jline3#1282. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100753459 From naoto at openjdk.org Wed May 21 16:57:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 16:57:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v3] In-Reply-To: <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com> References: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com> <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com> Message-ID: On Wed, 21 May 2025 08:30:26 GMT, Volkan Yazici wrote: >> `stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java` > > Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none1 that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too. > > For the record, AFAICT, there are no tests for `stderr.encoding`. > > 1 There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`. Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100762324 From naoto at openjdk.org Wed May 21 16:57:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 16:57:54 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v3] In-Reply-To: References: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com> <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com> Message-ID: On Wed, 21 May 2025 16:53:53 GMT, Naoto Sato wrote: >> Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none1 that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too. >> >> For the record, AFAICT, there are no tests for `stderr.encoding`. >> >> 1 There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`. > > Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input). > There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding. It is addressed in this PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100763095 From archie.cobbs at gmail.com Wed May 21 17:03:12 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 21 May 2025 12:03:12 -0500 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Message-ID: On Wed, May 21, 2025 at 11:30?AM Paul Sandoz wrote: > I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We would > need to explore this area throughly, which includes the interconnection > with Serialization 2.0, before we really know what we can and should do in > the near and long term. That?s a significant effort, and I would like to > separate it out from the non-trivial effort to first get a rather modest > API over the line. I think the discussions about object mapping and serialization are important and super interesting, but as Paul points out, not really an immediate concern wrt. this proposal. In trying to understand this discussion, there are so many different concepts stirred up it's hard to keep track. It was helpful for me to go through the exercise of trying to partition the discussion space. Below is my feeble attempt at that... Side note: for better or worse, there are lots of parallels here with XML, so I expect the solutions to parallel the XML solutions, for many of the same reasons. We should also avoid parallelling the mistakes (e.g., including too much functionality in the JDK which gets stale over time). Q1: What is JSON? Just like XML, it's a specification for structured documents. By "structured" we mean the syntax implies a nested tree-like structure (by "document" we mean "file" or "streams of bytes"). Q2: What do people want to do with JSON? 1. Model a JSON document as Java objects in memory (using a "document object model" or DOM). Analogy: org.w3c.dom 2. Convert JSON DOM objects (see #1) to/from JSON documents. Analogy: {javax,jakarta}.xml.{parsers,transform} 3. Transform JSON documents. Analogy {javax,jakarta}.xml.transform 4. Read/write normal Java objects to/from JSON ("object mapping"). Analogy: {javax,jakarta}.xml.bind (JAXB), JiBX 5. Read/write normal Java objects, where JSON is one possible encoding ("serialization 2.0"). Analogy: java.beans.XMLEncoder (!?) To me these are mostly separate problems whose solutions can be solved separately, each building on the previous (analogous to what was done with XML). So what problem is this new API trying to solve? Just #1 and #2. Of course, you probably want to use the solutions to problem 1 and 2 in your solution to problems 3, 4, and 5. But let's respect the ordering here. In solving problems 1 and 2, we should focus on those problems only. The solution to problems 1 and 2, if done well, will automatically be a good foundation for solving problems 3, 4, and 5, etc. -Archie P.S. I'm interested in "serialization 2.0" too - and that discussion must be happening somewhere else... where? -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed May 21 17:06:38 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 21 May 2025 17:06:38 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Message-ID: It was a design choice to be consistent with each json value having an X, accepting X in on construction and producing X out (notionally) on deconstruction, which leans into pattern matching. Definitely pros/cons to that e.g., we could instead make JonObject implement Map, or do as you suggest [*], both of which adjust how one reasons about the X in and X out. I would prefer to mostly drive the API design from user ergonomics with pattern matching rather than what is easier for implementations. It?s definitely possible for implementations to optimize (as you posit, such as a concrete implementation extending from Map with a custom implementation), and there is room for improvement in the current implementation we should explore. Paul. [*] Although I don?t think we can avoid exposing collection like semantics, since it requires iteration to produce the Map containing all the entries from a default method, so might as well expose Map directly. > On May 21, 2025, at 9:01?AM, Maurizio Cimadamore wrote: > > Hi Paul, > I like the emphasis on minimality, and extensibility of the proposed API. > > One comment/question is why the API choses to expose Json arrays and objects as List/Maps respectively, instead of e.g. providing accessor to the object members/array elements. > > E.g. it seems to me that creating a Map from a JSON object is a potentially expensive operation (although perhaps maybe an implementor could implement some kind of lazy list/map under the hood). > > If the "minimal" contract only required basic element (for arrays) or key/val (for objects) accessors, perhaps this will might leave more room for implementors to support such accessors as they see fit? And we could still have default methods which could use the accessor to provide a List/Map view of the json array/object. > > Cheers > Maurizio From liach at openjdk.org Wed May 21 17:09:29 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 17:09:29 GMT Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently [v2] In-Reply-To: References: Message-ID: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com> > The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail. > > Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well. > > Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Increase timeout, add comment for adjust for debugging - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cv-test-problems - Restore incorrectly removed annotation - Fix problems with class value tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25292/files - new: https://git.openjdk.org/jdk/pull/25292/files/792d683e..68a13bb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25292&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25292&range=00-01 Stats: 36448 lines in 506 files changed: 23222 ins; 10278 del; 2948 mod Patch: https://git.openjdk.org/jdk/pull/25292.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25292/head:pull/25292 PR: https://git.openjdk.org/jdk/pull/25292 From jpai at openjdk.org Wed May 21 17:15:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 17:15:53 GMT Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently [v2] In-Reply-To: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com> References: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com> Message-ID: <2OGd66LXxsHPfRwtqXtnxc7bwfqZMKlTOXhJeznKAb8=.cdafe4a6-4976-4319-9b9a-a5515d91972c@github.com> On Wed, 21 May 2025 17:09:29 GMT, Chen Liang wrote: >> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail. >> >> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well. >> >> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Increase timeout, add comment for adjust for debugging > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cv-test-problems > - Restore incorrectly removed annotation > - Fix problems with class value tests The update to increase the timeout to 1 minute * timeout factor, looks good to me. I'm not too familiar with the bug that's requiring the `testWeakAgainstClassValue()` method to be updated, but if that helps with the test failures then it seems reasonable to fix it. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25292#pullrequestreview-2858558310 From paul.sandoz at oracle.com Wed May 21 17:17:00 2025 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 21 May 2025 17:17:00 +0000 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Message-ID: Thank you Archie, nicely expressed. The discussions in this thread will help us write a crisper set of goals/non-goals and a clearer motivation for the to-be-written JEP. Paul. On May 21, 2025, at 10:03?AM, Archie Cobbs wrote: On Wed, May 21, 2025 at 11:30?AM Paul Sandoz > wrote: I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We would need to explore this area throughly, which includes the interconnection with Serialization 2.0, before we really know what we can and should do in the near and long term. That?s a significant effort, and I would like to separate it out from the non-trivial effort to first get a rather modest API over the line. I think the discussions about object mapping and serialization are important and super interesting, but as Paul points out, not really an immediate concern wrt. this proposal. In trying to understand this discussion, there are so many different concepts stirred up it's hard to keep track. It was helpful for me to go through the exercise of trying to partition the discussion space. Below is my feeble attempt at that... Side note: for better or worse, there are lots of parallels here with XML, so I expect the solutions to parallel the XML solutions, for many of the same reasons. We should also avoid parallelling the mistakes (e.g., including too much functionality in the JDK which gets stale over time). Q1: What is JSON? Just like XML, it's a specification for structured documents. By "structured" we mean the syntax implies a nested tree-like structure (by "document" we mean "file" or "streams of bytes"). Q2: What do people want to do with JSON? 1. Model a JSON document as Java objects in memory (using a "document object model" or DOM). Analogy: org.w3c.dom 2. Convert JSON DOM objects (see #1) to/from JSON documents. Analogy: {javax,jakarta}.xml.{parsers,transform} 3. Transform JSON documents. Analogy {javax,jakarta}.xml.transform 4. Read/write normal Java objects to/from JSON ("object mapping"). Analogy: {javax,jakarta}.xml.bind (JAXB), JiBX 5. Read/write normal Java objects, where JSON is one possible encoding ("serialization 2.0"). Analogy: java.beans.XMLEncoder (!?) To me these are mostly separate problems whose solutions can be solved separately, each building on the previous (analogous to what was done with XML). So what problem is this new API trying to solve? Just #1 and #2. Of course, you probably want to use the solutions to problem 1 and 2 in your solution to problems 3, 4, and 5. But let's respect the ordering here. In solving problems 1 and 2, we should focus on those problems only. The solution to problems 1 and 2, if done well, will automatically be a good foundation for solving problems 3, 4, and 5, etc. -Archie P.S. I'm interested in "serialization 2.0" too - and that discussion must be happening somewhere else... where? -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed May 21 17:25:17 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 May 2025 18:25:17 +0100 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> Message-ID: <0e31ed85-25e7-44aa-903c-ceae80272c60@oracle.com> On 21/05/2025 18:06, Paul Sandoz wrote: > It was a design choice to be consistent with each json value having an > X, accepting X in on construction and producing X out (notionally) on > deconstruction, which leans into pattern matching. Definitely pros/cons > to that e.g., we could instead make JonObject implement Map, or do as > you suggest [*], both of which adjust how one reasons about the X in and > X out. I agree with this. When I wrote, I thought that it might be possible to address some of these use cases using instance pattern declaration on the array class (e.g. having an instance pattern that extracts the i-th element of a JSONArray) -- but the instance pattern proposals we have discussed so far [1] are not powerful enough to model that use case. Maurizio [1] - https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns -------------- next part -------------- An HTML attachment was scrubbed... URL: From plevart at openjdk.org Wed May 21 17:26:54 2025 From: plevart at openjdk.org (Peter Levart) Date: Wed, 21 May 2025 17:26:54 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev wrote: >> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max specifications. >> >> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Return first argument in case of tie (to be consistent with BinaryOperator); junit tests Hi, There exists a class implementing Comparator and min and max methods too. But they are generic: https://github.com/google/guava/blob/f1b962f1f1d1c96068c62b7ff55426ea249cbd55/guava/src/com/google/common/collect/Ordering.java#L622C10-L622C79 public E max(E a, E b) { return (compare(a, b) >= 0) ? a : b; } So when I have: Comparator cmp = ... var greatest = cmp.max("foo", "bar"); ...then the type of `greatest` would be `String` and not `CharSequence`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2898707140 From jiangli at openjdk.org Wed May 21 17:27:52 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 21 May 2025 17:27:52 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: References: Message-ID: <68OItsB8gIJK4njZ1FkN-gX4iFw6JW92wjfOUlD2LxQ=.aff91b03-56c7-4dd6-baac-bf337b02baff@github.com> On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou wrote: >> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description: >> >> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. Still need a (R)eviewer. @AlanBateman, @jerboaa, or @dholmes-ora Could one of you help review/approve? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/25220#issuecomment-2898711067 From jpai at openjdk.org Wed May 21 17:31:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 17:31:55 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 15:49:29 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Mismatched order is considered invalid src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 119: > 117: * element is not equal to "." or ".." > 118: * > 119: * @param entryName CEN/LOC header file name field entry Nit - `@param entryName ZIP entry name` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100821550 From jvernee at openjdk.org Wed May 21 18:02:05 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 21 May 2025 18:02:05 GMT Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov wrote: > Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2858676969 From jlu at openjdk.org Wed May 21 18:09:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 21 May 2025 18:09:52 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v3] In-Reply-To: References: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com> <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com> Message-ID: On Wed, 21 May 2025 16:54:22 GMT, Naoto Sato wrote: >> Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input). > >> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding. > > It is addressed in this PR I think the JBS bug ID needs to be added to `CharsetTest.java` as well then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100890130 From rriggs at openjdk.org Wed May 21 18:48:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 18:48:52 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou wrote: >> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description: >> >> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25220#pullrequestreview-2858791041 From rriggs at openjdk.org Wed May 21 18:51:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 18:51:55 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev wrote: >> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max specifications. >> >> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Return first argument in case of tie (to be consistent with BinaryOperator); junit tests Looks good. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-2858798359 From duke at openjdk.org Wed May 21 18:55:53 2025 From: duke at openjdk.org (Abhishek N) Date: Wed, 21 May 2025 18:55:53 GMT Subject: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() [v2] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:50:35 GMT, Justin Lu wrote: >> Abhishek N has updated the pull request incrementally with one additional commit since the last revision: >> >> correcting jtreg header order, add meaningful comments for each test methods and properties file > > This test is not effectively testing standard ISO 4217 future transition currencies. For example, with your patch, if I supply the following changes to the ISO 4217 currency data: > (i.e. Make country `LK` have a transition currency of `XCH` in July) > > > --- a/src/java.base/share/data/currency/CurrencyData.properties > +++ b/src/java.base/share/data/currency/CurrencyData.properties > @@ -55,7 +55,7 @@ all=ADP020-AED784-AFA004-AFN971-ALL008-AMD051-ANG532-AOA973-ARS032-ATS040-AUD036 > SRD968-SRG740-SSP728-STD678-STN930-SVC222-SYP760-SZL748-THB764-TJS972-TMM795-TMT934-TND788-TOP776-\ > TPE626-TRL792-TRY949-TTD780-TWD901-TZS834-UAH980-UGX800-USD840-USN997-USS998-UYI940-\ > UYU858-UZS860-VEB862-VED926-VEF937-VES928-VND704-VUV548-WST882-XAF950-XAG961-XAU959-XBA955-\ > - XBB956-XBC957-XBD958-XCD951-XCG532-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\ > + XBB956-XBC957-XBD958-XCD951-XCG532-XCH533-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\ > XPT962-XSU994-XTS963-XUA965-XXX999-YER886-YUM891-ZAR710-ZMK894-ZMW967-ZWD716-ZWG924-\ > ZWL932-ZWN942-ZWR935 > > @@ -502,7 +502,7 @@ GS=GBP > # SPAIN > ES=EUR > # SRI LANKA > -LK=LKR > +LK=LKR;2025-07-01-04-00-00;XCH > > > and break some functionality related to _future/special_ currencies in `Currency.getInstance(String)`, > (Similar to 8, prior to the fix backported) > > > --- a/src/java.base/share/classes/java/util/Currency.java > +++ b/src/java.base/share/classes/java/util/Currency.java > @@ -326,13 +326,6 @@ private static Currency getInstance(String currencyCode, int defaultFractionDigi > defaultFractionDigits = (tableEntry & SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_MASK) >> SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_SHIFT; > numericCode = (tableEntry & NUMERIC_CODE_MASK) >> NUMERIC_CODE_SHIFT; > found = true; > - } else { //special case > - int[] fractionAndNumericCode = SpecialCaseEntry.findEntry(currencyCode); > - if (fractionAndNumericCode != null) { > - defaultFractionDigits = fractionAndNumericCode[0]; > - numericCode = fractionAndNumericCode[1]; > - found = true; > - } > } > > > With the above changes, we would expect this test to fail, since `getInstance("XCH")` should throw an exception. However, your test still passes. What this patch is doing is selectively testing a handful of Currencies with the system property override. This is not sufficient to ensure test coverage for testing a standard ISO 4217 tran... @justin-curtis-lu @weibxiao Our objective is to ensure the proper functionality of the Currency.getInstance() methods?particularly to guarantee that currencies defined with special conditions (such as future cutover dates) will work correctly once the system date passes those thresholds. For example, in the case of the mapping: LK=LKR;2025-07-01-04-00-00;XCH we want to ensure that, once the system date passes 2025-07-01T04:00:00, both Currency.getInstance("XCH") and Currency.getInstance(new Locale("LK")) will work as expected and not throw an IllegalArgumentException. To facilitate this, we use a custom currency.properties file that includes entries for currencies with such special conditions, where the cutover date has already passed. An example entry would be: BI=BFI,108,0,2022-12-15T04:00:00 Without this customization, in earlier JDK versions (which do not include recent fixes), calling Currency.getInstance("BFI") would result in an IllegalArgumentException and issues such as JDK-8353433 would have been caught in earlier stages itself. Including these entries allows us to surface such issues earlier in the development or testing lifecycle. **The test in mainline utilize the ClassFile API for mocking system time (such as System::currentTimeMillis), the ClassFile API is not supported in lower LTS JDK versions. Therefore, we rely on the custom currency properties approach to simulate post-cutover behavior for those environments.** **Since additional currencies with similar cutover rules may be introduced in the future, our approach ensures that Currency.getInstance() continues to function reliably across all supported LTS JDK versions?even before the actual cutover date is reached?by validating currency data early using the custom CurrencyData.properties..** ------------- PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2898918478 From jiangli at openjdk.org Wed May 21 18:58:56 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 21 May 2025 18:58:56 GMT Subject: Integrated: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk In-Reply-To: References: Message-ID: On Tue, 13 May 2025 21:28:00 GMT, Jiangli Zhou wrote: > Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description: > > jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. This pull request has now been integrated. Changeset: 400c9350 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/400c935082a0d4d843cf369af6fefde12d637438 Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk Reviewed-by: henryjen, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/25220 From jiangli at openjdk.org Wed May 21 18:58:55 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 21 May 2025 18:58:55 GMT Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 18:46:25 GMT, Roger Riggs wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java. > > lgtm @RogerRiggs Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25220#issuecomment-2898926876 From vklang at openjdk.org Wed May 21 19:04:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 21 May 2025 19:04:58 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v5] In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> References: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> Message-ID: On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) wrote: >> Motivation: >> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. >> >> Modification: >> Add detail error messages. >> >> Result: >> Helpful messages. > > He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang Thanks for your work here, @He-Pin ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23050#pullrequestreview-2858828972 From liach at openjdk.org Wed May 21 19:09:03 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 19:09:03 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v5] In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> References: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> Message-ID: On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) wrote: >> Motivation: >> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. >> >> Modification: >> Add detail error messages. >> >> Result: >> Helpful messages. > > He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang Looks good, though I would relax the check on messages to just include the offending variable names to ensure compatible evolution. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23050#pullrequestreview-2858837437 From rriggs at openjdk.org Wed May 21 19:13:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 19:13:53 GMT Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe wrote: > Hi, please consider the following patch. > > This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc. > > This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens). > > Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409 > > This patch also fixes two subtle bugs: > - we didn't check the return value of the close() inside closeAllFileDescriptors > - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it) > > ---- > > Testing: > > We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC. > > - in the parent JVM, the test opens a file in native code without FD_CLOEXEC > - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open > > I verified that the test correctly detects a broken implementation that leaks file descriptors. > > I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX). > > I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green. Looks good ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25301#pullrequestreview-2858850942 From bpb at openjdk.org Wed May 21 19:18:03 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 21 May 2025 19:18:03 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v25] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com> > Implement the requested methods and add a test thereof. Brian Burkhalter 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 29 additional commits since the last revision: - 8354724: Update API notes - Merge - 8354724: Revert previous commit and remove first comma in the change - 8354724: Improve verbiage about I/O errors - 8354724: Replace getChars in previous commit with subSequence - 8354724: Improve readAllAsString method of Reader returned by Reader.of - 8354724: Change readAllCharsAsString as suggested; move test to proper location - 8354724: "stream" -> "reader" - 8354724: Attempt to further improve verbiage - Merge - ... and 19 more: https://git.openjdk.org/jdk/compare/bcf1bca6...f9c732eb ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/0880af29..f9c732eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=23-24 Stats: 66091 lines in 1204 files changed: 34984 ins; 23883 del; 7224 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From plevart at openjdk.org Wed May 21 19:22:52 2025 From: plevart at openjdk.org (Peter Levart) Date: Wed, 21 May 2025 19:22:52 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: References: Message-ID: <38y18L1eSJAGuzFgH8xAn38k_Xu8pqueLhYYIEAzz8M=.bd30476b-e887-414a-8f03-f3f26c78f66b@github.com> On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev wrote: >> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max specifications. >> >> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Return first argument in case of tie (to be consistent with BinaryOperator); junit tests What I was trying to say is that not only would Guava's Ordering not compile any more (it would still be binary compatible I think, as both methods have same erasure), but I also think that generic max and min as defined by Guava's Ordering are more useful too. So what do you think of making them generic like this: default E max(E e1, E e2) { return compare(e1, e2) >= 0 ? e1 : e2; } default E min(E e1, E e2) { return compare(e1, e2) <= 0 ? e1 : e2; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2898984302 From mikael at openjdk.org Wed May 21 19:27:55 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 21 May 2025 19:27:55 GMT Subject: RFR: 8357173: Split jtreg test group jdk tier3 [v2] In-Reply-To: References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com> Message-ID: On Wed, 21 May 2025 13:53:37 GMT, Erik Joelsson wrote: >> We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split. > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - grammar > - Clarified the group split with comments Marked as reviewed by mikael (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25274#pullrequestreview-2858888804 From naoto at openjdk.org Wed May 21 19:29:08 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 19:29:08 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v4] In-Reply-To: References: Message-ID: > `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: CharsetTest clean-up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25271/files - new: https://git.openjdk.org/jdk/pull/25271/files/dd370768..ce1c8035 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=02-03 Stats: 8 lines in 1 file changed: 1 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271 PR: https://git.openjdk.org/jdk/pull/25271 From naoto at openjdk.org Wed May 21 19:29:08 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 19:29:08 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v4] In-Reply-To: References: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com> <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com> Message-ID: On Wed, 21 May 2025 18:07:39 GMT, Justin Lu wrote: >>> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding. >> >> It is addressed in this PR > > I think the JBS bug ID needs to be added to `CharsetTest.java` as well then. Bugid added to the test. Additionally replaced testsrc/jdk/classes with Utils ones ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2101014981 From rriggs at openjdk.org Wed May 21 19:29:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 19:29:55 GMT Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v8] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 00:57:30 GMT, Shaojin Wen wrote: >> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix comments, from @j3graham Looks good. Thanks for the detailed comments and vectorized hex to string conversion. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22928#pullrequestreview-2858893329 From almatvee at openjdk.org Wed May 21 19:35:55 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 19:35:55 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 12:41:24 GMT, Stefan Lobbenmeier wrote: >> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space >> >> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 > > Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: > > also use in other locations src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298: > 296: \ --linux-menu-group \n\ > 297: \ Menu group this application is placed in\n\ > 298: \ --linux-package-deps\n\ I am not familiar with this CLI option, but if it is "dependency list separated by comma and space", then it should be documented. Similar to `--add-modules`. Also, why we need `space` as well? For example: \ --linux-package-deps \n\ \ A comma (",") separated list of required packages or capabilities for the application\n\ or if space is really needed: \ --linux-package-deps \n\ \ A comma and space (", ") separated list of required packages or capabilities for the application\n\ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101024107 From lancea at openjdk.org Wed May 21 19:38:54 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 21 May 2025 19:38:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 16:45:51 GMT, Jaikiran Pai wrote: > Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes. I don't have a preference but unix/MacOS commands vary: - ls command: The ls utility exits?0 on success, and?>0 if an error occurs. - grep command: > The grep utility exits with one of the following values: 0 One or more lines were selected. 1 No lines were selected. >1 An error occurred. - unzip command: > The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the following values, except under VMS: 0 normal; no errors or warnings detected. 1 one or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles where one or more files was skipped due to unsupported compression method or encryption with an unknown password. 2 a generic error in the zipfile format was detected. Processing may have completed successfully anyway; some broken zipfiles created by other archivers have simple work- arounds. 3 a severe error in the zipfile format was detected. Processing probably failed immediately. 4 unzip was unable to allocate memory for one or more buffers during program initialization. 5 unzip was unable to allocate memory or unable to obtain a tty to read the decryption password(s). 6 unzip was unable to allocate memory during decompression to disk. 7 unzip was unable to allocate memory during in-memory decompression. 8 [currently not used] 9 the specified zipfiles were not found. 10 invalid options were specified on the command line. 11 no matching files were found. 50 the disk is (or was) full during extraction. 51 the end of the ZIP archive was encountered prematurely. 80 the user aborted unzip prematurely with control-C (or similar) 81 testing or extraction of one or more files failed due to unsupported compression methods or unsupported decryption. 82 no files were found due to bad decryption password(s). (If even one file is successfully processed, however, the exit status is 1.) So perhaps something along the lines of > The jar tool exits with a status of 0 if there were no integrity issues encountered and >0 if an error/warning occurred ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101029665 From almatvee at openjdk.org Wed May 21 19:41:57 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 19:41:57 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3] In-Reply-To: References: <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com> <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com> Message-ID: On Wed, 21 May 2025 12:03:16 GMT, Alexey Semenyuk wrote: >> As in, this worked in my testing: `--linux-package-deps "foo, bar"`, see https://github.com/JetBrains/compose-multiplatform/pull/5227#issuecomment-2659470908 > >> As in, this worked in my testing: --linux-package-deps "foo, bar" > > Of course. You can put any string for `--linux-package-deps` option, jpackage will pass it as-is to the underlying tool. Unlike, e.g. `--arguments`, for which jpackage will tokenize the value into a string array. I think we should document that jpackage will pass value as-is similar to `--mac-app-image-sign-identity`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101032436 From erikj at openjdk.org Wed May 21 19:52:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 May 2025 19:52:56 GMT Subject: Integrated: 8357173: Split jtreg test group jdk tier3 In-Reply-To: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com> References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com> Message-ID: On Fri, 16 May 2025 20:16:02 GMT, Erik Joelsson wrote: > We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split. This pull request has now been integrated. Changeset: afcbf6b2 Author: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/afcbf6b2f49c00a544e6db5b4ed9da76c0bdcba4 Stats: 13 lines in 1 file changed: 11 ins; 1 del; 1 mod 8357173: Split jtreg test group jdk tier3 Reviewed-by: mikael ------------- PR: https://git.openjdk.org/jdk/pull/25274 From ethan at mccue.dev Wed May 21 19:55:18 2025 From: ethan at mccue.dev (Ethan McCue) Date: Wed, 21 May 2025 15:55:18 -0400 Subject: Towards a JSON API for the JDK In-Reply-To: References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr> <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com> <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr> <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr> <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr> <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com> <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr> <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com> <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com> Message-ID: I think you missed a 2.5 which is to use the information in DOM objects to perform useful work. On Wed, May 21, 2025, 1:04?PM Archie Cobbs wrote: > On Wed, May 21, 2025 at 11:30?AM Paul Sandoz > wrote: > >> I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We >> would need to explore this area throughly, which includes the >> interconnection with Serialization 2.0, before we really know what we can >> and should do in the near and long term. That?s a significant effort, and I >> would like to separate it out from the non-trivial effort to first get a >> rather modest API over the line. > > > I think the discussions about object mapping and serialization are > important and super interesting, but as Paul points out, not really an > immediate concern wrt. this proposal. > > In trying to understand this discussion, there are so many different > concepts stirred up it's hard to keep track. It was helpful for me to go > through the exercise of trying to partition the discussion space. Below is > my feeble attempt at that... > > Side note: for better or worse, there are lots of parallels here with XML, > so I expect the solutions to parallel the XML solutions, for many of the > same reasons. We should also avoid parallelling the mistakes (e.g., > including too much functionality in the JDK which gets stale over time). > > Q1: What is JSON? Just like XML, it's a specification for structured > documents. By "structured" we mean the syntax implies a nested tree-like > structure (by "document" we mean "file" or "streams of bytes"). > > Q2: What do people want to do with JSON? > > 1. Model a JSON document as Java objects in memory (using a "document > object model" or DOM). Analogy: org.w3c.dom > > 2. Convert JSON DOM objects (see #1) to/from JSON documents. Analogy: > {javax,jakarta}.xml.{parsers,transform} > > 3. Transform JSON documents. Analogy {javax,jakarta}.xml.transform > > 4. Read/write normal Java objects to/from JSON ("object mapping"). > Analogy: {javax,jakarta}.xml.bind (JAXB), JiBX > > 5. Read/write normal Java objects, where JSON is one possible encoding > ("serialization 2.0"). Analogy: java.beans.XMLEncoder (!?) > > To me these are mostly separate problems whose solutions can be solved > separately, each building on the previous (analogous to what was done with > XML). > > So what problem is this new API trying to solve? Just #1 and #2. > > Of course, you probably want to use the solutions to problem 1 and 2 in > your solution to problems 3, 4, and 5. > > But let's respect the ordering here. In solving problems 1 and 2, we > should focus on those problems only. The solution to problems 1 and 2, if > done well, will automatically be a good foundation for solving problems 3, > 4, and 5, etc. > > -Archie > > P.S. I'm interested in "serialization 2.0" too - and that discussion must > be happening somewhere else... where? > > -- > Archie L. Cobbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Wed May 21 20:16:01 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 20:16:01 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 06:08:37 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Move intrinsic to be a subsection; just one most common function of the annotation >> - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate >> - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate >> - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java >> >> Co-authored-by: Raffaello Giulietti >> - Shorter first sentence >> - Updates, thanks to John >> - Refine validation and defensive copying >> - 8355223: Improve documentation on @IntrinsicCandidate > > src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 39: > >> 37: *

      Intrinsification

      >> 38: * The most frequently special treatment is intrinsification, which replaces a >> 39: * candidate method's body, bytecode or native, with handwritten platform > > Is this sentence missing the word "code" after "native"? Should it have been: > >> bytecode or native code, ... This is referring to native method's bodies. I think "bytecode or native" is sufficient to summarize the executable method body in the Java Language/Virtual Machine Specification. > src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 50: > >> 48: * For example, the bytecodes of a candidate method may be executed by lower >> 49: * compilation tiers of VM execution, while higher compilation tiers may replace >> 50: * the bytecodes with specialized assembly code and/or compiler IR. Therefore, > >> while higher compilation tiers may replace the bytecodes with specialized assembly code and/or compiler IR > > Is there ever a case, where for a `@IntrinsicCandidate` method, the runtime will choose to execute the instrinsic for that method for a certain duration and then at a later point in time replace the intrinsic with compiler generated code? In other words, once the runtime executes the intrinsic implementation for a `@IntrinsicCandidate` method, will the method's implementation be switched to anything else during the lifetime of an application? We cannot rule it out, but this sentence begins "for example" meaning this is just one scenario and is not exhaustive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101082191 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101080051 From duke at openjdk.org Wed May 21 20:20:56 2025 From: duke at openjdk.org (Stefan Lobbenmeier) Date: Wed, 21 May 2025 20:20:56 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 19:33:13 GMT, Alexander Matveev wrote: >> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: >> >> also use in other locations > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298: > >> 296: \ --linux-menu-group \n\ >> 297: \ Menu group this application is placed in\n\ >> 298: \ --linux-package-deps\n\ > > I am not familiar with this CLI option, but if it is "dependency list separated by comma and space", then it should be documented. Similar to `--add-modules`. > > Also, why we need `space` as well? > > For example: > > \ --linux-package-deps \n\ > \ A comma (",") separated list of required packages or capabilities for the application\n\ > > > or if space is really needed: > > \ --linux-package-deps \n\ > \ A comma and space (", ") separated list of required packages or capabilities for the application\n\ I mostly learned about this through trial and error. To me it seems it is just appended to the existing default dependency list, which is separated by space and comma. Haven?t tried omitting the space though and I am unsure where this is defined ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101088895 From lancea at openjdk.org Wed May 21 20:23:58 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 21 May 2025 20:23:58 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 16:42:14 GMT, Jaikiran Pai wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Mismatched order is considered invalid > > src/jdk.jartool/share/man/jar.md line 223: > >> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools >> 222: other than the `jar` command. The --validate option may be used to perform the following >> 223: integrity checks against a jar archive: > > Nit - "integrity checks against a JAR file:" I think we have other inconsistencies that we can clean up at a later time in the help and man page for the jar tool in the usages of archive/file. The man page description can use a further overhaul as we still reference applets. So we can do this also as follow on work ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101097000 From asemenyuk at openjdk.org Wed May 21 20:28:02 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 21 May 2025 20:28:02 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:17:45 GMT, Stefan Lobbenmeier wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298: >> >>> 296: \ --linux-menu-group \n\ >>> 297: \ Menu group this application is placed in\n\ >>> 298: \ --linux-package-deps\n\ >> >> I am not familiar with this CLI option, but if it is "dependency list separated by comma and space", then it should be documented. Similar to `--add-modules`. >> >> Also, why we need `space` as well? >> >> For example: >> >> \ --linux-package-deps \n\ >> \ A comma (",") separated list of required packages or capabilities for the application\n\ >> >> >> or if space is really needed: >> >> \ --linux-package-deps \n\ >> \ A comma and space (", ") separated list of required packages or capabilities for the application\n\ > > I mostly learned about this through trial and error. To me it seems it is just appended to the existing default dependency list, which is separated by space and comma. Haven?t tried omitting the space though and I am unsure where this is defined I assume "dependency list separated by comma and space" is a quote from the PR description. I understand that this is how users interpret the value of this parameter, but for jpackage this is a pass-through option. It can be any string. And it is documented accordingly: Required packages or capabilities for the application It doesn't say anything about the value format because it is irrelevant for jpackage. Probably this is an overly vague description, and we can add details that the value of this parameter will be passed verbatim to rpmbuild or dpkg commands. But this is not what this PR is about. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101102106 From mseledtsov at openjdk.org Wed May 21 20:31:53 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 21 May 2025 20:31:53 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> References: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> Message-ID: <-rGf3Cfj34SX1QlPIp1vyVRWGc67aFxFmbAqNC2iMyo=.d6eaa386-b98f-45e8-8035-94b5cf5f159a@github.com> On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks for the updates. Changes look good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2859031087 From jlu at openjdk.org Wed May 21 20:41:43 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 21 May 2025 20:41:43 GMT Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention conversions made on language tag [v4] In-Reply-To: References: Message-ID: > It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: CSR review - clarify that 3 extlang subtags is not a JDK specific condition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25309/files - new: https://git.openjdk.org/jdk/pull/25309/files/62714a26..1ee830e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=02-03 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309 PR: https://git.openjdk.org/jdk/pull/25309 From ethan at mccue.dev Wed May 21 20:42:04 2025 From: ethan at mccue.dev (Ethan McCue) Date: Wed, 21 May 2025 16:42:04 -0400 Subject: Towards a JSON API for the JDK In-Reply-To: <0e31ed85-25e7-44aa-903c-ceae80272c60@oracle.com> References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com> <0e31ed85-25e7-44aa-903c-ceae80272c60@oracle.com> Message-ID: I think what has been proposed so far is powerful enough to perform that task *if* there is an intermediate object in the mix. if ( // Assuming a dual pattern for JsonString.of and the SAP // strategy outlined in the doc json instanceof index(0, JsonString::of).decode(var firstName) ) { } On Wed, May 21, 2025 at 1:26?PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 21/05/2025 18:06, Paul Sandoz wrote: > > It was a design choice to be consistent with each json value having an > X, accepting X in on construction and producing X out (notionally) on > deconstruction, which leans into pattern matching. Definitely pros/cons > to that e.g., we could instead make JonObject implement Map, or do as > you suggest [*], both of which adjust how one reasons about the X in and > X out. > > I agree with this. When I wrote, I thought that it might be possible to > address some of these use cases using instance pattern declaration on the > array class (e.g. having an instance pattern that extracts the i-th element > of a JSONArray) -- but the instance pattern proposals we have discussed so > far [1] are not powerful enough to model that use case. > > Maurizio > > [1] - > https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns > -------------- next part -------------- An HTML attachment was scrubbed... URL: From almatvee at openjdk.org Wed May 21 20:54:54 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 21 May 2025 20:54:54 GMT Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 12:41:24 GMT, Stefan Lobbenmeier wrote: >> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space >> >> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372 > > Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision: > > also use in other locations src/jdk.jpackage/share/man/jpackage.md line 426: > 424: : Menu group this application is placed in > 425: > 426: `--linux-package-deps *package-dep-string*` Should it be "`--linux-package-deps *package-dep-string*`" -> "`--linux-package-deps` *package-dep-string*" similar to other options like `--linux-menu-group`. "``" around option only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101143417 From vyazici at openjdk.org Wed May 21 21:02:04 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 21 May 2025 21:02:04 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner Message-ID: There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. ### Fixing strategy * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. ### Scanning strategy The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: # Perl is used for multi-line matching find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print git grep -H 'FileDescriptor.in' "*.java" All calls to `InputStreamReader::new` and `Scanner::new` are checked too. ### Problems encountered 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: ``` DOMImplementationRegistry InputRC ListingErrorHandler PandocFilter ``` 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property ------------- Commit messages: - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations Changes: https://git.openjdk.org/jdk/pull/25368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356893 Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/25368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368 PR: https://git.openjdk.org/jdk/pull/25368 From rriggs at openjdk.org Wed May 21 21:08:01 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 21:08:01 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v25] In-Reply-To: <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com> Message-ID: On Wed, 21 May 2025 19:18:03 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter 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 29 additional commits since the last revision: > > - 8354724: Update API notes > - Merge > - 8354724: Revert previous commit and remove first comma in the change > - 8354724: Improve verbiage about I/O errors > - 8354724: Replace getChars in previous commit with subSequence > - 8354724: Improve readAllAsString method of Reader returned by Reader.of > - 8354724: Change readAllCharsAsString as suggested; move test to proper location > - 8354724: "stream" -> "reader" > - 8354724: Attempt to further improve verbiage > - Merge > - ... and 19 more: https://git.openjdk.org/jdk/compare/b2ecf232...f9c732eb Looks good as a straightforward convenience for getting lines or a string from a Reader. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2859115874 From jlu at openjdk.org Wed May 21 21:24:11 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 21 May 2025 21:24:11 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable Message-ID: _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/25371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357281 Stats: 180 lines in 3 files changed: 15 ins; 69 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/25371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371 PR: https://git.openjdk.org/jdk/pull/25371 From liach at openjdk.org Wed May 21 21:31:16 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 21:31:16 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v7] In-Reply-To: References: Message-ID: > In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - More review updates - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate - Move intrinsic to be a subsection; just one most common function of the annotation - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java Co-authored-by: Raffaello Giulietti - Shorter first sentence - Updates, thanks to John - Refine validation and defensive copying - 8355223: Improve documentation on @IntrinsicCandidate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24777/files - new: https://git.openjdk.org/jdk/pull/24777/files/317dd27a..a312d92b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=05-06 Stats: 45626 lines in 1611 files changed: 26514 ins; 10851 del; 8261 mod Patch: https://git.openjdk.org/jdk/pull/24777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777 PR: https://git.openjdk.org/jdk/pull/24777 From liach at openjdk.org Wed May 21 21:31:16 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 21:31:16 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com> On Fri, 16 May 2025 19:45:16 GMT, John R Rose wrote: > Or just: s/, unlike the other methods// Removed mention of "the other methods". > src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 90: > >> 88: * intrinsic.) For example, the documentation can simply say that the result is >> 89: * undefined if a race happens. However, race conditions must not lead to >> 90: * program failures or type safety breaches, as listed above. > > Maybe add a teaching paragraph: > >> Reasoning about such race conditions is difficult, but it is a necessary skill when working with intrinsics that can observe racing shared variables. One example of a tolerable race is a repeated read of a shared reference. This only works if the algorithm takes no action based on the first read, other than deciding to perform the second read; it must "forget what it saw" in the first read. This is why the array-mismatch intrinsics can sometimes report a tentative search hit (maybe using vectorized code), which can then be confirmed (by scalar code) as the caller makes a fresh and independent observation. > > (This is done when the array mismatch logic performs NaN-folding. I just noticed that the NaN-folding code in ArraysSupport is slightly incorrect with respect to races!) I have appened this teaching paragraph also as a blockquote inlined note after this current paragraph. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101197921 PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101199974 From liach at openjdk.org Wed May 21 21:31:16 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 21:31:16 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:11:39 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 50: >> >>> 48: * For example, the bytecodes of a candidate method may be executed by lower >>> 49: * compilation tiers of VM execution, while higher compilation tiers may replace >>> 50: * the bytecodes with specialized assembly code and/or compiler IR. Therefore, >> >>> while higher compilation tiers may replace the bytecodes with specialized assembly code and/or compiler IR >> >> Is there ever a case, where for a `@IntrinsicCandidate` method, the runtime will choose to execute the instrinsic for that method for a certain duration and then at a later point in time replace the intrinsic with compiler generated code? In other words, once the runtime executes the intrinsic implementation for a `@IntrinsicCandidate` method, will the method's implementation be switched to anything else during the lifetime of an application? > > We cannot rule it out, but this sentence begins "for example" meaning this is just one scenario and is not exhaustive. To address your concern, I have reworded: * During execution, intrinsification may happen and may be rolled back at any * moment; this loading and unloading process may happen zero to many times. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101198872 From rriggs at openjdk.org Wed May 21 21:33:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 21:33:56 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com> References: <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com> Message-ID: On Wed, 21 May 2025 21:28:07 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 90: >> >>> 88: * intrinsic.) For example, the documentation can simply say that the result is >>> 89: * undefined if a race happens. However, race conditions must not lead to >>> 90: * program failures or type safety breaches, as listed above. >> >> Maybe add a teaching paragraph: >> >>> Reasoning about such race conditions is difficult, but it is a necessary skill when working with intrinsics that can observe racing shared variables. One example of a tolerable race is a repeated read of a shared reference. This only works if the algorithm takes no action based on the first read, other than deciding to perform the second read; it must "forget what it saw" in the first read. This is why the array-mismatch intrinsics can sometimes report a tentative search hit (maybe using vectorized code), which can then be confirmed (by scalar code) as the caller makes a fresh and independent observation. >> >> (This is done when the array mismatch logic performs NaN-folding. I just noticed that the NaN-folding code in ArraysSupport is slightly incorrect with respect to races!) > > I have appened this teaching paragraph also as a blockquote inlined note after this current paragraph. This unnecessary detail goes will beyond the description of the annotation and is more of a design doc for VM implementation so this is not really the best place for it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101204688 From rriggs at openjdk.org Wed May 21 21:39:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 21:39:53 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property There too many changes in too many different areas to be in a single PR. Please break it down by review areas. Client, core libs, tools, etc. ------------- PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030 From liach at openjdk.org Wed May 21 21:42:04 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 21:42:04 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v25] In-Reply-To: <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com> Message-ID: <4pPFoeCY_nyCbqACGpn_RgSM7js2KzuXgVod7PgIyR0=.a5ce2321-9ad4-4738-9408-ca6cc4fc5dd9@github.com> On Wed, 21 May 2025 19:18:03 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter 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 29 additional commits since the last revision: > > - 8354724: Update API notes > - Merge > - 8354724: Revert previous commit and remove first comma in the change > - 8354724: Improve verbiage about I/O errors > - 8354724: Replace getChars in previous commit with subSequence > - 8354724: Improve readAllAsString method of Reader returned by Reader.of > - 8354724: Change readAllCharsAsString as suggested; move test to proper location > - 8354724: "stream" -> "reader" > - 8354724: Attempt to further improve verbiage > - Merge > - ... and 19 more: https://git.openjdk.org/jdk/compare/c5a1d189...f9c732eb src/java.base/share/classes/java/io/Reader.java line 460: > 458: */ > 459: public List readAllLines() throws IOException { > 460: return readAllCharsAsString().lines().toList(); I recommend an implementation comment that we intentionally avoid delegating to `readAllAsString`, which can be overridden by subclasses. Otherwise, the purpose of `readAllCharsAsString` may not be immediately clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2101213305 From liach at openjdk.org Wed May 21 21:43:55 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 21:43:55 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6] In-Reply-To: References: <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com> Message-ID: On Wed, 21 May 2025 21:31:39 GMT, Roger Riggs wrote: >> I have appened this teaching paragraph also as a blockquote inlined note after this current paragraph. > > This unnecessary detail goes will beyond the description of the annotation and is more of a design doc for VM implementation so this is not really the best place for it. This is a general note for intrinsic APIs - in rendering, this is a blockquote, so it is nested as if it is an inlined footnote. It does not impact the readability of the main body. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101216837 From naoto at openjdk.org Wed May 21 22:18:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 May 2025 22:18:51 GMT Subject: RFR: 8347050: Console.readLine() drops '\' when reading through JLine [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 07:23:07 GMT, Jan Lahoda wrote: >> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine(). >> >> This PR proposes to disable the history expansion. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing test on Windows. Looks fine ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25326#pullrequestreview-2859258534 From lancea at openjdk.org Wed May 21 22:20:59 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 21 May 2025 22:20:59 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 10:43:12 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweaking exact wording. src/jdk.zipfs/share/classes/module-info.java line 279: > 277: *
        > 278: *
      • > 279: * If no value is set, the file system is created read-write created -> created as I think it might be better as > If no value is specified, the file system is created as .... src/jdk.zipfs/share/classes/module-info.java line 289: > 287: * read-only file system requires the underlying ZIP file to > 288: * already exist. > 289: * Specifying {@code create} as {@code true} and {@code accessMode} as > Specifying {@code create} You should make this clear that it is the 'create property ' src/jdk.zipfs/share/classes/module-info.java line 291: > 289: * Specifying {@code create} as {@code true} and {@code accessMode} as > 290: * {@code readOnly} will cause an {@code IllegalArgumentException} > 291: * to be thrown when creating the ZIP file system. I 'think' this should be "cause a" or "result in a" for the usages of "cause an" based on how the phrase is used ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101259671 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101262569 PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101257012 From liach at openjdk.org Wed May 21 22:33:55 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 22:33:55 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote: > _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. The record migration is sensible: this class is purely used as a data carrier. Its object methods of hashCode and equals were unused so we can migrate safely, and the public constructor is okay too. One comment is about the `List` returning methods: currently, you are doing: return list.isEmpty() ? list : Collections.unmodifiableList(list); This code is error prone: if the list becomes immutable, the wrapper is redundant; if the list becomes mutable, the empty list can have new items added, and is not safe. Since this is only accessed by trusted code (and we don't do dangerous thingss like `contains(null)`, we have much freedom in refactoring - we might just use the raw array list because users don't change them, and add alerts on record header about the mutability. Or wrap those lists with unmodifiableList upon parsing, or copy with List.copyOf, etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2899412146 From swen at openjdk.org Wed May 21 22:41:56 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 21 May 2025 22:41:56 GMT Subject: Integrated: 8357063: Document preconditions for DecimalDigits methods In-Reply-To: References: Message-ID: On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen wrote: > Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks. This pull request has now been integrated. Changeset: 07871cd7 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/07871cd78aa7ee35762234112dfe46fe3ebc9a57 Stats: 74 lines in 7 files changed: 16 ins; 5 del; 53 mod 8357063: Document preconditions for DecimalDigits methods Reviewed-by: vyazici, liach, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/25246 From duke at openjdk.org Wed May 21 23:30:18 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 21 May 2025 23:30:18 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v12] In-Reply-To: References: Message-ID: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: More tweaking... ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/ab15123a..92355287 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=10-11 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From swen at openjdk.org Thu May 22 00:57:06 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 May 2025 00:57:06 GMT Subject: RFR: 8349176: Speed up Integer/Long.toString via allocateUninitializedArray [v5] In-Reply-To: References: Message-ID: > The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501 # Conflicts: # src/java.base/share/classes/java/lang/Integer.java # src/java.base/share/classes/java/lang/Long.java - simplify code - use Unsafe::allocateUninitializedArray - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501 # Conflicts: # src/java.base/share/classes/java/lang/Integer.java # src/java.base/share/classes/java/lang/Long.java - use StringConcatHelper.newArray - simplify - use Unsafe.allocateUninitializedArray - revert StringConcatHelper newArray change - copyright - remove duplicate check - ... and 1 more: https://git.openjdk.org/jdk/compare/b685ea54...85e437a8 ------------- Changes: https://git.openjdk.org/jdk/pull/23353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=04 Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23353/head:pull/23353 PR: https://git.openjdk.org/jdk/pull/23353 From naoto at openjdk.org Thu May 22 01:18:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 22 May 2025 01:18:54 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable In-Reply-To: References: Message-ID: <3wbh2CRyYKYPfjMrlaJUB8fiaH9FSVFusKFnhJzLBys=.3716f5f6-c196-4887-bf39-1f526d9cf8e3@github.com> On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote: > _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. Nice refactoring. Couple of nits follow src/java.base/share/classes/sun/util/locale/LanguageTag.java line 53: > 51: public static final String PRIVUSE_VARIANT_PREFIX = "lvariant"; > 52: private static final String EMPTY_TAG = ""; > 53: private static final List EMPTY_TAGS = Collections.emptyList(); It would be clearer to rename "TAG(S)" to "SUBTAG(S)" src/java.base/share/classes/sun/util/locale/LanguageTag.java line 191: > 189: String region = EMPTY_TAG; > 190: List variants = EMPTY_TAGS; > 191: List extensions = EMPTY_TAGS; These assignments can be moved for the case of `language.isEmpty()` ------------- PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2859485182 PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101431166 PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101426074 From swen at openjdk.org Thu May 22 01:29:05 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 May 2025 01:29:05 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote: > _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. src/java.base/share/classes/sun/util/locale/LanguageTag.java line 458: > 456: baseLanguage = "id"; > 457: } > 458: language = baseLanguage; Suggestion: language = switch(baseLanguage) { case "iw" -> "he"; case "ji" -> "yi"; case "in" -> "id"; default -> baseLanguage; }; use switch expression ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101446785 From henryjen at openjdk.org Thu May 22 01:29:12 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 01:29:12 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: References: Message-ID: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Validator to take a file, use term JAR file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/b0df54d2..52af70aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=10-11 Stats: 27 lines in 3 files changed: 7 ins; 3 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From henryjen at openjdk.org Thu May 22 01:45:00 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 01:45:00 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com> References: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com> Message-ID: On Wed, 21 May 2025 16:53:17 GMT, Jaikiran Pai wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Mismatched order is considered invalid > > src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454: > >> 452: new FileInputStream(file)))) { >> 453: >> 454: return Validator.validate(this, zf, zis); > > I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate. > > The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem. > > It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR. I keep File instead of Path to avoid unnecessary changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101460623 From henryjen at openjdk.org Thu May 22 01:45:01 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 01:45:01 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:21:18 GMT, Lance Andersen wrote: >> src/jdk.jartool/share/man/jar.md line 223: >> >>> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools >>> 222: other than the `jar` command. The --validate option may be used to perform the following >>> 223: integrity checks against a jar archive: >> >> Nit - "integrity checks against a JAR file:" > > I think we have other inconsistencies that we can clean up at a later time in the help and man page for the jar tool in the usages of archive/file. > > The man page description can use a further overhaul as we still reference applets. So we can do this also as follow on work I changed references in the new content and leave the retrofit to future works. >> src/jdk.jartool/share/man/jar.md line 235: >> >>> 233: versions. >>> 234: >>> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise >> >> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes. > >> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes. > > I don't have a preference but unix/MacOS commands vary: > > - ls command: The ls utility exits?0 on success, and?>0 if an error occurs. > - grep command: > >> The grep utility exits with one of the following values: > > 0 One or more lines were selected. > 1 No lines were selected. > >1 An error occurred. > > - unzip command: > >> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the > following values, except under VMS: > > 0 normal; no errors or warnings detected. > > 1 one or more warning errors were encountered, but processing completed successfully > anyway. This includes zipfiles where one or more files was skipped due to unsupported > compression method or encryption with an unknown password. > > 2 a generic error in the zipfile format was detected. Processing may have completed > successfully anyway; some broken zipfiles created by other archivers have simple work- > arounds. > 3 a severe error in the zipfile format was detected. Processing probably failed > immediately. > > 4 unzip was unable to allocate memory for one or more buffers during program > initialization. > > 5 unzip was unable to allocate memory or unable to obtain a tty to read the decryption > password(s). > > 6 unzip was unable to allocate memory during decompression to disk. > > 7 unzip was unable to allocate memory during in-memory decompression. > > 8 [currently not used] > > 9 the specified zipfiles were not found. > > 10 invalid options were specified on the command line. > > 11 no matching files were found. > > 50 the disk is (or was) full during extraction. > > 51 the end of the ZIP archive was encountered prematurely. > > 80 the user aborted unzip prematurely with control-C (or similar) > > 81 testing or extraction of one or more files failed due to unsupported compression methods > or unsupported decryption. > > 82 no files were found due to bad decryption password(s). (If even one file is successfully > ... I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101457168 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101458911 From lancea at openjdk.org Thu May 22 01:48:54 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 22 May 2025 01:48:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 01:39:45 GMT, Henry Jen wrote: >>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes. >> >> I don't have a preference but unix/MacOS commands vary: >> >> - ls command: The ls utility exits?0 on success, and?>0 if an error occurs. >> - grep command: >> >>> The grep utility exits with one of the following values: >> >> 0 One or more lines were selected. >> 1 No lines were selected. >> >1 An error occurred. >> >> - unzip command: >> >>> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the >> following values, except under VMS: >> >> 0 normal; no errors or warnings detected. >> >> 1 one or more warning errors were encountered, but processing completed successfully >> anyway. This includes zipfiles where one or more files was skipped due to unsupported >> compression method or encryption with an unknown password. >> >> 2 a generic error in the zipfile format was detected. Processing may have completed >> successfully anyway; some broken zipfiles created by other archivers have simple work- >> arounds. >> 3 a severe error in the zipfile format was detected. Processing probably failed >> immediately. >> >> 4 unzip was unable to allocate memory for one or more buffers during program >> initialization. >> >> 5 unzip was unable to allocate memory or unable to obtain a tty to read the decryption >> password(s). >> >> 6 unzip was unable to allocate memory during decompression to disk. >> >> 7 unzip was unable to allocate memory during in-memory decompression. >> >> 8 [currently not used] >> >> 9 the specified zipfiles were not found. >> >> 10 invalid options were specified on the command line. >> >> 11 no matching files were found. >> >> 50 the disk is (or was) full during extraction. >> >> 51 the end of the ZIP archive was encountered prematurely. >> >> 80 the user aborted unzip prematurely with control-C (or similar) >> >> 81 testing or extraction of one or more files failed due to unsupported compression methods >> or unsupported decryption. >> >> ... > > I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations. Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101463994 From duke at openjdk.org Thu May 22 02:11:58 2025 From: duke at openjdk.org (He-Pin (kerr)) Date: Thu, 22 May 2025 02:11:58 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com> References: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com> Message-ID: <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com> On Tue, 20 May 2025 10:11:03 GMT, Viktor Klang wrote: >> It would be much nicer if you take this one:), we are on JDK 21 and want to have this in the next LTS. > > @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit. @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2899696140 From jpai at openjdk.org Thu May 22 02:21:04 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 02:21:04 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v3] In-Reply-To: References: Message-ID: On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg wrote: >> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry. >> >> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance. >> >> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file. >> >> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html. > > Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright and remove part of comment Hello Jason, I'll just run this once in our CI today to make sure nothing fails against latest master. I'll add a comment here once that's complete and you can then integrate it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2899711012 From syan at openjdk.org Thu May 22 03:44:57 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 May 2025 03:44:57 GMT Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug In-Reply-To: References: Message-ID: On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon wrote: > Hi, > > This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines. > A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable. > > Thanks, > Michael Changes requested by syan (Committer). test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 32: > 30: */ > 31: /* > 32: * @test id=Z Should we need update the copyright year ------------- PR Review: https://git.openjdk.org/jdk/pull/25331#pullrequestreview-2859675980 PR Review Comment: https://git.openjdk.org/jdk/pull/25331#discussion_r2101559815 From duke at openjdk.org Thu May 22 03:56:52 2025 From: duke at openjdk.org (duke) Date: Thu, 22 May 2025 03:56:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> References: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> Message-ID: On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > address review comments @pawanchawdhary1 Your change (at version 5e1f9240b379356fb8d5e0db1587216d1cbeed0f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2899823355 From alanb at openjdk.org Thu May 22 05:54:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 May 2025 05:54:52 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property javax.swing.text.DefaultEditorKit.read(InputStream ...) is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`. From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753 From jlahoda at openjdk.org Thu May 22 06:01:57 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 22 May 2025 06:01:57 GMT Subject: RFR: 8347050: Console.readLine() drops '\' when reading through JLine [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 07:23:07 GMT, Jan Lahoda wrote: >> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine(). >> >> This PR proposes to disable the history expansion. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing test on Windows. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25326#issuecomment-2900008739 From jlahoda at openjdk.org Thu May 22 06:01:58 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 22 May 2025 06:01:58 GMT Subject: Integrated: 8347050: Console.readLine() drops '\' when reading through JLine In-Reply-To: References: Message-ID: <9Zsfwz2gsl592Z9ziQiiStxWdPf582vrXsSO1TBQVbI=.82f0c2e4-3fd6-4de4-bf56-94f4bdbad112@github.com> On Tue, 20 May 2025 13:07:55 GMT, Jan Lahoda wrote: > JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine(). > > This PR proposes to disable the history expansion. This pull request has now been integrated. Changeset: 061b5cc6 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/061b5cc6b9939e182f3b2063ad86d042e35f0a91 Stats: 19 lines in 2 files changed: 17 ins; 0 del; 2 mod 8347050: Console.readLine() drops '\' when reading through JLine Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/25326 From syan at openjdk.org Thu May 22 06:19:55 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 May 2025 06:19:55 GMT Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov wrote: > Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual Changes requested by syan (Committer). test/jdk/java/foreign/TestMatrix.java line 38: > 36: * @build NativeTestHelper CallGeneratorHelper TestUpcallHighArity > 37: * > 38: * @run testng/othervm/native/manual Should we update the copyright year to 2025. ------------- PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2859914726 PR Review Comment: https://git.openjdk.org/jdk/pull/25355#discussion_r2101720038 From jpai at openjdk.org Thu May 22 06:50:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 06:50:54 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance In-Reply-To: References: <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com> Message-ID: On Mon, 24 Mar 2025 22:33:56 GMT, Jason Zaugg wrote: >> Good catch, thanks! Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test. > >> Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test. > > I tested this change [externally](https://github.com/retronym/jarcache/blob/ba7f5cdd5f7db976a6568855a0d517f52a1404bf/demo/src/test/scala/demo/JarCacheAgentTest.java#L75-L76) with [JFRUnit](https://github.com/moditect/jfrunit). > > If preferred, I could create a `jtreg` test along similar lines. It would use the JFR API directly to capture `jdk.FileRead` events. The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR. tier1, tier2, tier3 testing of these changes against latest master branch has completed without any related failures. @retronym, you can go ahead and "/integrate" this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900107948 From tvaleev at openjdk.org Thu May 22 07:04:52 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 22 May 2025 07:04:52 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com> References: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com> Message-ID: On Wed, 21 May 2025 11:55:07 GMT, Raffaello Giulietti wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Return first argument in case of tie (to be consistent with BinaryOperator); junit tests > > src/java.base/share/classes/java/util/Comparator.java line 200: > >> 198: * @return the larger of {@code a} and {@code b} according to this comparator. >> 199: * @throws ClassCastException if the collection contains elements that are >> 200: * not mutually comparable (for example, strings and > > `` is more intent revealing. > Suggestion: > > * not mutually comparable (for example, strings and I copied this sentence from `java.util.Collections` where `` is used 48 times. I'll replace it here with ``, but probably it should be updated en-masse for consistency? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2101795425 From duke at openjdk.org Thu May 22 07:08:55 2025 From: duke at openjdk.org (duke) Date: Thu, 22 May 2025 07:08:55 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v3] In-Reply-To: References: Message-ID: On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg wrote: >> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry. >> >> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance. >> >> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file. >> >> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html. > > Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright and remove part of comment @retronym Your change (at version e1334955bbe1db1cb7dd0e62c138c2321045d719) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900148295 From tvaleev at openjdk.org Thu May 22 07:20:11 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 22 May 2025 07:20:11 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v3] In-Reply-To: References: Message-ID: > Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: > https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html > The specification is mostly composed of Math.min/max and Collections.min/max specifications. > > The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. > > I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: - MinMaxTest: remove unnecessary public modifier - Use instead of ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25297/files - new: https://git.openjdk.org/jdk/pull/25297/files/9edc73e2..b750c3fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297 PR: https://git.openjdk.org/jdk/pull/25297 From tvaleev at openjdk.org Thu May 22 07:22:51 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 22 May 2025 07:22:51 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: <38y18L1eSJAGuzFgH8xAn38k_Xu8pqueLhYYIEAzz8M=.bd30476b-e887-414a-8f03-f3f26c78f66b@github.com> References: <38y18L1eSJAGuzFgH8xAn38k_Xu8pqueLhYYIEAzz8M=.bd30476b-e887-414a-8f03-f3f26c78f66b@github.com> Message-ID: On Wed, 21 May 2025 19:20:38 GMT, Peter Levart wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Return first argument in case of tie (to be consistent with BinaryOperator); junit tests > > What I was trying to say is that not only would Guava's Ordering not compile any more (it would still be binary compatible I think, as both methods have same erasure), but I also think that generic max and min as defined by Guava's Ordering are more useful too. So what do you think of making them generic like this: > > > default E max(E e1, E e2) { > return compare(e1, e2) >= 0 ? e1 : e2; > } > > default E min(E e1, E e2) { > return compare(e1, e2) <= 0 ? e1 : e2; > } @plevart this is definitely a good idea, and it will make the methods more convenient. I used `U` as a new type parameter, because it looks like it's more common in the OpenJDK codebase (e.g., `StructuredTaskScope::fork`). Now, Guava should be source-compatible, though it's possible that some other libraries declare non-generic min/max and they will not be source-compatible anymore. I'll mention this in CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2900176890 From tvaleev at openjdk.org Thu May 22 07:22:52 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 22 May 2025 07:22:52 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v2] In-Reply-To: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com> References: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com> Message-ID: On Wed, 21 May 2025 11:55:16 GMT, Raffaello Giulietti wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Return first argument in case of tie (to be consistent with BinaryOperator); junit tests > > test/jdk/java/util/Comparator/MinMaxTest.java line 39: > >> 37: public class MinMaxTest { >> 38: @Test >> 39: public void testMin() { > > According to [this](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods), test methods do not need to be `public` (but cannot be `private`). > > Suggestion: > > void testMin() { Done, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2101825796 From vklang at openjdk.org Thu May 22 07:28:56 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 22 May 2025 07:28:56 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com> References: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com> <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com> Message-ID: On Thu, 22 May 2025 02:09:08 GMT, He-Pin(kerr) wrote: >> @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit. > > @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc. @He-Pin Please suggest improvements to https://openjdk.org/guide/ ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2900190233 From jzaugg at openjdk.org Thu May 22 07:29:02 2025 From: jzaugg at openjdk.org (Jason Zaugg) Date: Thu, 22 May 2025 07:29:02 GMT Subject: Integrated: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg wrote: > zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry. > > Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance. > > com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file. > > It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html. This pull request has now been integrated. Changeset: d9b6e4b1 Author: Jason Zaugg Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/d9b6e4b13200684b69a161e288b9883ff0d96bec Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance Reviewed-by: liach, jpai, jlahoda, lancea ------------- PR: https://git.openjdk.org/jdk/pull/24176 From vklang at openjdk.org Thu May 22 07:34:02 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 22 May 2025 07:34:02 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance In-Reply-To: References: <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com> Message-ID: On Mon, 24 Mar 2025 22:33:56 GMT, Jason Zaugg wrote: >> Good catch, thanks! Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test. > >> Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test. > > I tested this change [externally](https://github.com/retronym/jarcache/blob/ba7f5cdd5f7db976a6568855a0d517f52a1404bf/demo/src/test/scala/demo/JarCacheAgentTest.java#L75-L76) with [JFRUnit](https://github.com/moditect/jfrunit). > > If preferred, I could create a `jtreg` test along similar lines. It would use the JFR API directly to capture `jdk.FileRead` events. The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR. @retronym Great to see you here, Jason! I hope all is well. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900199480 From pminborg at openjdk.org Thu May 22 07:46:02 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 07:46:02 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps Message-ID: This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. This has the effect of simplifying and shortening the code while improving performance. The number of branches to evaluate is reduced. ------------- Commit messages: - Simplify the fill method Changes: https://git.openjdk.org/jdk/pull/25383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357531 Stats: 59 lines in 1 file changed: 26 ins; 15 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/25383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383 PR: https://git.openjdk.org/jdk/pull/25383 From pminborg at openjdk.org Thu May 22 07:46:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 07:46:03 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps In-Reply-To: References: Message-ID: On Thu, 22 May 2025 07:34:08 GMT, Per Minborg wrote: > This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. > > This has the effect of simplifying and shortening the code while improving performance. The number of branches to evaluate is reduced. Performance on an M1 Mac (Sequoia 15.4.1) Base: Benchmark (ELEM_SIZE) Mode Cnt Score Error Units SegmentBulkFill.nativeSegmentFillJava 2 avgt 30 1.618 ? 0.060 ns/op SegmentBulkFill.nativeSegmentFillJava 3 avgt 30 1.602 ? 0.042 ns/op SegmentBulkFill.nativeSegmentFillJava 4 avgt 30 1.775 ? 0.070 ns/op SegmentBulkFill.nativeSegmentFillJava 5 avgt 30 1.759 ? 0.051 ns/op SegmentBulkFill.nativeSegmentFillJava 6 avgt 30 1.771 ? 0.051 ns/op SegmentBulkFill.nativeSegmentFillJava 7 avgt 30 1.785 ? 0.049 ns/op SegmentBulkFill.nativeSegmentFillJava 8 avgt 30 2.383 ? 0.061 ns/op SegmentBulkFill.nativeSegmentFillJava 64 avgt 30 4.010 ? 0.255 ns/op SegmentBulkFill.nativeSegmentFillJava 512 avgt 30 6.622 ? 0.246 ns/op SegmentBulkFill.nativeSegmentFillJava 4096 avgt 30 44.431 ? 0.832 ns/op SegmentBulkFill.nativeSegmentFillJava 32768 avgt 30 331.429 ? 3.073 ns/op SegmentBulkFill.nativeSegmentFillJava 262144 avgt 30 4174.795 ? 76.096 ns/op SegmentBulkFill.nativeSegmentFillJava 2097152 avgt 30 33084.699 ? 53.530 ns/op SegmentBulkFill.nativeSegmentFillJava 16777216 avgt 30 298953.004 ? 11241.262 ns/op SegmentBulkFill.nativeSegmentFillJava 134217728 avgt 30 2857973.939 ? 128453.291 ns/op Patch Benchmark (ELEM_SIZE) Mode Cnt Score Error Units SegmentBulkFill.nativeSegmentFillJava 2 avgt 30 1.317 ? 0.022 ns/op SegmentBulkFill.nativeSegmentFillJava 3 avgt 30 1.313 ? 0.006 ns/op SegmentBulkFill.nativeSegmentFillJava 4 avgt 30 1.319 ? 0.018 ns/op SegmentBulkFill.nativeSegmentFillJava 5 avgt 30 1.317 ? 0.019 ns/op SegmentBulkFill.nativeSegmentFillJava 6 avgt 30 1.316 ? 0.016 ns/op SegmentBulkFill.nativeSegmentFillJava 7 avgt 30 1.320 ? 0.019 ns/op SegmentBulkFill.nativeSegmentFillJava 8 avgt 30 2.239 ? 0.047 ns/op SegmentBulkFill.nativeSegmentFillJava 64 avgt 30 3.487 ? 0.074 ns/op SegmentBulkFill.nativeSegmentFillJava 512 avgt 30 6.659 ? 0.102 ns/op SegmentBulkFill.nativeSegmentFillJava 4096 avgt 30 44.461 ? 0.666 ns/op SegmentBulkFill.nativeSegmentFillJava 32768 avgt 30 331.159 ? 5.928 ns/op SegmentBulkFill.nativeSegmentFillJava 262144 avgt 30 4171.649 ? 60.867 ns/op SegmentBulkFill.nativeSegmentFillJava 2097152 avgt 30 34718.817 ? 697.494 ns/op SegmentBulkFill.nativeSegmentFillJava 16777216 avgt 30 305446.597 ? 11087.702 ns/op SegmentBulkFill.nativeSegmentFillJava 134217728 avgt 30 2905051.303 ? 114905.125 ns/op ![image](https://github.com/user-attachments/assets/df4888ab-67d9-49fe-982b-8018d949cee3) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900213674 From duke at openjdk.org Thu May 22 07:58:07 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 22 May 2025 07:58:07 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: References: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com> <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com> Message-ID: On Thu, 22 May 2025 07:26:29 GMT, Viktor Klang wrote: >> @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc. > > @He-Pin Please suggest improvements to https://openjdk.org/guide/ ? > @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc. This document https://github.com/openjdk/jdk/blob/master/doc/ide.md describes IDE support, but I couldn't find if it is also contained/linked from https://openjdk.org/guide/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2900260927 From vyazici at openjdk.org Thu May 22 07:59:09 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 22 May 2025 07:59:09 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs wrote: >> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. >> >> ### Fixing strategy >> >> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. >> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. >> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. >> >> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. >> >> ### Scanning strategy >> >> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: >> >> >> # Perl is used for multi-line matching >> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print >> git grep -H 'FileDescriptor.in' "*.java" >> >> >> All calls to `InputStreamReader::new` and `Scanner::new` are checked too. >> >> ### Problems encountered >> >> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: >> >> ``` >> DOMImplementationRegistry >> InputRC >> ListingErrorHandler >> PandocFilter >> ``` >> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property > > There too many changes in too many different areas to be in a single PR. > Please break it down by review areas. Client, core libs, tools, etc. @RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will 1. withdraw this PR, 2. convert certain changes to spec clarifications, 3. and break it down to multiple PRs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422 From vyazici at openjdk.org Thu May 22 07:59:10 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 22 May 2025 07:59:10 GMT Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25368 From vyazici at openjdk.org Thu May 22 08:05:54 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 22 May 2025 08:05:54 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v4] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 19:29:08 GMT, Naoto Sato wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > CharsetTest clean-up Marked as reviewed by vyazici (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2860206112 From pminborg at openjdk.org Thu May 22 08:14:35 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 08:14:35 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v2] In-Reply-To: References: Message-ID: > This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. > > This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Correct typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25383/files - new: https://git.openjdk.org/jdk/pull/25383/files/1a095f60..9e0d67ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383 PR: https://git.openjdk.org/jdk/pull/25383 From swen at openjdk.org Thu May 22 08:14:35 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 May 2025 08:14:35 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:11:09 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Correct typo in comment src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 110: > 108: SCOPED_MEMORY_ACCESS.setMemory(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset(), len, value); > 109: } > 110: } Suggestion: final var sessionImpl = dst.sessionImpl(); final var unsafeGetBase = dst.unsafeGetBase(); final var unsafeGetOffset = dst.unsafeGetOffset(); final var bigEndian = !Architecture.isLittleEndian(); // Switch on log2(len) = 64 - Long.numberOfLeadingZeros(len) switch (64 - Long.numberOfLeadingZeros(len)) { case 0 -> sessionImpl.checkValidState(); // Implicit state check case 1 -> SCOPED_MEMORY_ACCESS.putByte(sessionImpl, unsafeGetBase, unsafeGetOffset, value); case 2 -> { SCOPED_MEMORY_ACCESS.putShortUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset, (short) longValue, bigEndian); SCOPED_MEMORY_ACCESS.putShortUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + len - Short.BYTES, (short) longValue, bigEndian); } case 3 -> { SCOPED_MEMORY_ACCESS.putIntUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset, (int) longValue, bigEndian); SCOPED_MEMORY_ACCESS.putIntUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + len - Integer.BYTES, (int) longValue, bigEndian); } default -> { if (len < NATIVE_THRESHOLD_FILL) { final int limit = (int) (len & (NATIVE_THRESHOLD_FILL - 8)); for (int offset = 0; offset < limit; offset += Long.BYTES) { SCOPED_MEMORY_ACCESS.putLongUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + offset, longValue, bigEndian); } SCOPED_MEMORY_ACCESS.putLongUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + len - Long.BYTES, longValue, bigEndian); } else { // Handle larger segments via native calls SCOPED_MEMORY_ACCESS.setMemory(sessionImpl, unsafeGetBase, unsafeGetOffset, len, value); } } } The current CodeSize is 370, which is greater than 325. It cannot be inlined during C2 optimization. We can extract the method calls used in each branch and declare them as local variables, which can reduce the CodeSize to 298. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2101921745 From swen at openjdk.org Thu May 22 08:25:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 May 2025 08:25:52 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:14:35 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Correct typo in comment Here you can use putShort/putInt/putLong to replace putShortUnaligned/putIntUnaligned/putLongUnaligned ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900343335 From duke at openjdk.org Thu May 22 08:31:06 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 22 May 2025 08:31:06 GMT Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual [v2] In-Reply-To: References: Message-ID: > Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: 8357462: copyright update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25355/files - new: https://git.openjdk.org/jdk/pull/25355/files/166a8fe2..43bf37b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25355&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25355&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25355/head:pull/25355 PR: https://git.openjdk.org/jdk/pull/25355 From abimpoudis at openjdk.org Thu May 22 08:39:58 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 22 May 2025 08:39:58 GMT Subject: Integrated: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler In-Reply-To: References: Message-ID: On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis wrote: > While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation. > > For example this is not valid Java (and protected) by javac: > > > byte b = 1; > switch (b) { > case String s -> System.out.println("How did we get here? byte is " + s.getClass()); > } > > > but this is a valid call (and not protected): > > > CallSite shortSwitch = SwitchBootstraps.typeSwitch( > MethodHandles.lookup(), > "", > MethodType.methodType(int.class, short.class, int.class), // models (short, int) -> int > String.class); > > > The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. > > This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton. This pull request has now been integrated. Changeset: c0665efd Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/c0665efd4f7f43c567393570ba6872838debd77f Stats: 43 lines in 3 files changed: 27 ins; 4 del; 12 mod 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler Reviewed-by: jlahoda, liach ------------- PR: https://git.openjdk.org/jdk/pull/25090 From mcimadamore at openjdk.org Thu May 22 08:58:50 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 22 May 2025 08:58:50 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps In-Reply-To: References: Message-ID: <28EjVeHYRyc8FD4WTEi7AU9rdUXbzD2vUXUsOfTmdII=.0c7b5abc-1e73-476d-96af-91b5b7bfb1b8@github.com> On Thu, 22 May 2025 07:36:51 GMT, Per Minborg wrote: > Performance on an M1 Mac (Sequoia 15.4.1) Are the "regressions" for very big sizes related to this patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900432766 From mcimadamore at openjdk.org Thu May 22 08:58:52 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 22 May 2025 08:58:52 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:14:35 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Correct typo in comment src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 93: > 91: case 2 -> { > 92: SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset(), (short) longValue, !Architecture.isLittleEndian()); > 93: SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + len - Short.BYTES, (short) longValue, !Architecture.isLittleEndian()); So that I understand, since this configuration might pick up both length = 2 and length = 3, in 50% of cases there's a redundant store? This is also true for length = 4, 5, 6, 7 -- but in this case the chance of redundant store is reduced to 25%. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2102016436 From duke at openjdk.org Thu May 22 09:05:27 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 22 May 2025 09:05:27 GMT Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test Message-ID: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test ------------- Commit messages: - 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test Changes: https://git.openjdk.org/jdk/pull/25360/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356443 Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25360/head:pull/25360 PR: https://git.openjdk.org/jdk/pull/25360 From stuefe at openjdk.org Thu May 22 09:41:52 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 May 2025 09:41:52 GMT Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: On Wed, 21 May 2025 19:10:49 GMT, Roger Riggs wrote: >> Hi, please consider the following patch. >> >> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc. >> >> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens). >> >> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409 >> >> This patch also fixes two subtle bugs: >> - we didn't check the return value of the close() inside closeAllFileDescriptors >> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it) >> >> ---- >> >> Testing: >> >> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC. >> >> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC >> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open >> >> I verified that the test correctly detects a broken implementation that leaks file descriptors. >> >> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX). >> >> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green. > > Looks good @RogerRiggs Thank you. I hold this up a few days until JDK26 since its not super critical. Would one review be sufficient or do I need more? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25301#issuecomment-2900562843 From jpai at openjdk.org Thu May 22 10:41:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 10:41:59 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com> Message-ID: On Thu, 22 May 2025 01:41:51 GMT, Henry Jen wrote: >> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454: >> >>> 452: new FileInputStream(file)))) { >>> 453: >>> 454: return Validator.validate(this, zf, zis); >> >> I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate. >> >> The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem. >> >> It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR. > > I keep File instead of Path to avoid unnecessary changes. Thank you for the update to this method, Henry. Retaining the use of `File` is fine. We have a separate plan for future to use `java.nio.file.Path` for the code in the jar tool and this can be revisited at that time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102239606 From jpai at openjdk.org Thu May 22 10:51:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 10:51:07 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: On Thu, 22 May 2025 01:29:12 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Validator to take a file, use term JAR file src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 141: > 139: * NOTE: In order to check the encounter order based on the CEN listing, > 140: * this implementation assumes CEN entries are to be added before > 141: * add any LOC entries. That is, addCenEntry should be called before This looks like a typo. Should have been "adding any ..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102254941 From jpai at openjdk.org Thu May 22 11:11:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 11:11:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: On Thu, 22 May 2025 01:29:12 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Validator to take a file, use term JAR file src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147: > 145: private class EntryValidator { > 146: // A place holder when an entry is not yet seen in the directory > 147: static EntryEncounter PLACE_HOLDER = new EntryEncounter(0, 0); It looks like this could be `final`? And then `isPlaceHolder()` could just return `this == PLACE_HOLDER`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102292540 From pminborg at openjdk.org Thu May 22 11:16:58 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 11:16:58 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps In-Reply-To: <28EjVeHYRyc8FD4WTEi7AU9rdUXbzD2vUXUsOfTmdII=.0c7b5abc-1e73-476d-96af-91b5b7bfb1b8@github.com> References: <28EjVeHYRyc8FD4WTEi7AU9rdUXbzD2vUXUsOfTmdII=.0c7b5abc-1e73-476d-96af-91b5b7bfb1b8@github.com> Message-ID: On Thu, 22 May 2025 08:56:13 GMT, Maurizio Cimadamore wrote: > > Performance on an M1 Mac (Sequoia 15.4.1) > > Are the "regressions" for very big sizes related to this patch? By default, only segments that are smaller than 32 bytes will use the affected code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900835299 From pminborg at openjdk.org Thu May 22 11:26:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 11:26:37 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v3] In-Reply-To: References: Message-ID: > This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. > > This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. > > It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add case for long operations and break out methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25383/files - new: https://git.openjdk.org/jdk/pull/25383/files/9e0d67ec..65c88fba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=01-02 Stats: 54 lines in 1 file changed: 32 ins; 17 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383 PR: https://git.openjdk.org/jdk/pull/25383 From pminborg at openjdk.org Thu May 22 11:26:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 11:26:37 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v2] In-Reply-To: References: Message-ID: <8LSWD4ZFbb8dkGOVvUFPXutCgkatFekJye7f3wgzDNA=.95be2805-723a-4782-9913-e3bd1f5d072f@github.com> On Thu, 22 May 2025 08:23:26 GMT, Shaojin Wen wrote: > Here you can use putShort/putInt/putLong to replace putShortUnaligned/putIntUnaligned/putLongUnaligned The segment might be unaligned. For example, if it was sliced off an aligned segment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900848621 From pminborg at openjdk.org Thu May 22 11:26:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 11:26:37 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:55:09 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct typo in comment > > src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 93: > >> 91: case 2 -> { >> 92: SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset(), (short) longValue, !Architecture.isLittleEndian()); >> 93: SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + len - Short.BYTES, (short) longValue, !Architecture.isLittleEndian()); > > So that I understand, since this configuration might pick up both length = 2 and length = 3, in 50% of cases there's a redundant store? This is also true for length = 4, 5, 6, 7 -- but in this case the chance of redundant store is reduced to 25%. That is correct. But it seems the hardware can handle redundant stores better than handling more branching. One idea is to add in "halfbits" to the tableswitch which would reduce redundant stores. I think this would have little to no performance effect while complicating the code, but it might be worth trying anyhow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2102307360 From jpai at openjdk.org Thu May 22 11:26:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 11:26:58 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: On Thu, 22 May 2025 01:29:12 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Validator to take a file, use term JAR file src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 185: > 183: // Encounter order in CEN, step by 1 on each new entry > 184: int cenEncounterOrder = 0; > 185: // Encounter order in LOC, step by 1 for new LOC entry exist in CEN Nit - "for new LOC entry that exists in CEN" src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 208: > 206: /** > 207: * Record an entry apperance in LOC > 208: * We compare entry order based on the CEN. Thus do not step LOC Nit - would "Thus do not increment LOC ..." be easier to understand? You don't have to do the change if you prefer it this way (I see that we use the same term on the comment of the `cenEncounterOrder` and `locEncounterOrder` fields. src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 238: > 236: /** > 237: * Validation per entry observed. > 238: * Each entry must appeared at least oncee in CEN or LOC. A couple of typos - "Each entry must appear at least once in the CEN or LOC" src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 265: > 263: > 264: /** > 265: * Validate the jar entries by check each entry in encounter order Typo - "by checking ..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102312203 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102312688 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102316444 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102321661 From pminborg at openjdk.org Thu May 22 11:37:38 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 11:37:38 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v4] In-Reply-To: References: Message-ID: > This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. > > This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. > > It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Simplify ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25383/files - new: https://git.openjdk.org/jdk/pull/25383/files/65c88fba..eadf067b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=02-03 Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383 PR: https://git.openjdk.org/jdk/pull/25383 From jpai at openjdk.org Thu May 22 11:44:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 11:44:53 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: <6Hk0ojFnclvLTaykOsVJBhZ3WmFw2AwJZWCbjob25xY=.6d79d9f6-a6b4-48ba-a6a6-22cd0e9447d5@github.com> On Thu, 22 May 2025 11:20:18 GMT, Jaikiran Pai wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Validator to take a file, use term JAR file > > src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 185: > >> 183: // Encounter order in CEN, step by 1 on each new entry >> 184: int cenEncounterOrder = 0; >> 185: // Encounter order in LOC, step by 1 for new LOC entry exist in CEN > > Nit - "for new LOC entry that exists in CEN" I think the way you have implemented this is correct, but can you explain why we don't increment the `locEncounterOrder` for each LOC entry? I'm pretty sure I'll keep asking myself that question every time I see this code in future, so it would be good to have this clarified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102350306 From jpai at openjdk.org Thu May 22 11:44:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 11:44:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com> On Thu, 22 May 2025 01:29:12 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Validator to take a file, use term JAR file test/jdk/tools/jar/ValidatorTest.java line 60: > 58: import jdk.test.lib.util.FileUtils; > 59: > 60: @TestInstance(Lifecycle.PER_CLASS) I haven't seen this used commonly in our tests. Is there something specific in this test that requires this usage? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102353416 From jpai at openjdk.org Thu May 22 11:49:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 11:49:56 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: <9UV7peR74Nase0cMQ7evBn-99r_aGMlGjyF-0apfTRo=.0363580c-e520-46c6-88e3-dd0cece21294@github.com> On Thu, 22 May 2025 01:29:12 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Validator to take a file, use term JAR file test/jdk/tools/jar/ValidatorTest.java line 224: > 222: > 223: @Test > 224: public void testValidateJar() throws IOException { Perhaps rename the method to `testValidJar()`? test/jdk/tools/jar/ValidatorTest.java line 230: > 228: jar("--validate --file " + zip.toString()); > 229: } catch (IOException e) { > 230: fail("Expecting zero exit code"); I think we should remove the try/catch block and let the IOException propagate. That way, if htis fails for whatever reason, we get the entire exception stacktrace. A comment before the `jar("--validate --file ...)` line can say that we except the `jar()` call to succeed with a zero exit code. test/jdk/tools/jar/ValidatorTest.java line 235: > 233: > 234: @Test > 235: public void testValidate() throws IOException { Perhaps rename to `testMultiManifestJar()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102361183 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102359049 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102361579 From pminborg at openjdk.org Thu May 22 11:52:34 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 11:52:34 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: > This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. > > This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. > > It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update benchmark to reflect new fill method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25383/files - new: https://git.openjdk.org/jdk/pull/25383/files/eadf067b..5c878bbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=03-04 Stats: 19 lines in 1 file changed: 4 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383 PR: https://git.openjdk.org/jdk/pull/25383 From jvernee at openjdk.org Thu May 22 11:59:01 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 22 May 2025 11:59:01 GMT Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov wrote: >> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual > > serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: > > 8357462: copyright update Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2860940487 From jpai at openjdk.org Thu May 22 11:59:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 11:59:02 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: <-RuOE8u98OK_ruRjXFgPQsWhOnB1aPSeh_0TeOVqmlQ=.4fc88805-062c-4619-8da2-81f9a026af0d@github.com> On Thu, 22 May 2025 01:29:12 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Validator to take a file, use term JAR file test/jdk/tools/jar/ValidatorTest.java line 293: > 291: } catch (IOException e) { > 292: var err = e.getMessage(); > 293: assertTrue(err.contains("Warning: Central directory and local file header entries are not in the same order")); Unlike in other tests, we are missing a `System.out.println(err)` before the assert here. test/jdk/tools/jar/ValidatorTest.java line 308: > 306: System.out.println(err); > 307: for (var entryName : invalidEntryNames) { > 308: assertTrue(err.contains("Warning: entry name " + entryName + " is not valid")); To help debug any failures, it might be better to include the entryName that failed the assert, something like: assertTrue(err.contains("Warning: entry name " + entryName + " is not valid"), "missing warning for " + entryName); test/jdk/tools/jar/ValidatorTest.java line 325: > 323: try { > 324: int rc = JAR_TOOL.run(jarOut, err, cmdline.split(" +")); > 325: if (rc != 0) { Nit - should we add a `System.out.println("exit code: " + rc);`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102370169 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102374499 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102379182 From pminborg at openjdk.org Thu May 22 12:00:55 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 12:00:55 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 11:52:34 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. >> >> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark to reflect new fill method Updated benchmarks: Base: Benchmark (ELEM_SIZE) Mode Cnt Score Error Units SegmentBulkFill.nativeSegmentFillJava 2 avgt 30 1.618 ? 0.060 ns/op SegmentBulkFill.nativeSegmentFillJava 3 avgt 30 1.602 ? 0.042 ns/op SegmentBulkFill.nativeSegmentFillJava 4 avgt 30 1.775 ? 0.070 ns/op SegmentBulkFill.nativeSegmentFillJava 5 avgt 30 1.759 ? 0.051 ns/op SegmentBulkFill.nativeSegmentFillJava 6 avgt 30 1.771 ? 0.051 ns/op SegmentBulkFill.nativeSegmentFillJava 7 avgt 30 1.785 ? 0.049 ns/op SegmentBulkFill.nativeSegmentFillJava 8 avgt 30 2.383 ? 0.061 ns/op (12 is estimated in the chart below) SegmentBulkFill.nativeSegmentFillJava 64 avgt 30 4.010 ? 0.255 ns/op SegmentBulkFill.nativeSegmentFillJava 512 avgt 30 6.622 ? 0.246 ns/op SegmentBulkFill.nativeSegmentFillJava 4096 avgt 30 44.431 ? 0.832 ns/op SegmentBulkFill.nativeSegmentFillJava 32768 avgt 30 331.429 ? 3.073 ns/op SegmentBulkFill.nativeSegmentFillJava 262144 avgt 30 4174.795 ? 76.096 ns/op SegmentBulkFill.nativeSegmentFillJava 2097152 avgt 30 33084.699 ? 53.530 ns/op SegmentBulkFill.nativeSegmentFillJava 16777216 avgt 30 298953.004 ? 11241.262 ns/op SegmentBulkFill.nativeSegmentFillJava 134217728 avgt 30 2857973.939 ? 128453.291 ns/op Patch: Benchmark (ELEM_SIZE) Mode Cnt Score Error Units SegmentBulkFill.nativeSegmentFillJava 2 avgt 30 1.322 ? 0.020 ns/op SegmentBulkFill.nativeSegmentFillJava 3 avgt 30 1.313 ? 0.009 ns/op SegmentBulkFill.nativeSegmentFillJava 4 avgt 30 1.323 ? 0.023 ns/op SegmentBulkFill.nativeSegmentFillJava 5 avgt 30 1.309 ? 0.006 ns/op SegmentBulkFill.nativeSegmentFillJava 6 avgt 30 1.310 ? 0.017 ns/op SegmentBulkFill.nativeSegmentFillJava 7 avgt 30 1.308 ? 0.004 ns/op SegmentBulkFill.nativeSegmentFillJava 8 avgt 30 1.312 ? 0.008 ns/op SegmentBulkFill.nativeSegmentFillJava 12 avgt 30 1.316 ? 0.025 ns/op SegmentBulkFill.nativeSegmentFillJava 64 avgt 30 3.829 ? 0.199 ns/op SegmentBulkFill.nativeSegmentFillJava 512 avgt 30 6.661 ? 0.077 ns/op ![image](https://github.com/user-attachments/assets/69462223-e967-4d37-b7fd-ac47d0e04db9) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900966164 From jpai at openjdk.org Thu May 22 12:07:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 May 2025 12:07:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> Message-ID: On Thu, 22 May 2025 01:29:12 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Validator to take a file, use term JAR file Hello Henry, thank you for this enhancement. Overall this looks very good to me, especially because the validation code is concise and very cleanly done. I only had some nits and minor clarifications in this review. Some parts of the test (like the usage of ISO_8859_1 charset) isn't clear to me, so I'll come back to that later. I'll focus on the CSR review now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24430#issuecomment-2900987846 From duke at openjdk.org Thu May 22 12:18:53 2025 From: duke at openjdk.org (duke) Date: Thu, 22 May 2025 12:18:53 GMT Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov wrote: >> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual > > serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: > > 8357462: copyright update @serhiysachkov Your change (at version 43bf37b5545866752925ca521b0477aa2babd60e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25355#issuecomment-2901017733 From liach at openjdk.org Thu May 22 12:27:02 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 12:27:02 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v5] In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> References: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> Message-ID: On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) wrote: >> Motivation: >> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. >> >> Modification: >> Add detail error messages. >> >> Result: >> Helpful messages. > > He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang There's a Hotspot Development section in the guide, maybe we need one for Java development that talks about IDE and such too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2901039155 From lancea at openjdk.org Thu May 22 12:27:56 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 22 May 2025 12:27:56 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 01:46:40 GMT, Lance Andersen wrote: >> I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations. > > Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate We are somewhat inconsistent in documenting the exit code from our commands as many do not include any mention A few for reference **java command**: > The following exit values are typically returned by the launcher when the launcher is called with the wrong arguments, serious errors, or exceptions thrown by the JVM. However, a Java application may choose to return any value by using the API call System.exit(exitValue). The values are: 0: Successful completion >0: An error occurred **jarsigner command**: > If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0. See https://docs.oracle.com/en/java/javase/24/docs/specs/man/jarsigner.html#errors-and-warnings for the full details **jshell command**: > /exit [integer-expression-snippet] > Exits the tool. If no snippet is entered, the exit status is zero. If a snippet is entered and the result of the snippet is an integer, the result is used as the exit status. If an error occurs, or the result of the snippet is not an integer, an error is displayed and the tool remains active. `% jshell | Welcome to JShell -- Version 22.0.1 | For an introduction type: /help intro jshell> System.out.print("hi"); hi jshell> /exit 1 | Goodbye (1) % echo $? 1 ` So, currently, the jdk commands use either: - exit code - exit value - exit status - exit with code I would probably go with either "exit status" or "exit value" And as I mentioned in a prior comment we should move away from non-zero and use either '>0' as java and several unix based commands do or use "greater than 0" **Note:** Other several commands such as jdeperscan do not specify the exit status value and I think we need to document the possible exit status values for the jdk commands and perhaps target this for jdk 26 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102431539 From syan at openjdk.org Thu May 22 12:33:01 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 May 2025 12:33:01 GMT Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov wrote: >> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual > > serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: > > 8357462: copyright update LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2861037754 From duke at openjdk.org Thu May 22 12:33:02 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 22 May 2025 12:33:02 GMT Subject: Integrated: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual In-Reply-To: References: Message-ID: <_f_SVjwteOc31dkU8Yl0UASgVgHWKx69jSeNg62MneQ=.4b70e59f-1f1f-45be-98f5-04095297d75e@github.com> On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov wrote: > Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual This pull request has now been integrated. Changeset: 428d33ef Author: Serhiy Sachkov Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/428d33ef3ca0af34d8f164fe9d9b722e81e866a7 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual Reviewed-by: jvernee, syan ------------- PR: https://git.openjdk.org/jdk/pull/25355 From rriggs at openjdk.org Thu May 22 13:18:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 22 May 2025 13:18:56 GMT Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe wrote: > Hi, please consider the following patch. > > This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc. > > This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens). > > Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409 > > This patch also fixes two subtle bugs: > - we didn't check the return value of the close() inside closeAllFileDescriptors > - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it) > > ---- > > Testing: > > We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC. > > - in the parent JVM, the test opens a file in native code without FD_CLOEXEC > - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open > > I verified that the test correctly detects a broken implementation that leaks file descriptors. > > I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX). > > I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green. Leaving it to 26 is good. One review is ok. If we were pushing for JDK 25, a second review would be warranted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25301#issuecomment-2901193939 From pminborg at openjdk.org Thu May 22 13:46:57 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 May 2025 13:46:57 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v5] In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> References: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com> Message-ID: On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) wrote: >> Motivation: >> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. >> >> Modification: >> Add detail error messages. >> >> Result: >> Helpful messages. > > He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang > - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java > > Co-authored-by: Viktor Klang Looks good to me. ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23050#pullrequestreview-2861300123 From vklang at openjdk.org Thu May 22 14:22:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 22 May 2025 14:22:58 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com> References: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com> <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com> Message-ID: On Thu, 22 May 2025 02:09:08 GMT, He-Pin(kerr) wrote: >> @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit. > > @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc. @He-Pin This PR is now ready to integrate, type "/integrate" (without the quotes) as a comment on this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2901412915 From vklang at openjdk.org Thu May 22 14:24:28 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 22 May 2025 14:24:28 GMT Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed Message-ID: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*. ------------- Commit messages: - Addressing a potential stall-induced test failure in ScheduledExecutorTest::testShutdownNow_delayedTasks Changes: https://git.openjdk.org/jdk/pull/25394/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357285 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25394/head:pull/25394 PR: https://git.openjdk.org/jdk/pull/25394 From liach at openjdk.org Thu May 22 14:27:59 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 14:27:59 GMT Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently [v2] In-Reply-To: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com> References: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com> Message-ID: <3dPOJ8aiXq0RrawctSyoDLc_UWh5fYfR_n8NmLsr8b0=.0f48dfdd-b916-4d8f-8683-2b099b3454e0@github.com> On Wed, 21 May 2025 17:09:29 GMT, Chen Liang wrote: >> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail. >> >> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well. >> >> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Increase timeout, add comment for adjust for debugging > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cv-test-problems > - Restore incorrectly removed annotation > - Fix problems with class value tests The failing tier 1 tests on GitHub are gc ones. Thanks for the reviews! I think we are good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25292#issuecomment-2901426835 From liach at openjdk.org Thu May 22 14:28:00 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 14:28:00 GMT Subject: Integrated: 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently In-Reply-To: References: Message-ID: On Sun, 18 May 2025 21:58:04 GMT, Chen Liang wrote: > The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail. > > Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well. > > Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug. This pull request has now been integrated. Changeset: 12efc1fe Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/12efc1fe3322d16f0e703b334912241d80dbaba9 Stats: 15 lines in 1 file changed: 6 ins; 6 del; 3 mod 8357165: test java/lang/invoke/ClassValueTest.java fails intermittently Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/25292 From myankelevich at openjdk.org Thu May 22 14:57:55 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 22 May 2025 14:57:55 GMT Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> Message-ID: On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang wrote: > Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*. test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java line 703: > 701: final ScheduledThreadPoolExecutor p = new ScheduledThreadPoolExecutor(1); > 702: List> tasks = new ArrayList<>(); > 703: final int DELAY = 100; What do you think of trying to change this to `Utils.adjustTimeout(100)` so the env could change this depending on the factor used? This way may be the delay won't need to be as large. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25394#discussion_r2102774011 From vklang at openjdk.org Thu May 22 15:02:53 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 22 May 2025 15:02:53 GMT Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed In-Reply-To: References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> Message-ID: On Thu, 22 May 2025 14:55:21 GMT, Mikhail Yankelevich wrote: >> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*. > > test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java line 703: > >> 701: final ScheduledThreadPoolExecutor p = new ScheduledThreadPoolExecutor(1); >> 702: List> tasks = new ArrayList<>(); >> 703: final int DELAY = 100; > > What do you think of trying to change this to `Utils.adjustTimeout(100)` so the env could change this depending on the factor used? This way may be the delay won't need to be as large. @myankelev The tasks are not expected to run, so the delay does not impact the duration of the test execution. The problem is rather that if they *do run* that the test fails, so if we move the delay further into the future, the test is less prone to failing spuriously. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25394#discussion_r2102782380 From aph at openjdk.org Thu May 22 15:09:12 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 22 May 2025 15:09:12 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8] In-Reply-To: References: Message-ID: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com> > Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a null argument. Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge from JDK head - Fix merge - Fix merge - Merge from https://github.com/openjdk/jdk - ScopedValue::orElse() does not accept null as an argument. - Remove unnecessary @since 25 - Remove unnecessary @enablePreview in some tests - Since when? - ScopedValue::orElse() does not accept null as an argument. - 8355720: Implement JEP 506: Scoped Values - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd ------------- Changes: https://git.openjdk.org/jdk/pull/24923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=07 Stats: 21 lines in 6 files changed: 3 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923 PR: https://git.openjdk.org/jdk/pull/24923 From nbenalla at openjdk.org Thu May 22 15:18:43 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 22 May 2025 15:18:43 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v2] In-Reply-To: References: Message-ID: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: revert changes to MethodType.java. foo markup should not be used ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25287/files - new: https://git.openjdk.org/jdk/pull/25287/files/b17b55fa..0653af94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287 PR: https://git.openjdk.org/jdk/pull/25287 From henryjen at openjdk.org Thu May 22 15:29:36 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 15:29:36 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v13] In-Reply-To: References: Message-ID: <7jkcv3sSX-L6EA-0JGC4cJE-u-_0cOzrwRJJ0ZTK2N4=.969da667-e338-44ec-9f93-7c989c47c9b9@github.com> > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Assure >0 exit code and fix typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/52af70aa..5118aba4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=11-12 Stats: 18 lines in 3 files changed: 2 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From smarks at openjdk.org Thu May 22 16:18:52 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 22 May 2025 16:18:52 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2] In-Reply-To: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com> References: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com> Message-ID: On Wed, 21 May 2025 16:48:20 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 67: >> >>> 65: * stdout.encoding}, in which case read operations use the {@code Charset} >>> 66: * designated by {@code stdin.encoding}. >>> 67: *

        >> >> `Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well. > > Good point. Brought the same wording to the `charset()` method description for further clarification. I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method. I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2102946359 From alanb at openjdk.org Thu May 22 16:28:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 May 2025 16:28:52 GMT Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> Message-ID: On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang wrote: > Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*. I think this looks okay and I assume you've testing with debug and -Xcomp to be confident that the tasks will never run. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25394#pullrequestreview-2861875933 From henryjen at openjdk.org Thu May 22 16:33:53 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 16:33:53 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v11] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 12:25:04 GMT, Lance Andersen wrote: >> Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate > > We are somewhat inconsistent in documenting the exit code from our commands as many do not include any mention > > A few for reference > > **java command**: > >> The following exit values are typically returned by the launcher when the launcher is called with the wrong arguments, serious errors, or exceptions thrown by the JVM. However, a Java application may choose to return any value by using the API call System.exit(exitValue). The values are: > > 0: Successful completion > > >0: An error occurred > > **jarsigner command**: > >> If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0. > > See https://docs.oracle.com/en/java/javase/24/docs/specs/man/jarsigner.html#errors-and-warnings for the full details > > **jshell command**: > >> /exit [integer-expression-snippet] >> Exits the tool. If no snippet is entered, the exit status is zero. If a snippet is entered and the result of the snippet is an integer, the result is used as the exit status. If an error occurs, or the result of the snippet is not an integer, an error is displayed and the tool remains active. > > `% jshell > | Welcome to JShell -- Version 22.0.1 > | For an introduction type: /help intro > > jshell> System.out.print("hi"); > hi > jshell> /exit 1 > | Goodbye (1) > % echo $? > 1 > ` > So, currently, the jdk commands use either: > > - exit code > - exit value > - exit status > - exit with code > > I would probably go with either "exit status" or "exit value" > > And as I mentioned in a prior comment we should move away from non-zero and use either '>0' as java and several unix based commands do or use "greater than 0" > > **Note:** > Other several commands such as jdeperscan do not specify the exit status value and I think we need to document the possible exit status values for the jdk commands and perhaps target this for jdk 26 For noun and verb, seems we have exit code and exit with code. Do we want to use status instead of code? I don't have a preference as long as we can agree to one. exit status and exit with status? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102974569 From alanb at openjdk.org Thu May 22 16:42:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 May 2025 16:42:54 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2] In-Reply-To: References: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com> Message-ID: On Thu, 22 May 2025 16:15:56 GMT, Stuart Marks wrote: >> Good point. Brought the same wording to the `charset()` method description for further clarification. > > I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method. > > I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method. I think I agree with Stuart and it would be better to say that stdin.encoding is used for reading, and stdout.encoding for writing. They are usually the same but if they differ then Console will return the charset for output. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2102987344 From liach at openjdk.org Thu May 22 16:44:56 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 16:44:56 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8] In-Reply-To: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com> References: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com> Message-ID: On Thu, 22 May 2025 15:09:12 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge from JDK head > - Fix merge > - Fix merge > - Merge from https://github.com/openjdk/jdk > - ScopedValue::orElse() does not accept null as an argument. > - Remove unnecessary @since 25 > - Remove unnecessary @enablePreview in some tests > - Since when? > - ScopedValue::orElse() does not accept null as an argument. > - 8355720: Implement JEP 506: Scoped Values > - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd The latest master merge looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2861915865 From jlu at openjdk.org Thu May 22 16:46:10 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 22 May 2025 16:46:10 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2] In-Reply-To: References: Message-ID: > _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25371/files - new: https://git.openjdk.org/jdk/pull/25371/files/ed0acc44..2d778a85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=00-01 Stats: 63 lines in 1 file changed: 12 ins; 16 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/25371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371 PR: https://git.openjdk.org/jdk/pull/25371 From jlu at openjdk.org Thu May 22 16:46:10 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 22 May 2025 16:46:10 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote: > _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. Comments addressed in https://github.com/openjdk/jdk/pull/25371/commits/2d778a85ebff14e5080a15556083c3e16986edf4. Chen, that's a good point, those getters are fragile. I opted to maintain the unmodifiable quality of the list fields, this code isn't perf sensitive and is more predictable this way. I wrapped the lists during parsing so we can drop overriding the getters altogether. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2901903043 From jrose at openjdk.org Thu May 22 16:49:52 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 22 May 2025 16:49:52 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 11:52:34 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. >> >> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark to reflect new fill method Very cool! I'm glad it worked. This came out of some background work I was doing to find fast ways to feed a vectorized loop over an input measured in bytes (any number of them). https://cr.openjdk.org/~jrose/jvm/PartialMemoryWord.cpp The corresponding read technique works quite well, also. It has the property that (if you combine the partial overlapping reads correctly) that each byte is read exactly once, which might be a good property for building concurrent data structures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2901911070 From henryjen at openjdk.org Thu May 22 17:08:58 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 17:08:58 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v12] In-Reply-To: <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com> References: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com> <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com> Message-ID: On Thu, 22 May 2025 11:42:04 GMT, Jaikiran Pai wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Validator to take a file, use term JAR file > > test/jdk/tools/jar/ValidatorTest.java line 60: > >> 58: import jdk.test.lib.util.FileUtils; >> 59: >> 60: @TestInstance(Lifecycle.PER_CLASS) > > I haven't seen this used commonly in our tests. Is there something specific in this test that requires this usage? I take this in as other jar tests. I think it's because we used to share the ZIP file between tests. I believe I can remove it for this test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2103031299 From duke at openjdk.org Thu May 22 17:11:08 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 22 May 2025 17:11:08 GMT Subject: Integrated: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 13:04:15 GMT, PAWAN CHAWDHARY wrote: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails This pull request has now been integrated. Changeset: 9ca1004e Author: pawan chawdhary Committer: Mikhailo Seledtsov URL: https://git.openjdk.org/jdk/commit/9ca1004e76a614328cd2eb7546143839c4d2f810 Stats: 118 lines in 3 files changed: 115 ins; 3 del; 0 mod 8352926: New test TestDockerMemoryMetricsSubgroup.java fails Reviewed-by: mseledtsov, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/24948 From liach at openjdk.org Thu May 22 17:17:59 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 17:17:59 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2] In-Reply-To: References: Message-ID: <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com> On Thu, 22 May 2025 16:46:10 GMT, Justin Lu wrote: >> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors Everything else looks good. src/java.base/share/classes/sun/util/locale/LanguageTag.java line 249: > 247: return EMPTY_SUBTAGS; > 248: } > 249: List extLangs = null; Do we want to name this `extLangs` or `extlangs`? The parsing method and the record uses `extlangs`. ------------- PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862000028 PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2103042373 From henryjen at openjdk.org Thu May 22 17:22:54 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 17:22:54 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v6] In-Reply-To: <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com> References: <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com> Message-ID: On Wed, 14 May 2025 17:27:25 GMT, Lance Andersen wrote: >> UTF-8 messed up the index, we don't want any conversion to happen. >> Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory >> Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory >> Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header >> Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header > >> UTF-8 messed up the index, we don't want any conversion to happen. Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header > > Without looking into this in finer detail I am not sure what the issue is and is why the other tests typically use the actual offset to modify. Simply put, a byte in the bytearray could be extend to more than one byte with UTF-8. The base we start to looking for the character is recorded as in the bytearray. Thus could lead we start looking at wrong place. I didn't look into exactly how this happens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2103056825 From srl at openjdk.org Thu May 22 17:32:53 2025 From: srl at openjdk.org (Steven Loomis) Date: Thu, 22 May 2025 17:32:53 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 16:46:10 GMT, Justin Lu wrote: >> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors @yumaoka ------------- PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2902033974 From liach at openjdk.org Thu May 22 17:36:52 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 17:36:52 GMT Subject: RFR: 8357178: Simplify Class::componentType [v2] In-Reply-To: References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: On Mon, 19 May 2025 00:22:08 GMT, Chen Liang wrote: >> `isArray` and null return is now redundant when `componentType` is changed to an explicit field. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > For parity with MT.descriptorString Can anyone review this simple cleanup? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2902042283 From naoto at openjdk.org Thu May 22 17:46:33 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 22 May 2025 17:46:33 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: > `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects wording change suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25271/files - new: https://git.openjdk.org/jdk/pull/25271/files/ce1c8035..75fa0a89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=03-04 Stats: 18 lines in 1 file changed: 1 ins; 6 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/25271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271 PR: https://git.openjdk.org/jdk/pull/25271 From naoto at openjdk.org Thu May 22 17:48:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 22 May 2025 17:48:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2] In-Reply-To: References: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com> Message-ID: On Thu, 22 May 2025 16:39:46 GMT, Alan Bateman wrote: >> I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method. >> >> I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method. > > I think I agree with Stuart and it would be better to say that stdin.encoding is used for reading, and stdout.encoding for writing. They are usually the same but if they differ then Console will return the charset for output. Thanks. I reworded the descriptions of the class and `charset()` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2103101604 From jlu at openjdk.org Thu May 22 17:51:32 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 22 May 2025 17:51:32 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3] In-Reply-To: References: Message-ID: > _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. 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 four additional commits since the last revision: - extLangs -> extlangs - Merge branch 'master' into JDK-8357281-LanguageTag - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25371/files - new: https://git.openjdk.org/jdk/pull/25371/files/2d778a85..a5429599 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=01-02 Stats: 43668 lines in 640 files changed: 29920 ins; 10197 del; 3551 mod Patch: https://git.openjdk.org/jdk/pull/25371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371 PR: https://git.openjdk.org/jdk/pull/25371 From jlu at openjdk.org Thu May 22 17:51:33 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 22 May 2025 17:51:33 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2] In-Reply-To: <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com> References: <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com> Message-ID: On Thu, 22 May 2025 17:14:03 GMT, Chen Liang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors > > src/java.base/share/classes/sun/util/locale/LanguageTag.java line 249: > >> 247: return EMPTY_SUBTAGS; >> 248: } >> 249: List extLangs = null; > > Do we want to name this `extLangs` or `extlangs`? The parsing method and the record uses `extlangs`. Changed to `extlangs`, more consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2103105426 From henryjen at openjdk.org Thu May 22 17:51:43 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 May 2025 17:51:43 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v14] In-Reply-To: References: Message-ID: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Minor tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/5118aba4..bf82d668 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=12-13 Stats: 7 lines in 3 files changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From liach at openjdk.org Thu May 22 18:07:52 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 18:07:52 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3] In-Reply-To: References: Message-ID: <_QUPLEkt0lQLzNp1Z7X1UO0LGGyRH1OIJzuRnlagEbU=.361cab70-0229-45f2-add7-54599c907a77@github.com> On Thu, 22 May 2025 17:51:32 GMT, Justin Lu wrote: >> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. > > 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 four additional commits since the last revision: > > - extLangs -> extlangs > - Merge branch 'master' into JDK-8357281-LanguageTag > - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors > - init This version looks much better. You might want the original author Yoshito or another I18N reviewer to check too. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862145268 From zuniquex at protonmail.com Thu May 22 18:12:17 2025 From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=) Date: Thu, 22 May 2025 18:12:17 +0000 Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler Message-ID: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com> Hi, recently I've come across the documentation of Proxy#getInvocationHandler(Object) and recognized that there's a missing throws declaration for a NullPointerException. The expression Proxy.getInvocationHandler(null) fails, because proxy.getClass() is called without asserting that proxy is not null. I'd be happy to provide the JavaDoc update, if anyone would like to sponsor me the JBS issue for this one. Cheers Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Thu May 22 18:24:51 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 18:24:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v2] In-Reply-To: References: Message-ID: <2NivjYQr_KiIrdCorX_x68nTNHezBA1qKvhjaDknI1E=.5da267a6-125d-49bf-9de3-4eaf9afbfcd6@github.com> On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to MethodType.java. foo markup should not be used Changes to MethodHandles look good. Please wait for a review from security developers for KEM.java. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2862198182 From naoto at openjdk.org Thu May 22 18:24:58 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 22 May 2025 18:24:58 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3] In-Reply-To: References: Message-ID: <_FIijEYTfFnkCAHDC8UFFYSUV4IBey5-im_qVyeqwtc=.2fe202af-bad4-46a9-8717-2d2f647bc91a@github.com> On Thu, 22 May 2025 17:51:32 GMT, Justin Lu wrote: >> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. > > 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 four additional commits since the last revision: > > - extLangs -> extlangs > - Merge branch 'master' into JDK-8357281-LanguageTag > - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors > - init LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862197819 From isipka at openjdk.org Thu May 22 18:40:50 2025 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 22 May 2025 18:40:50 GMT Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> Message-ID: On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov wrote: > Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CenSizeMaximum.java https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestMatrix.java https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java are all manual and https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java is not. local run starts fine. LGTM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25360#issuecomment-2902213413 From dl at openjdk.org Thu May 22 18:48:50 2025 From: dl at openjdk.org (Doug Lea) Date: Thu, 22 May 2025 18:48:50 GMT Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed In-Reply-To: References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> Message-ID: On Thu, 22 May 2025 14:59:04 GMT, Viktor Klang wrote: >> test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java line 703: >> >>> 701: final ScheduledThreadPoolExecutor p = new ScheduledThreadPoolExecutor(1); >>> 702: List> tasks = new ArrayList<>(); >>> 703: final int DELAY = 100; >> >> What do you think of trying to change this to `Utils.adjustTimeout(100)` so the env could change this depending on the factor used? This way may be the delay won't need to be as large. > > @myankelev The tasks are not expected to run, so the delay does not impact the duration of the test execution. The problem is rather that if they *do run* that the test fails, so if we move the delay further into the future, the test is less prone to failing spuriously. I agree. This change is the only one that comes to mind to make spurious failure much less likely. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25394#discussion_r2103199492 From asemenyuk at openjdk.org Thu May 22 19:53:22 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 22 May 2025 19:53:22 GMT Subject: RFR: 8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator Message-ID: - Allow to configure multiple expected installation exit codes for jpackage native packaging tests. - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators. ------------- Commit messages: - 8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator Changes: https://git.openjdk.org/jdk/pull/25400/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357171 Stats: 30 lines in 2 files changed: 18 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25400/head:pull/25400 PR: https://git.openjdk.org/jdk/pull/25400 From asemenyuk at openjdk.org Thu May 22 19:53:22 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 22 May 2025 19:53:22 GMT Subject: RFR: 8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator In-Reply-To: References: Message-ID: On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk wrote: > - Allow to configure multiple expected installation exit codes for jpackage native packaging tests. > - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/25400#issuecomment-2902384922 From serb at openjdk.org Thu May 22 20:04:01 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 22 May 2025 20:04:01 GMT Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused after JDK-8341402 Message-ID: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777): see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8 And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402): see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325 ------------- Commit messages: - Merge branch 'openjdk:master' into bigd - unused ONE_TENTH and ONE_HALF Changes: https://git.openjdk.org/jdk/pull/25339/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25339&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357401 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25339.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25339/head:pull/25339 PR: https://git.openjdk.org/jdk/pull/25339 From chen.l.liang at oracle.com Thu May 22 20:06:14 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 22 May 2025 20:06:14 +0000 Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler In-Reply-To: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com> References: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com> Message-ID: Hello, I have created https://bugs.openjdk.org/browse/JDK-8357597 for this. Your analysis isn't quite correct - if you look at the method documentation, you would anticipate this to fail with an IllegalArgumentException instead of a NullPointerException. However, this mismatch has been there since 2006, so it's best to update the docs to match the actual longstanding behavior. P.S. In the future, you can also report bugs via https://bugs.java.com/ Regard, Chen ________________________________ From: core-libs-dev on behalf of Steffen Nie?ing Sent: Thursday, May 22, 2025 1:12 PM To: core-libs-dev at openjdk.org Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler Hi, recently I've come across the documentation of Proxy#getInvocationHandler(Object) and recognized that there's a missing throws declaration for a NullPointerException. The expression Proxy.getInvocationHandler(null) fails, because proxy.getClass() is called without asserting that proxy is not null. I'd be happy to provide the JavaDoc update, if anyone would like to sponsor me the JBS issue for this one. Cheers Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Thu May 22 20:10:50 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 May 2025 20:10:50 GMT Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused after JDK-8341402 In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> Message-ID: On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov wrote: > Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777): > see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8 > And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402): > see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325 Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25339#pullrequestreview-2862445385 From liach at openjdk.org Thu May 22 20:10:51 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 20:10:51 GMT Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused after JDK-8341402 In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> Message-ID: On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov wrote: > Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777): > see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8 > And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402): > see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325 These are indeed unused. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25339#pullrequestreview-2862446799 From jrose at openjdk.org Thu May 22 20:27:01 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 22 May 2025 20:27:01 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Copyright format correction Nice! There's a nicely written loop tail that handles power-of-two chunks from 32 bytes (stpq) down to a single byte. Like many such tails, it is O(lg N), N being the max tail size, and that can be annoying when the loop tail is most or all of the work. One thing that sometimes helps is a count leading zeroes followed by a multiway switch at the start, or just before the tail, to get started at the right place in the tail (its log-size cascade), for very small inputs. This PR https://github.com/openjdk/jdk/pull/25383 uses clz in that way. It also uses an overlapping-store technique to reduce an O(lg N) tail to an O(1) tail, which also depends on the clz step. When atomicity is not an issue, the overlapping-store technique is faster on my MacBook M1. It lets you (say) store 7 bytes in two cycles and no extra branches. The downside is some bytes get stored twice (in the overlap), so it only works on unshared memory. My rough notes on the relative performance of overlapping loads and stores are here FWIW: https://cr.openjdk.org/~jrose/jvm/PartialMemoryWord.cpp BTW, overlapping loads (properly bit-masked) are just as atomic as loads of individual bytes, and much faster. But that's not the topic here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2902463076 From jrose at openjdk.org Thu May 22 20:30:51 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 22 May 2025 20:30:51 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 11:52:34 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. >> >> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark to reflect new fill method Related discussion at the hardware level: https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076 I think I want to look into the VM, see if it can use overlapping reads and writes as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2902478627 From kevin.bourrillion at oracle.com Thu May 22 20:33:15 2025 From: kevin.bourrillion at oracle.com (Kevin Bourrillion) Date: Thu, 22 May 2025 20:33:15 +0000 Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler In-Reply-To: References: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com> Message-ID: <439853F6-BF71-437F-94BC-DA1E7E9A71A1@oracle.com> I think Steffen is almost certainly right that this was an accidental omission. That omission results in the `@throws IAE` line being *interpreted* as also applying to null, but I doubt it was ever meant that way. I think adding a `@throws NPE` is the right fix, and makes the class more consistent, and also preserves the ability to migrate the argument type to `Object!` in the future. On May 22, 2025, at 1:06?PM, Chen Liang wrote: Hello, I have created https://bugs.openjdk.org/browse/JDK-8357597 for this. Your analysis isn't quite correct - if you look at the method documentation, you would anticipate this to fail with an IllegalArgumentException instead of a NullPointerException. However, this mismatch has been there since 2006, so it's best to update the docs to match the actual longstanding behavior. P.S. In the future, you can also report bugs via https://bugs.java.com/ Regard, Chen ________________________________ From: core-libs-dev on behalf of Steffen Nie?ing Sent: Thursday, May 22, 2025 1:12 PM To: core-libs-dev at openjdk.org Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler Hi, recently I've come across the documentation of Proxy#getInvocationHandler(Object) and recognized that there's a missing throws declaration for a NullPointerException. The expression Proxy.getInvocationHandler(null) fails, because proxy.getClass() is called without asserting that proxy is not null. I'd be happy to provide the JavaDoc update, if anyone would like to sponsor me the JBS issue for this one. Cheers Steffen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlu at openjdk.org Thu May 22 20:36:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 22 May 2025 20:36:52 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects wording change suggestions New wording is straightforward and looks good to me. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2862507794 From archie.cobbs at gmail.com Thu May 22 20:58:03 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 22 May 2025 15:58:03 -0500 Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: On Thu, May 22, 2025 at 3:31?PM John R Rose wrote: > > Update benchmark to reflect new fill method > > Related discussion at the hardware level: > > https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076 > This discussion spurred me to ask a dumb question. Apologies in advance, just trying to learn here... If I do this: import java.util.Arrays; public class ArrayFiller { public static void main(String[] args) { while (true) { final byte[] array = new byte[1000000]; Arrays.fill(array, (byte)0x42); } } } Will C2 compile Arrays.fill() into something that is more efficient than a byte-at-a-time loop like what appears in the source code? Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Thu May 22 21:28:53 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 22 May 2025 21:28:53 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> Message-ID: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com> On Thu, 15 May 2025 12:33:06 GMT, Raffaello Giulietti wrote: >>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? >> >> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case. > > FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France): > > - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark. > - U+00A0 (No-Break Space NBSP) preceding colon. > > Similar conventions are used in other French speaking countries. > No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. > This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed the Java unicode escape to UTF-8 for the localised message string. You propose restoring it to Java escape. I wouldn't be surprised if the next message drop reverses what you reversed. I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes since that is very much a Java thing. So you are probably making the translation job harder. So I am suggesting you leave all of the translation files as is. Which might mean withdrawing this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2103421828 From prr at openjdk.org Thu May 22 21:34:50 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 22 May 2025 21:34:50 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote: > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. Just speaking for the one client demo. Someone else will need to review the other 98% of this PR ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2862613813 From prr at openjdk.org Thu May 22 21:45:52 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 22 May 2025 21:45:52 GMT Subject: RFR: 8356977: UTF-8 cleanups In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie wrote: > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49: > 47: * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by > 48: *

        > 49: * MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false); This is javadoc inJava SE specification. As is the Action case below. I can't think of any actual harm from this change, so OK, but I am not seeing why it is needed. test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63: > 61: > 62: private static final String INSTRUCTIONS = > 63: "A string \u201C" + TEXT + "\u201D is drawn at eight different " I really don't like these tests being changed. It isn't part of the JDK build. People compile these in all sorts of locales. Please revert all the changes in the client tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338 PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874 From d.ukhlov at gmail.com Thu May 22 22:57:25 2025 From: d.ukhlov at gmail.com (Dmytro Ukhlov) Date: Fri, 23 May 2025 01:57:25 +0300 Subject: Reducing Classloader's parallelLockMap memory consumption proposal In-Reply-To: <8168f8c8-75c0-4158-b8d8-fcc4d495dced@oracle.com> References: <8168f8c8-75c0-4158-b8d8-fcc4d495dced@oracle.com> Message-ID: Hello Alan, Thank you for the useful information. Jenkins's class loader topology is hierarchical. I believe Jenkins can make its internal class loader implementations non-parallel capable. However, the problem persists because Jenkins pipelines are built on top of Groovy scripts. Running a pipeline requires the compilation and execution of Groovy scripts at runtime. When loading these dynamically generated classes (with unique names), the GroovyClassLoader first tries to load them from the parent class loader. As a result, a large number of lock objects are created throughout the class loader chain, all the way down to the PlatformClassLoader, which is parallel capable and cannot be modified. Additionally, Groovy performs class lookups via class loading. For example, if we have MyObject.name in a script, Groovy will attempt to load MyObject, java.lang.MyObject, java.util.MyObject, groovy.lang.MyObject, and so on. To summarize: The existing JDK java.lang.ClassLoader works well for traditional Java applications, but it causes memory leaks when using dynamic class loaders that load short-lived classes. It seems that we need a way to determine whether a class can be loaded from the parent class loader chain, and avoid calling parent.loadClass() if unnecessary - so as not to accumulate entries in parallelLockMap. If anyone has experience solving such issues, I would greatly appreciate it if you could share your insights. > > On 20/05/2025 03:42, Dmytro Ukhlov wrote: > > Hello! > > > > I created PR is scope of jenkins-core project: > > https://github.com/jenkinsci/jenkins/pull/10659 > > Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675 > > > > In this PR i propped to override > > protected Object getClassLoadingLock(String className) > > method and use weak references for lock objects > > > > Jenkins is a plugable platform, each plugin has its own class loader > > and its parallelLockMap may consume 10mb of RAM. As a result it might > > have 2gb overhead if ~200 plugins installed. > > > > Jenkins maintainers ask me to consider making this improvement in base > > This is an issue for "parallel capable" class loaders, esp. those that > don't directly delegate. I don't know what topology is used in the > Jenkins plugin class loaders and whether these class loader need to > parallel capable. > > Expunging entries isn't really feasible, at least not without changing > the spec. > > JDK-8005233 [1] has a write-up from David Holmes on this topic and a > prototype for "fully concurrent" class loaders. This work has been > parked for several years. Maybe some day it will get dusted off and a > JEP drafted (due to the significance). > > -Alan > > [1] https://bugs.openjdk.org/browse/JDK-8005233 From swen at openjdk.org Thu May 22 23:37:59 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 May 2025 23:37:59 GMT Subject: Integrated: 8353741: Eliminate table lookup in UUID.toString In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 13:18:50 GMT, Shaojin Wen wrote: > Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses. This pull request has now been integrated. Changeset: 796ec5e7 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/796ec5e7cfcfb20d76a3b48c0b369dc73250f7e4 Stats: 118 lines in 2 files changed: 87 ins; 27 del; 4 mod 8353741: Eliminate table lookup in UUID.toString Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/22928 From swen at openjdk.org Fri May 23 02:03:48 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 23 May 2025 02:03:48 GMT Subject: RFR: 8357081: Removed unused methods of HexDigits [v2] In-Reply-To: References: Message-ID: > In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge remote-tracking branch 'upstream/master' into hexdigits_202505 # Conflicts: # src/java.base/share/classes/jdk/internal/util/HexDigits.java - remove unused code ------------- Changes: https://git.openjdk.org/jdk/pull/25258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25258&range=01 Stats: 69 lines in 1 file changed: 0 ins; 69 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25258/head:pull/25258 PR: https://git.openjdk.org/jdk/pull/25258 From syan at openjdk.org Fri May 23 03:25:54 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 23 May 2025 03:25:54 GMT Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> Message-ID: <7bGhVY0UN6jkktKCsi5rw3qX9KbpFOSRTjAvTwR9jQU=.bf45d926-0720-4d74-a74f-b38622a45d8f@github.com> On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang wrote: > Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*. Hi, the test file `/test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java` seem do not have jtreg entry, is this test use for other jtreg tests. I found that this file has `main` function, how can I run this test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25394#issuecomment-2903135761 From smarks at openjdk.org Fri May 23 03:49:51 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 23 May 2025 03:49:51 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com> On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects wording change suggestions I may be overthinking this, but let me just toss this out there to get people's opinions. This changes the API of `jdk.internal.io.JdkConsoleProvider`. OK, this is an internal interface, so strictly speaking we can change it at will. But... do the IDEs use this to interface to implement their in-IDE terminal emulator? I'm not sure; maybe we should ask @lahodaj . Well, the IDEs can probably easily adapt based on the JDK version. Or, if we want to be nice, we can leave the two-arg `console` method in place and have a default implementation for the three-arg `console` method that just calls the two-arg method with one of the charsets. Might not be worth it though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2903161425 From iklam at openjdk.org Fri May 23 04:31:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 23 May 2025 04:31:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v12] In-Reply-To: References: Message-ID: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Fixed merge - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @erikj79 comments -- makefile indentation - Fixed merge - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=11 Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From duke at openjdk.org Fri May 23 04:33:36 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 23 May 2025 04:33:36 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v3] In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: > 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 PAWAN CHAWDHARY has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8354475 - Update TestDockerMemoryMetricsSubgroup.java remove extra space - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 ------------- Changes: https://git.openjdk.org/jdk/pull/24930/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=02 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24930/head:pull/24930 PR: https://git.openjdk.org/jdk/pull/24930 From darcy at openjdk.org Fri May 23 04:39:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 23 May 2025 04:39:51 GMT Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused after JDK-8341402 In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> Message-ID: <-t5arb9h32offk8tW-m2Nj9twg-bz5bOlp_5a-TB4gI=.be05f1b6-e045-4c0f-bd28-224318685793@github.com> On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov wrote: > Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777): > see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8 > And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402): > see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325 Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25339#pullrequestreview-2863134181 From alan.bateman at oracle.com Fri May 23 06:12:24 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 23 May 2025 07:12:24 +0100 Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler In-Reply-To: <439853F6-BF71-437F-94BC-DA1E7E9A71A1@oracle.com> References: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com> <439853F6-BF71-437F-94BC-DA1E7E9A71A1@oracle.com> Message-ID: On 22/05/2025 21:33, Kevin Bourrillion wrote: > I think Steffen is almost certainly right that this was an accidental > omission. That omission results in the `@throws IAE` line being > *interpreted* as also applying to null, but I doubt it was ever meant > that way. > > I think adding a `@throws NPE` is the right fix, and makes the class > more consistent, and also preserves the ability to migrate the > argument type to `Object!` in the future. As Chen notes, long standing behavior (since at least 2006) has been to throw NPE. Changing it to match an interpretation of the the IAE description will be noticed, maybe even break something. So yes, I think the NPE needs to be documented to align with the long standing behavior. -Alan From alanb at openjdk.org Fri May 23 08:21:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 May 2025 08:21:58 GMT Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8] In-Reply-To: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com> References: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com> Message-ID: On Thu, 22 May 2025 15:09:12 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a null argument. > > Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge from JDK head > - Fix merge > - Fix merge > - Merge from https://github.com/openjdk/jdk > - ScopedValue::orElse() does not accept null as an argument. > - Remove unnecessary @since 25 > - Remove unnecessary @enablePreview in some tests > - Since when? > - ScopedValue::orElse() does not accept null as an argument. > - 8355720: Implement JEP 506: Scoped Values > - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd CSR is approved, I think this update is ready to integrate. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2863611886 From per-ake.minborg at oracle.com Fri May 23 08:30:56 2025 From: per-ake.minborg at oracle.com (Per-Ake Minborg) Date: Fri, 23 May 2025 08:30:56 +0000 Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: Hi Archie! The C2 compiler can use automatic vectorization [1] to speed up such operations. You can watch my explanation of the concept in some of my recent presentations, e.g, [2] Best, Per YouTube Share your videos with friends, family, and the world youtu.be Automatic vectorization - Wikipedia Automatic vectorization, in parallel computing, is a special case of automatic parallelization, where a computer program is converted from a scalar implementation, which processes a single pair of operands at a time, to a vector implementation, which processes one operation on multiple pairs of operands at once. For example, modern conventional computers, including specialized supercomputers ... en.wikipedia.org [1] https://en.wikipedia.org/wiki/Automatic_vectorization [2] https://youtu.be/rXv2-lN5Xgk?t=1518 ________________________________ From: core-libs-dev on behalf of Archie Cobbs Sent: Thursday, May 22, 2025 10:58 PM To: John R Rose Cc: core-libs-dev at openjdk.org Subject: Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] On Thu, May 22, 2025 at 3:31?PM John R Rose > wrote: > Update benchmark to reflect new fill method Related discussion at the hardware level: https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076 This discussion spurred me to ask a dumb question. Apologies in advance, just trying to learn here... If I do this: import java.util.Arrays; public class ArrayFiller { public static void main(String[] args) { while (true) { final byte[] array = new byte[1000000]; Arrays.fill(array, (byte)0x42); } } } Will C2 compile Arrays.fill() into something that is more efficient than a byte-at-a-time loop like what appears in the source code? Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Fri May 23 09:10:13 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 23 May 2025 09:10:13 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v13] In-Reply-To: References: Message-ID: <4qOq3AQt4RJI9yPvjXJSva2ZMyhqSOLqH3ERDX8csBg=.0ddce86f-eaba-41fd-9677-10e2090edaf1@github.com> On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. >> >> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [x] Linux x86_64 server fastdebug, `all` >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > A bit more comments Closing in favor of https://git.openjdk.org/jdk/pull/25289. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2903787453 From davidalayachew at gmail.com Fri May 23 10:44:19 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 23 May 2025 06:44:19 -0400 Subject: Could someone answer this question about Gatherers? Message-ID: Hello Core Libs Dev Team, A post came up on StackOverflow recently that asked a question about Gatherers -- https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream Just raising it here, as I think the only folks equipped to answer that question are people already on this mailing list. Thank you for your time and help! David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssarathi at openjdk.org Fri May 23 11:45:02 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Fri, 23 May 2025 11:45:02 GMT Subject: RFR: 8357644: Add missing CPE statements Message-ID: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> Adds missing classpath exception in a couple of files. ------------- Commit messages: - Adding missing CPE Changes: https://git.openjdk.org/jdk/pull/25413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357644 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25413/head:pull/25413 PR: https://git.openjdk.org/jdk/pull/25413 From tvaleev at openjdk.org Fri May 23 12:28:36 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Fri, 23 May 2025 12:28:36 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v4] In-Reply-To: References: Message-ID: > Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: > https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html > The specification is mostly composed of Math.min/max and Collections.min/max specifications. > > The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. > > I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Make min and max generic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25297/files - new: https://git.openjdk.org/jdk/pull/25297/files/b750c3fa..38f9eb71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=02-03 Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297 PR: https://git.openjdk.org/jdk/pull/25297 From viktor.klang at oracle.com Fri May 23 12:56:33 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Fri, 23 May 2025 12:56:33 +0000 Subject: [External] : Could someone answer this question about Gatherers? In-Reply-To: References: Message-ID: Hi David, This definitely sounds like a bug, so I've opened: https://bugs.openjdk.org/browse/JDK-8357647 Thanks, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: David Alayachew Sent: Friday, 23 May 2025 12:44 To: Viktor Klang ; core-libs-dev Subject: [External] : Could someone answer this question about Gatherers? Hello Core Libs Dev Team, A post came up on StackOverflow recently that asked a question about Gatherers -- https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream Just raising it here, as I think the only folks equipped to answer that question are people already on this mailing list. Thank you for your time and help! David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Fri May 23 13:15:58 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 May 2025 13:15:58 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v12] In-Reply-To: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> References: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> Message-ID: <7V06iTghjLDxbNUVkjjhLzZ8qNJ54W74R10Iy_HE6M8=.17c02df0-4cd6-4b9b-a7ad-d1404c17c817@github.com> On Fri, 23 May 2025 04:31:39 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> [...] >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Fixed merge > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - @erikj79 comments -- makefile indentation > - Fixed merge > - @erikj79 comments > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2864370912 From erikj at openjdk.org Fri May 23 13:27:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 May 2025 13:27:53 GMT Subject: RFR: 8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator In-Reply-To: References: Message-ID: On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk wrote: > - Allow to configure multiple expected installation exit codes for jpackage native packaging tests. > - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25400#pullrequestreview-2864409725 From archie.cobbs at gmail.com Fri May 23 13:38:31 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Fri, 23 May 2025 08:38:31 -0500 Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: Hi Per, Thanks very much. Looks like there's lots of good info out there but I didn't really know where to start so I appreciate the references. -Archie On Fri, May 23, 2025 at 3:31?AM Per-Ake Minborg wrote: > Hi Archie! > > The C2 compiler can use *automatic vectorization* [1] to speed up such > operations. You can watch my explanation of the concept in some of my > recent presentations, e.g, [2] > > Best, Per > YouTube > Share your videos with friends, family, and the world > youtu.be > > Automatic vectorization - Wikipedia > > Automatic vectorization, in parallel computing, is a special case of > automatic parallelization, where a computer program is converted from a > scalar implementation, which processes a single pair of operands at a time, > to a vector implementation, which processes one operation on multiple pairs > of operands at once. For example, modern conventional computers, including > specialized supercomputers ... > en.wikipedia.org > [1] https://en.wikipedia.org/wiki/Automatic_vectorization > [2] https://youtu.be/rXv2-lN5Xgk?t=1518 > ------------------------------ > *From:* core-libs-dev on behalf of > Archie Cobbs > *Sent:* Thursday, May 22, 2025 10:58 PM > *To:* John R Rose > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can > be improved using overlaps [v5] > > On Thu, May 22, 2025 at 3:31?PM John R Rose wrote: > > > Update benchmark to reflect new fill method > > Related discussion at the hardware level: > > https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076 > > > This discussion spurred me to ask a dumb question. Apologies in advance, > just trying to learn here... > > If I do this: > > import java.util.Arrays; > public class ArrayFiller { > public static void main(String[] args) { > while (true) { > final byte[] array = new byte[1000000]; > Arrays.fill(array, (byte)0x42); > } > } > } > > Will C2 compile Arrays.fill() > > into something that is more efficient than a byte-at-a-time loop like what > appears in the source code? > > Thanks, > -Archie > > -- > Archie L. Cobbs > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Fri May 23 13:55:59 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 23 May 2025 13:55:59 GMT Subject: Integrated: 8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator In-Reply-To: References: Message-ID: On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk wrote: > - Allow to configure multiple expected installation exit codes for jpackage native packaging tests. > - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators. This pull request has now been integrated. Changeset: b07da7bc Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/b07da7bcdcd4d1bba1f6e922d8e606bd73879052 Stats: 30 lines in 2 files changed: 18 ins; 0 del; 12 mod 8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25400 From jpai at openjdk.org Fri May 23 13:57:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 May 2025 13:57:57 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v12] In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> References: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> Message-ID: On Wed, 21 May 2025 23:30:18 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > More tweaking... This looks good to me. I would have prefered not changing the intial value of a the `readOnly` field to `true`, because that would mean one less thing to be concerned about. However, I am not too sure if it makes a practical difference. So what you have I think is OK. I'll think about it a bit more later and if anything shows up, I think we can address it. I think this enhancement deserves a release note, so I have added that label to the JBS issue. Instructions for creating a release note are available here https://openjdk.org/guide/#release-notes. Thank you David for being patient with the back and forth discussions and reviews. Please wait for Alan and Lance to have a chance to look at the final state of this PR before integrating. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2864523197 From lancea at openjdk.org Fri May 23 14:24:52 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 23 May 2025 14:24:52 GMT Subject: RFR: 8356629: Incorrect use of {@linkplain} in java.sql In-Reply-To: References: Message-ID: On Sat, 17 May 2025 17:21:01 GMT, Nizar Benalla wrote: > Please review this trivial patch to fix a javadoc bug. > > TIA Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25286#pullrequestreview-2864609961 From weijun at openjdk.org Fri May 23 14:31:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 23 May 2025 14:31:52 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to MethodType.java. foo markup should not be used src/java.base/share/classes/javax/crypto/KEM.java line 711: > 709: * with the key encapsulation message so that the receiver is able to create > 710: * a matching decapsulator, it will be included as a byte array in the > 711: * {@link Encapsulated#params()} field inside the encapsulation output. Good catch. The text must have been added before we changed `Encapsulated` from a record to a normal class. Now that `params` is a method instead of a record field, please consider rewriting the sentence to something like it will be included as a byte array returned by the {@link Encapsulated#params()} method within the encapsulation output. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2104718909 From vklang at openjdk.org Fri May 23 14:56:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 23 May 2025 14:56:58 GMT Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed In-Reply-To: <7bGhVY0UN6jkktKCsi5rw3qX9KbpFOSRTjAvTwR9jQU=.bf45d926-0720-4d74-a74f-b38622a45d8f@github.com> References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> <7bGhVY0UN6jkktKCsi5rw3qX9KbpFOSRTjAvTwR9jQU=.bf45d926-0720-4d74-a74f-b38622a45d8f@github.com> Message-ID: On Fri, 23 May 2025 03:22:59 GMT, SendaoYan wrote: >> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*. > > Hi, the test file `/test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java` seem do not have jtreg entry, is this test use for other jtreg tests. I found that this file has `main` function, how can I run this test. @sendaoYan For simplicitly I typically execute the entire jdk_concurrent suite. You can get more granular if you want to, but it is trickier to get it done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25394#issuecomment-2904700844 From vklang at openjdk.org Fri May 23 14:56:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 23 May 2025 14:56:58 GMT Subject: Integrated: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com> Message-ID: On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang wrote: > Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*. This pull request has now been integrated. Changeset: 6a078204 Author: Viktor Klang URL: https://git.openjdk.org/jdk/commit/6a07820483bcf3e9d7df27ee496db43675f1c002 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8357285: JSR166 Test case testShutdownNow_delayedTasks failed Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/25394 From nbenalla at openjdk.org Fri May 23 14:59:07 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 23 May 2025 14:59:07 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v3] In-Reply-To: References: Message-ID: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: update javadoc based on feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25287/files - new: https://git.openjdk.org/jdk/pull/25287/files/0653af94..daaed6c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287 PR: https://git.openjdk.org/jdk/pull/25287 From weijun at openjdk.org Fri May 23 15:06:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 23 May 2025 15:06:52 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > update javadoc based on feedback The `KEM.java` change looks good to me. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2864755280 From lancea at openjdk.org Fri May 23 15:14:58 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 23 May 2025 15:14:58 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v12] In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> References: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> Message-ID: On Wed, 21 May 2025 23:30:18 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > More tweaking... src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1451: > 1449: } > 1450: int version; > 1451: if (o instanceof String) { Any reason to not use: > if (o instanceof String s) { if (s.equals("runtime")) { version = Runtime.version().feature(); } else else if (s.matches("^[1-9][0-9]*$")) { { version = Version.parse(s).feature();; } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2104803699 From vklang at openjdk.org Fri May 23 15:20:30 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 23 May 2025 15:20:30 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream Message-ID: While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size). Includes a regression test which yields an OOME if this change is omitted. ------------- Commit messages: - No forced sequential needed - Amends GatherSink to propagate that the resulting output is unknown (-1) rather than passing on the upstream size Changes: https://git.openjdk.org/jdk/pull/25418/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25418&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357647 Stats: 40 lines in 2 files changed: 37 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25418.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25418/head:pull/25418 PR: https://git.openjdk.org/jdk/pull/25418 From viktor.klang at oracle.com Fri May 23 15:26:08 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Fri, 23 May 2025 15:26:08 +0000 Subject: [External] : Could someone answer this question about Gatherers? In-Reply-To: References: Message-ID: I've opened a PR to prevent this from occurring: https://github.com/openjdk/jdk/pull/25418/files However, there's an argument to be made that an unbounded Spliterator (as obtained by Random::ints(?)) should not report the SIZED and SUBSIZED characteristics, as it is indeed not sized. I'll open a separate Issue for that next week. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Viktor Klang Sent: Friday, 23 May 2025 14:56 To: David Alayachew ; core-libs-dev Subject: Re: [External] : Could someone answer this question about Gatherers? Hi David, This definitely sounds like a bug, so I've opened: https://bugs.openjdk.org/browse/JDK-8357647 Thanks, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: David Alayachew Sent: Friday, 23 May 2025 12:44 To: Viktor Klang ; core-libs-dev Subject: [External] : Could someone answer this question about Gatherers? Hello Core Libs Dev Team, A post came up on StackOverflow recently that asked a question about Gatherers -- https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream Just raising it here, as I think the only folks equipped to answer that question are people already on this mailing list. Thank you for your time and help! David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Fri May 23 15:28:04 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 23 May 2025 11:28:04 -0400 Subject: [External] : Could someone answer this question about Gatherers? In-Reply-To: References: Message-ID: Ty vm. You don't think this has anything to do with my bug from 6 months ago, where the parallel stream caused OOME, but the sequential ones short-circuited correctly? I can pull up the thread if you don't recall. On Fri, May 23, 2025, 11:26?AM Viktor Klang wrote: > I've opened a PR to prevent this from occurring: > https://github.com/openjdk/jdk/pull/25418/files > > However, there's an argument to be made that an unbounded Spliterator (as > obtained by Random::ints(?)) should not report the SIZED and SUBSIZED > characteristics, as it is indeed not sized. I'll open a separate Issue for > that next week. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of > Viktor Klang > *Sent:* Friday, 23 May 2025 14:56 > *To:* David Alayachew ; core-libs-dev < > core-libs-dev at openjdk.org> > *Subject:* Re: [External] : Could someone answer this question about > Gatherers? > > Hi David, > > This definitely sounds like a bug, so I've opened: > https://bugs.openjdk.org/browse/JDK-8357647 > > Thanks, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* David Alayachew > *Sent:* Friday, 23 May 2025 12:44 > *To:* Viktor Klang ; core-libs-dev < > core-libs-dev at openjdk.org> > *Subject:* [External] : Could someone answer this question about > Gatherers? > > Hello Core Libs Dev Team, > > A post came up on StackOverflow recently that asked a question about > Gatherers -- > https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream > > > Just raising it here, as I think the only folks equipped to answer that > question are people already on this mailing list. > > Thank you for your time and help! > David Alayachew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Fri May 23 15:35:51 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 May 2025 15:35:51 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang wrote: > While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size). > > Includes a regression test which yields an OOME if this change is omitted. Looks sensible; an integrator may push an arbitrary number of items to the downstream. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25418#pullrequestreview-2864843391 From rriggs at openjdk.org Fri May 23 15:36:57 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 May 2025 15:36:57 GMT Subject: RFR: 8357081: Removed unused methods of HexDigits [v2] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 02:03:48 GMT, Shaojin Wen wrote: >> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge remote-tracking branch 'upstream/master' into hexdigits_202505 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/util/HexDigits.java > - remove unused code lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25258#pullrequestreview-2864845707 From duke at openjdk.org Fri May 23 15:56:02 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Fri, 23 May 2025 15:56:02 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang wrote: > While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size). > > Includes a regression test which yields an OOME if this change is omitted. src/java.base/share/classes/java/util/stream/GathererOp.java line 153: > 151: if (initializer != Gatherer.defaultInitializer()) // Optimization > 152: state = initializer.get(); > 153: sink.begin(-1); // GathererOp does not know the size of the output The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104886743 From liach at openjdk.org Fri May 23 16:00:52 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 May 2025 16:00:52 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 15:53:22 GMT, Johannes D?bler wrote: >> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size). >> >> Includes a regression test which yields an OOME if this change is omitted. > > src/java.base/share/classes/java/util/stream/GathererOp.java line 153: > >> 151: if (initializer != Gatherer.defaultInitializer()) // Optimization >> 152: state = initializer.get(); >> 153: sink.begin(-1); // GathererOp does not know the size of the output > > The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in? This sounds like `averageCharsPerByte` in `CharsetDecoder`. I first don't think we need the stream estimate for the integrater; also this probably deserves its own RFE instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104898276 From rriggs at openjdk.org Fri May 23 16:02:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 May 2025 16:02:52 GMT Subject: RFR: 8357178: Simplify Class::componentType [v2] In-Reply-To: References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: On Mon, 19 May 2025 00:22:08 GMT, Chen Liang wrote: >> `isArray` and null return is now redundant when `componentType` is changed to an explicit field. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > For parity with MT.descriptorString lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25280#pullrequestreview-2864932353 From vklang at openjdk.org Fri May 23 16:08:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 23 May 2025 16:08:52 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 15:53:22 GMT, Johannes D?bler wrote: >> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size). >> >> Includes a regression test which yields an OOME if this change is omitted. > > src/java.base/share/classes/java/util/stream/GathererOp.java line 153: > >> 151: if (initializer != Gatherer.defaultInitializer()) // Optimization >> 152: state = initializer.get(); >> 153: sink.begin(-1); // GathererOp does not know the size of the output > > The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in? @jdlib I guess that would depend on the definition of *value* and *cost* in this context. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104911643 From vklang at openjdk.org Fri May 23 16:08:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 23 May 2025 16:08:52 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 16:04:50 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/GathererOp.java line 153: >> >>> 151: if (initializer != Gatherer.defaultInitializer()) // Optimization >>> 152: state = initializer.get(); >>> 153: sink.begin(-1); // GathererOp does not know the size of the output >> >> The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in? > > @jdlib I guess that would depend on the definition of *value* and *cost* in this context. API modifications would definitely be its own thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104914259 From duke at openjdk.org Fri May 23 16:10:03 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Fri, 23 May 2025 16:10:03 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null Message-ID: `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE. ------------- Commit messages: - 8357597: Add throws declaration for NPE Changes: https://git.openjdk.org/jdk/pull/25419/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25419&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357597 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25419/head:pull/25419 PR: https://git.openjdk.org/jdk/pull/25419 From rriggs at openjdk.org Fri May 23 16:15:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 May 2025 16:15:56 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v7] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:31:16 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - More review updates > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Move intrinsic to be a subsection; just one most common function of the annotation > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java > > Co-authored-by: Raffaello Giulietti > - Shorter first sentence > - Updates, thanks to John > - Refine validation and defensive copying > - 8355223: Improve documentation on @IntrinsicCandidate The bulk of these comments belong in a design/rational doc for VM intrinsics, not in the javadoc of an annotation. ------------- PR Review: https://git.openjdk.org/jdk/pull/24777#pullrequestreview-2864975777 From duke at openjdk.org Fri May 23 16:16:51 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Fri, 23 May 2025 16:16:51 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 16:06:08 GMT, Viktor Klang wrote: >> @jdlib I guess that would depend on the definition of *value* and *cost* in this context. > > API modifications would definitely be its own thing. @viktorklang-ora, @liach I agree given the artificial starting point of the discussion - instead of a Gatherer the stackoverflow poster should have used `Stream.limit(long)` or `Random.ints(long streamSize, int , int)` to achieve the goal... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104949317 From rriggs at openjdk.org Fri May 23 16:18:50 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 May 2025 16:18:50 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null In-Reply-To: References: Message-ID: On Fri, 23 May 2025 16:05:08 GMT, Steffen Nie?ing wrote: > `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE. looks fine, will review the csr when its drafted. ------------- PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2864988003 From liach at openjdk.org Fri May 23 16:21:51 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 May 2025 16:21:51 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null In-Reply-To: References: Message-ID: On Fri, 23 May 2025 16:05:08 GMT, Steffen Nie?ing wrote: > `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE. I have created a CSR for this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25419#issuecomment-2905009702 From naoto at openjdk.org Fri May 23 16:28:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 May 2025 16:28:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com> References: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com> Message-ID: On Fri, 23 May 2025 03:47:32 GMT, Stuart Marks wrote: > But... do the IDEs use this to interface to implement their in-IDE terminal emulator? Can they even possibly do so? `java.base`'s `module-info` exports `jdk.internal.io` only to `jdk.internal.le` and `jdk.jshell`, so I think no other modules can implement it and be loaded at runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905030550 From asemenyuk at openjdk.org Fri May 23 16:33:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 23 May 2025 16:33:55 GMT Subject: RFR: 8357644: Add missing CPE statements In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> Message-ID: On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N wrote: > Adds missing classpath exception in a couple of files. Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25413#pullrequestreview-2865019628 From chen.l.liang at oracle.com Fri May 23 16:42:38 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 23 May 2025 16:42:38 +0000 Subject: [External] : Could someone answer this question about Gatherers? In-Reply-To: References: Message-ID: Yes, please pull it up. We have a patch ready at https://github.com/openjdk/jdk/pull/25418, and I can test if this patch fixes your said bug. ________________________________ From: core-libs-dev on behalf of David Alayachew Sent: Friday, May 23, 2025 10:28 AM To: Viktor Klang Cc: core-libs-dev Subject: Re: [External] : Could someone answer this question about Gatherers? Ty vm. You don't think this has anything to do with my bug from 6 months ago, where the parallel stream caused OOME, but the sequential ones short-circuited correctly? I can pull up the thread if you don't recall. On Fri, May 23, 2025, 11:26?AM Viktor Klang > wrote: I've opened a PR to prevent this from occurring: https://github.com/openjdk/jdk/pull/25418/files However, there's an argument to be made that an unbounded Spliterator (as obtained by Random::ints(?)) should not report the SIZED and SUBSIZED characteristics, as it is indeed not sized. I'll open a separate Issue for that next week. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Viktor Klang > Sent: Friday, 23 May 2025 14:56 To: David Alayachew >; core-libs-dev > Subject: Re: [External] : Could someone answer this question about Gatherers? Hi David, This definitely sounds like a bug, so I've opened: https://bugs.openjdk.org/browse/JDK-8357647 Thanks, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: David Alayachew > Sent: Friday, 23 May 2025 12:44 To: Viktor Klang >; core-libs-dev > Subject: [External] : Could someone answer this question about Gatherers? Hello Core Libs Dev Team, A post came up on StackOverflow recently that asked a question about Gatherers -- https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream Just raising it here, as I think the only folks equipped to answer that question are people already on this mailing list. Thank you for your time and help! David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Fri May 23 16:45:01 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 23 May 2025 16:45:01 GMT Subject: RFR: 8357644: Add missing CPE statements In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> Message-ID: On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N wrote: > Adds missing classpath exception in a couple of files. Thank you for fixing this! My sincere apologies for the trouble. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25413#issuecomment-2905075388 From davidalayachew at gmail.com Fri May 23 17:06:18 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 23 May 2025 13:06:18 -0400 Subject: [External] : Could someone answer this question about Gatherers? In-Reply-To: References: Message-ID: Sorry, I misremembered. What I was describing was not a bug, but a quirk of streams, where they aggressively pre-fetch on parallel, but not when sequential, causig an OOME on parallel streams. Not that it helps, but here it is in case you want to read it anyways. https://mail.openjdk.org/pipermail/core-libs-dev/2024-October/132207.html On Fri, May 23, 2025, 12:48?PM Chen Liang wrote: > Yes, please pull it up. We have a patch ready at > https://github.com/openjdk/jdk/pull/25418, and I can test if this patch > fixes your said bug. > ------------------------------ > *From:* core-libs-dev on behalf of David > Alayachew > *Sent:* Friday, May 23, 2025 10:28 AM > *To:* Viktor Klang > *Cc:* core-libs-dev > *Subject:* Re: [External] : Could someone answer this question about > Gatherers? > > Ty vm. > > You don't think this has anything to do with my bug from 6 months ago, > where the parallel stream caused OOME, but the sequential ones > short-circuited correctly? I can pull up the thread if you don't recall. > > On Fri, May 23, 2025, 11:26?AM Viktor Klang > wrote: > > I've opened a PR to prevent this from occurring: > https://github.com/openjdk/jdk/pull/25418/files > > However, there's an argument to be made that an unbounded Spliterator (as > obtained by Random::ints(?)) should not report the SIZED and SUBSIZED > characteristics, as it is indeed not sized. I'll open a separate Issue for > that next week. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of > Viktor Klang > *Sent:* Friday, 23 May 2025 14:56 > *To:* David Alayachew ; core-libs-dev < > core-libs-dev at openjdk.org> > *Subject:* Re: [External] : Could someone answer this question about > Gatherers? > > Hi David, > > This definitely sounds like a bug, so I've opened: > https://bugs.openjdk.org/browse/JDK-8357647 > > Thanks, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* David Alayachew > *Sent:* Friday, 23 May 2025 12:44 > *To:* Viktor Klang ; core-libs-dev < > core-libs-dev at openjdk.org> > *Subject:* [External] : Could someone answer this question about > Gatherers? > > Hello Core Libs Dev Team, > > A post came up on StackOverflow recently that asked a question about > Gatherers -- > https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream > > > Just raising it here, as I think the only folks equipped to answer that > question are people already on this mailing list. > > Thank you for your time and help! > David Alayachew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smarks at openjdk.org Fri May 23 17:20:58 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 23 May 2025 17:20:58 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com> Message-ID: On Fri, 23 May 2025 16:26:36 GMT, Naoto Sato wrote: > Can they even possibly do so? Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and it can easily be invoked or modified to allow use of those modules. I took a quick look at NetBeans and didn't see any references to `jdk.internal.io` though, so maybe I'm off base in thinking that they might be using it. I did have the impression that at least one of the IDEs had its own console provider implementation but this is anecdotal and I don't have any evidence of this. No need to worry about this now, then. Sorry for the distraction. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905196982 From smarks at openjdk.org Fri May 23 17:25:54 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 23 May 2025 17:25:54 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: <3PAzs0ls7IGYZmW5m4VM-wIpr_vq080rwXCunwgwe78=.5a2669e4-201d-478d-9c0d-951770b315de@github.com> On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects wording change suggestions Marked as reviewed by smarks (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2865165348 From jlahoda at openjdk.org Fri May 23 17:25:54 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 23 May 2025 17:25:54 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com> Message-ID: On Fri, 23 May 2025 17:18:40 GMT, Stuart Marks wrote: > > Can they even possibly do so? > > Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and it can easily be invoked or modified to allow use of those modules. I took a quick look at NetBeans and didn't see any references to `jdk.internal.io` though, so maybe I'm off base in thinking that they might be using it. I did have the impression that at least one of the IDEs had its own console provider implementation but this is anecdotal and I don't have any evidence of this. FWIW, I am not aware about NetBeans using JdkConsoleProvider. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905211226 From naoto at openjdk.org Fri May 23 17:30:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 May 2025 17:30:52 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects wording change suggestions IntelliJ seems to be going with `-Djdk.console=jdk.internal.le` option, instead of hacking into the system: https://mastodon.online/@tagir_valeev/109981464706470933 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905233081 From jlu at openjdk.org Fri May 23 17:46:58 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 May 2025 17:46:58 GMT Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 17:51:32 GMT, Justin Lu wrote: >> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. > > 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 four additional commits since the last revision: > > - extLangs -> extlangs > - Merge branch 'master' into JDK-8357281-LanguageTag > - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors > - init Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2905306305 From jlu at openjdk.org Fri May 23 17:46:59 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 May 2025 17:46:59 GMT Subject: Integrated: 8357281: sun.util.Locale.LanguageTag should be immutable In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote: > _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code. This pull request has now been integrated. Changeset: 2f530f89 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/2f530f89e0ee5ed5253125d0e9319b07103173f0 Stats: 191 lines in 3 files changed: 22 ins; 80 del; 89 mod 8357281: sun.util.Locale.LanguageTag should be immutable Reviewed-by: naoto, liach ------------- PR: https://git.openjdk.org/jdk/pull/25371 From serb at openjdk.org Fri May 23 18:20:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 23 May 2025 18:20:56 GMT Subject: Integrated: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused after JDK-8341402 In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com> Message-ID: On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov wrote: > Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777): > see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8 > And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402): > see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325 This pull request has now been integrated. Changeset: 236e1b6d Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/236e1b6d529771f44218b6a4e2693e234e6a4e09 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused after JDK-8341402 Reviewed-by: bpb, liach, darcy ------------- PR: https://git.openjdk.org/jdk/pull/25339 From naoto at openjdk.org Fri May 23 18:36:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 May 2025 18:36:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 16:48:44 GMT, Naoto Sato wrote: >> Created jline/jline3#1282. > > Thanks! JLine seems to incorporate the stdin encoding already, which is quick! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2105219623 From bpb at openjdk.org Fri May 23 18:44:42 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 May 2025 18:44:42 GMT Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v26] In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com> Message-ID: > Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: "input reader specific" -> "reader specific" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24728/files - new: https://git.openjdk.org/jdk/pull/24728/files/f9c732eb..1fc0cd3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=24-25 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728 PR: https://git.openjdk.org/jdk/pull/24728 From rriggs at openjdk.org Fri May 23 19:00:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 May 2025 19:00:52 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v4] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 12:28:36 GMT, Tagir F. Valeev wrote: >> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max specifications. >> >> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Make min and max generic src/java.base/share/classes/java/util/Comparator.java line 206: > 204: * @since 25 > 205: */ > 206: default U max(U a, U b) { The parameter names are o1 and o2 in the `compare` method min and max build on. Though a and b are used in the class javadoc example and x and y are used in the spec description. Can we be consistent in the API? (o1, o2) perhaps. Someday, the parameter names *may* be more significant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105250452 From bpb at openjdk.org Fri May 23 19:46:53 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 May 2025 19:46:53 GMT Subject: RFR: 8354450: A File should be invalid if an element of its name sequence ends with a space [v4] In-Reply-To: <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com> References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com> <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com> Message-ID: On Wed, 23 Apr 2025 21:50:46 GMT, Brian Burkhalter wrote: >> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8354450: Simplify test for " \" in path elements `continue;` ------------- PR Comment: https://git.openjdk.org/jdk/pull/24635#issuecomment-2905629157 From liach at openjdk.org Fri May 23 19:55:54 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 May 2025 19:55:54 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 11:52:34 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. >> >> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). >> >> This PR passes tier1, tier2, and tier3 on multiple platforms. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark to reflect new fill method Can we remove all meaningless `!Architecture.isLittleEndian()` calls and use the platform-specific endianness unsafe primitives instead? For compensation, we can add a check in each of fill2/fill3/fill4 that `assert value == Integer/Short/Long.reverseBytes(value)` if you think that is necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2905651428 From aturbanov at openjdk.org Fri May 23 20:39:52 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 23 May 2025 20:39:52 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v4] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 12:28:36 GMT, Tagir F. Valeev wrote: >> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: >> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html >> The specification is mostly composed of Math.min/max and Collections.min/max specifications. >> >> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. >> >> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Make min and max generic src/java.base/share/classes/java/util/Comparator.java line 200: > 198: * @param the type of the arguments and the result. > 199: * @return the larger of {@code a} and {@code b} according to this comparator. > 200: * @throws ClassCastException if the collection contains elements that are What 'collection' meaned here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105386536 From liach at openjdk.org Fri May 23 23:00:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 May 2025 23:00:55 GMT Subject: RFR: 8357178: Simplify Class::componentType [v2] In-Reply-To: References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: On Mon, 19 May 2025 00:22:08 GMT, Chen Liang wrote: >> `isArray` and null return is now redundant when `componentType` is changed to an explicit field. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > For parity with MT.descriptorString Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2905985750 From liach at openjdk.org Fri May 23 23:00:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 May 2025 23:00:55 GMT Subject: Integrated: 8357178: Simplify Class::componentType In-Reply-To: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com> Message-ID: On Sat, 17 May 2025 02:15:42 GMT, Chen Liang wrote: > `isArray` and null return is now redundant when `componentType` is changed to an explicit field. This pull request has now been integrated. Changeset: 070c84cd Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/070c84cd22485a93a562a7639439fb056e840861 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8357178: Simplify Class::componentType Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/25280 From vlivanov at openjdk.org Fri May 23 23:03:53 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 23 May 2025 23:03:53 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v6] In-Reply-To: References: <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com> Message-ID: On Tue, 20 May 2025 22:14:42 GMT, Kim Barrett wrote: >> src/java.base/share/classes/java/lang/ref/Reference.java line 366: >> >>> 364: >>> 365: /* Implementation of unintrinsified get(). Making get() native may lead >>> 366: * C2 to sometimes prefer the native implementation over the intrinsic. >> >> Can you share more details on this? > > See review thread slightly above here, specifically https://github.com/openjdk/jdk/pull/24315/files#r2094884157. > I've looked at the intrinsics for Object.clone() and Object.hashCode(), but only enough to decide I > understand the approach being taken here better than what's in those. As I understand, `JDK-8271862` was about migrating to non-virtual intrinsic method. In case of `Reference::get()`, you already have a virtual public method marked as `@IntrinsicCandidate`. And the patch doesn't change anything there. So, unless I miss something, I believe the comment is misleading. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2105506789 From sherman at openjdk.org Fri May 23 23:28:54 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 23 May 2025 23:28:54 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v12] In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> References: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> Message-ID: On Wed, 21 May 2025 23:30:18 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. >> >> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. >> >> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > More tweaking... Looks like I'm late to the party :-) My apologies if this has already been discussed a long time ago. My question is whether it's really necessary to restrict the 'read-only' flag to existing ZIP files only. I don't see any issue with allowing the creation of a new, empty ZIP file and marking it as read-only. Sure, it might be useless since it's just an empty zip file system, but that's up to the user. Not a very strong opinion though. 283 *

      • 284 * If the value is {@code "readOnly"}, the file system is created 285 * read-only, and {@link java.nio.file.FileSystem#isReadOnly() 286 * isReadOnly()} will always return {@code true}. Creating a 287 * read-only file system requires the underlying ZIP file to 288 * already exist. 289 * Specifying the {@code create} property as {@code true} with the 290 * {@code accessMode} as {@code readOnly} will cause an {@code 291 * IllegalArgumentException} to be thrown when creating the ZIP file 292 * system. 293 *
      • ------------- PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2906012555 From amenkov at openjdk.org Sat May 24 00:22:14 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 24 May 2025 00:22:14 GMT Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread dumps Message-ID: This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870). The update has been split into parts to simplify reviewing. The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread. Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality. Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo; sanity tier1 (this fix only) ------------- Commit messages: - initial fix Changes: https://git.openjdk.org/jdk/pull/25425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357650 Stats: 736 lines in 8 files changed: 733 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25425/head:pull/25425 PR: https://git.openjdk.org/jdk/pull/25425 From shaojin.wensj at alibaba-inc.com Sat May 24 01:00:21 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Sat, 24 May 2025 09:00:21 +0800 Subject: =?UTF-8?B?RGlnaXRMaXN0Ojp0b1N0cmluZyBtZXRob2QgY2F1c2luZyBpbmNvcnJlY3QgcmVzdWx0cyBk?= =?UTF-8?B?dXJpbmcgZGVidWdnaW5n?= Message-ID: When debugging getLong/getDouble/getDecimal of java.text.DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results. - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat May 24 01:36:54 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 24 May 2025 01:36:54 GMT Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with empty file data [v3] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 11:27:35 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799? >> >> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix. >> >> tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's suggestion - simplify argument creation, given just a handful number of argument values test/jdk/java/util/zip/ZipInputStream/ZipInputStreamCRCCheck.java line 136: > 134: System.out.println("tampered the crc value" > 135: + " from 0x" + Integer.toHexString(currentCRC) > 136: + " to 0x" + Integer.toHexString(bb.position(crcOffset).getInt())); Suggestion: System.out.format("tampered the crc value from 0x%x to 0x%x%n", currentCRC, bb.position(crcOffset).getInt()); The test code does not require high performance, we can System.out.format ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25116#discussion_r2105656655 From chen.l.liang at oracle.com Sat May 24 02:26:57 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sat, 24 May 2025 02:26:57 +0000 Subject: DigitList::toString method causing incorrect results during debugging In-Reply-To: References: Message-ID: Thanks for this report. This code is indeed very old - and probably back then, people thought sharing StringBuffer (which has since been migrated to StringBuilder) was a great idea. I checked the use site of the temp buffer - it appears to me that in the lifecycle of a DigitList, that buffer is usually only created and used once, and the cache would actually be more of a penalty than an optimization if that is the case. In addition, I don't find any usage of toString of DigitList. I think it should be fine to create a PR to end the sharing of these temp buffer - a patch that uses a new StringBuilder for DigitList.toString should be the safest, before I18N engineers can determine if we can remove the cache mechanism altogether. Chen ________________________________ From: core-libs-dev on behalf of wenshao Sent: Friday, May 23, 2025 8:00 PM To: core-libs-dev Subject: DigitList::toString method causing incorrect results during debugging When debugging getLong/getDouble/getDecimal of java.text.DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results. - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat May 24 02:46:00 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 24 May 2025 02:46:00 GMT Subject: RFR: 8357681: Fixed the DigitList::toString method causing incorrect results during debugging Message-ID: When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results. ------------- Commit messages: - minimal change - remove tempBuilder Changes: https://git.openjdk.org/jdk/pull/25288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25288&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357681 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25288/head:pull/25288 PR: https://git.openjdk.org/jdk/pull/25288 From liach at openjdk.org Sat May 24 03:02:53 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 24 May 2025 03:02:53 GMT Subject: RFR: 8357681: Fixed the DigitList::toString method causing incorrect results during debugging In-Reply-To: References: Message-ID: On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen wrote: > When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results. This change looks reasonable to me. I couldn't find any direct usage of DigitList::toString. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2906330880 From shaojin.wensj at alibaba-inc.com Sat May 24 03:47:15 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Sat, 24 May 2025 11:47:15 +0800 Subject: =?UTF-8?B?SW50ZWdlcjo6ZGlnaXRzIHNob3VsZCBiZSBkZWZpbmVkIGFzIGJ5dGVbXQ==?= Message-ID: Now Integer/Long uses Integer::digits to convert to byte, so we should define Integer::digits as byte[], which can avoid the conversion. - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Sat May 24 04:59:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 24 May 2025 04:59:51 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v6] In-Reply-To: References: <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com> Message-ID: On Fri, 23 May 2025 23:01:02 GMT, Vladimir Ivanov wrote: >> See review thread slightly above here, specifically https://github.com/openjdk/jdk/pull/24315/files#r2094884157. >> I've looked at the intrinsics for Object.clone() and Object.hashCode(), but only enough to decide I >> understand the approach being taken here better than what's in those. > > As I understand, `JDK-8271862` was about migrating to non-virtual intrinsic method. > In case of `Reference::get()`, you already have a virtual public method marked as `@IntrinsicCandidate`. And the patch doesn't change anything there. So, unless I miss something, I believe the comment is misleading. The comment is about why we have native `get0` at all, rather than just making `get` also be native. > [...] JDK-8271862 was about migrating to non-virtual intrinsic method. That's not a correct summary of JDK-8271862. That change was about migrating away from having a method that was all 3 of (1) intrinsic (2) native, and (3) virtual. It split that method into two parts, and allocated the properties to them in such a way that neither had all 3. There are several possible allocations of the properties to the methods that would have worked. In this case we already had all the machinary in place for `refersTo0` to be intrinsic and native, so the allocation that didn't require a bunch of renaming for consistency was to introduce `refersToImpl` to provide the virtual part. For this PR we have a method that is already intrinsic and virtual. Of course, we don't want to make it native too. Since we already have all the machinary in place for `get` to be intrinsic and virtual, the allocation that didn't require a bunch of renaming for consistency was to introduce native `get0` for use as the non-intrinsic implementation of `get`. See also here: https://github.com/openjdk/jdk/pull/24315#discussion_r2039137923 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2105706304 From stuefe at openjdk.org Sat May 24 05:59:25 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 24 May 2025 05:59:25 GMT Subject: RFR: 8357683: (process) SIGQUIT still blocked after JDK-8234262 with jdk.lang.Process.launchMechanism=FORK or VFORK Message-ID: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com> See bug description. We now unblock all signals in both FORK and POSIX_SPAWN launch modes. This fixes the problem and makes the behavior consistent across these two modes. I left the VFORK mode alone since I believe the signal state is still shared with the parent. One more reason to get rid of this mode soon (it's deprecated with 25 and will be removed with 26) The fix just moves the unblocking code from the jspawnhelper over to the child process function that is called for all three modes. ----- Testing: I did various manual tests. I also tested that test/jdk/java/lang/ProcessBuilder/UnblockSignals.java succeeds with both POSIX_SPAWN and FORK mode now and that the behavior is unchanged (still broken) for VFORK mode. ping @RogerRiggs I would like to get this still into JDK 25; the fix is small and clean enough to not worry me. ------------- Commit messages: - unblock signals in fork mode Changes: https://git.openjdk.org/jdk/pull/25428/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25428&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357683 Stats: 30 lines in 3 files changed: 20 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25428.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25428/head:pull/25428 PR: https://git.openjdk.org/jdk/pull/25428 From alanb at openjdk.org Sat May 24 06:31:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 May 2025 06:31:55 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v12] In-Reply-To: References: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com> Message-ID: On Fri, 23 May 2025 23:25:59 GMT, Xueming Shen wrote: > Looks like I'm late to the party :-) My apologies if this has already been discussed a long time ago. My question is whether it's really necessary to restrict the 'read-only' flag to existing ZIP files only. I don't see any issue with allowing the creation of a new, empty ZIP file and marking it as read-only. Sure, it might be useless since it's just an empty zip file system, but that's up to the user. Not a very strong opinion though. In the file system API, the "CREATE" option is specified to be ignored when opening a file for only reading. This means an I/O exception if the file doesn't exist. This was a pragmatic choice at the time that requires the full table of combinations and their outcome to see. For zipfs, the doing the same, or rejecting having the env contain both create=true and accessMode=readOnly, is okay. We chatted with David about this recently and agreed that rejecting this combination makes the most sense. It means someone has opt'ed it for both options, which is different to the file system API where it defaults to "READ" if none of the read/write/append options are provided. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2906503159 From chen.l.liang at oracle.com Sat May 24 06:37:12 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sat, 24 May 2025 06:37:12 +0000 Subject: Integer::digits should be defined as byte[] In-Reply-To: References: Message-ID: I have one concern with byte conversion - now the arguments to StringUTF16.putChar is sign extended instead of zero extended. We need to ensure sign extension does not affect the intrinsics, maybe need static asserts to ensure all elements of the digit byte arrays are positive so we won't run into trouble with signed vs zero extension. Once we can address this UTF16 risk, I think we are fine with the latin1 usages, and storing the digits as a byte array is indeed more memory efficient and is a good cleanup. Regards, Chen Liang ________________________________ From: core-libs-dev on behalf of wenshao Sent: Friday, May 23, 2025 10:47 PM To: core-libs-dev Subject: Integer::digits should be defined as byte[] Now Integer/Long uses Integer::digits to convert to byte, so we should define Integer::digits as byte[], which can avoid the conversion. - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat May 24 07:12:31 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 24 May 2025 07:12:31 GMT Subject: RFR: 8357685: Changing the type of Integer::digits from char[] to byte[] Message-ID: Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory. ------------- Commit messages: - char[] -> byte[] Changes: https://git.openjdk.org/jdk/pull/25426/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25426&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357685 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25426.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25426/head:pull/25426 PR: https://git.openjdk.org/jdk/pull/25426 From swen at openjdk.org Sat May 24 07:19:24 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 24 May 2025 07:19:24 GMT Subject: RFR: 8357685: Changing the type of Integer::digits from char[] to byte[] [v2] In-Reply-To: References: Message-ID: > Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: stable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25426/files - new: https://git.openjdk.org/jdk/pull/25426/files/c89694cb..3eb72204 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25426&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25426&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25426.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25426/head:pull/25426 PR: https://git.openjdk.org/jdk/pull/25426 From tvaleev at openjdk.org Sat May 24 07:34:39 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Sat, 24 May 2025 07:34:39 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v5] In-Reply-To: References: Message-ID: > Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: > https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html > The specification is mostly composed of Math.min/max and Collections.min/max specifications. > > The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. > > I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Update exception description; update argument names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25297/files - new: https://git.openjdk.org/jdk/pull/25297/files/38f9eb71..293b2c40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=03-04 Stats: 20 lines in 1 file changed: 2 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/25297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297 PR: https://git.openjdk.org/jdk/pull/25297 From tvaleev at openjdk.org Sat May 24 07:34:39 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Sat, 24 May 2025 07:34:39 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v4] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 20:37:05 GMT, Andrey Turbanov wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Make min and max generic > > src/java.base/share/classes/java/util/Comparator.java line 200: > >> 198: * @param the type of the arguments and the result. >> 199: * @return the larger of {@code a} and {@code b} according to this comparator. >> 200: * @throws ClassCastException if the collection contains elements that are > > What 'collection' meaned here? Good catch, thank you. The description was copied from `Collections::max`, which is not so appropriate here. I think it's better to copy it from `Comparator::compare` (also, added `@throws NPE` for consistency). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105747341 From tvaleev at openjdk.org Sat May 24 07:34:40 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Sat, 24 May 2025 07:34:40 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v4] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 18:57:45 GMT, Roger Riggs wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Make min and max generic > > src/java.base/share/classes/java/util/Comparator.java line 206: > >> 204: * @since 25 >> 205: */ >> 206: default U max(U a, U b) { > > The parameter names are o1 and o2 in the `compare` method min and max build on. > Though a and b are used in the class javadoc example and x and y are used in the spec description. > Can we be consistent in the API? (o1, o2) perhaps. Someday, the parameter names *may* be more significant. Done, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105746862 From stuefe at openjdk.org Sat May 24 10:05:10 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 24 May 2025 10:05:10 GMT Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() [v2] In-Reply-To: References: Message-ID: <1_5zQCiLjBsuUquWR3ucXwGQs_ZdqMVU70aMEBg9rTo=.ebb95bf5-4326-45c6-a374-b8ffac0da485@github.com> > Hi, please consider the following patch. > > This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc. > > This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens). > > Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409 > > This patch also fixes two subtle bugs: > - we didn't check the return value of the close() inside closeAllFileDescriptors > - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it) > > ---- > > Testing: > > We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC. > > - in the parent JVM, the test opens a file in native code without FD_CLOEXEC > - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open > > I verified that the test correctly detects a broken implementation that leaks file descriptors. > > I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX). > > I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green. Thomas Stuefe 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 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close- - close dir fd on fcntl error - Mark fds with cloexec, plus test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25301/files - new: https://git.openjdk.org/jdk/pull/25301/files/0e0d64a6..8543a5ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=00-01 Stats: 45124 lines in 663 files changed: 30512 ins; 11063 del; 3549 mod Patch: https://git.openjdk.org/jdk/pull/25301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301 PR: https://git.openjdk.org/jdk/pull/25301 From stuefe at openjdk.org Sat May 24 10:15:44 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 24 May 2025 10:15:44 GMT Subject: RFR: 8357683: (process) SIGQUIT still blocked after JDK-8234262 with jdk.lang.Process.launchMechanism=FORK or VFORK [v2] In-Reply-To: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com> References: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com> Message-ID: > See bug description. We now unblock all signals in both FORK and POSIX_SPAWN launch modes. This fixes the problem and makes the behavior consistent across these two modes. > > I left the VFORK mode alone since I believe the signal state is still shared with the parent. One more reason to get rid of this mode soon (it's deprecated with 25 and will be removed with 26) > > The fix just moves the unblocking code from the jspawnhelper over to the child process function that is called for all three modes. > > ----- > > Testing: I did various manual tests. I also tested that test/jdk/java/lang/ProcessBuilder/UnblockSignals.java succeeds with both POSIX_SPAWN and FORK mode now and that the behavior is unchanged (still broken) for VFORK mode. > > ping @RogerRiggs I would like to get this still into JDK 25; the fix is small and clean enough to not worry me. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8357683-process-SIGQUIT-still-blocked-after-JDK-8234262-with-jdk-lang-Process-launchMechanism=FORK-or-VFORK - unblock signals in fork mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25428/files - new: https://git.openjdk.org/jdk/pull/25428/files/6e759200..0744f5b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25428&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25428&range=00-01 Stats: 732 lines in 27 files changed: 298 ins; 297 del; 137 mod Patch: https://git.openjdk.org/jdk/pull/25428.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25428/head:pull/25428 PR: https://git.openjdk.org/jdk/pull/25428 From orionllmain at gmail.com Sat May 24 10:35:59 2025 From: orionllmain at gmail.com (Zheka Kozlov) Date: Sat, 24 May 2025 15:35:59 +0500 Subject: Finding max or min of exactly two objects In-Reply-To: References: Message-ID: Collections.max(List.of(a, b))? On Tue, May 13, 2025 at 7:12?PM Tagir Valeev wrote: > The alternatives we have now: > BinaryOperator.maxBy(Comparator.naturalOrder()).apply(a, b); > This speaks clearly about the intent (we'd like to get the maximum and we > write 'maxBy') but very wordy. > > Stream.of(a, b).max(Comparator.naturalOrder()).get(); > Also clear and a little bit shorter, but has an unnecessary Optional > in-between (we know that we have at least one element, so the result is > always present) and we have to mention the comparator. Finally, it might be > much less efficient than expected. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgiulietti at openjdk.org Sat May 24 11:33:50 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 24 May 2025 11:33:50 GMT Subject: RFR: 8357685: Change the type of Integer::digits from char[] to byte[] [v2] In-Reply-To: References: Message-ID: <_CeVJknp399J9ellTJ3b_hYgqumGHNo9pyypvedtWIE=.c0d8e795-16dd-4b5f-a6bc-64284016c221@github.com> On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen wrote: >> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > stable @liach Chen, you were [concerned](https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/146655.html) that the fact that StringUTF16.putChar does sign extension might introduce errors. I don't think there's any issue here, as all bytes are just ASCII. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25426#issuecomment-2906784048 From dl at openjdk.org Sat May 24 11:39:01 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 24 May 2025 11:39:01 GMT Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown Message-ID: Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException. ------------- Commit messages: - undo wrong origin - Handle IllegalStateException from SharedThreadContainer.start - Reveert for master - Handle IllegalStateException thrown by SharedThreadContainer.start Changes: https://git.openjdk.org/jdk/pull/25431/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25431&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357146 Stats: 32 lines in 2 files changed: 25 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25431.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25431/head:pull/25431 PR: https://git.openjdk.org/jdk/pull/25431 From rgiulietti at openjdk.org Sat May 24 11:48:50 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 24 May 2025 11:48:50 GMT Subject: RFR: 8357685: Change the type of Integer::digits from char[] to byte[] [v2] In-Reply-To: References: Message-ID: On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen wrote: >> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > stable LGTM @wenshao Please wait for @liach to chime in before integrating. ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25426#pullrequestreview-2866268850 From duke at openjdk.org Sat May 24 14:21:51 2025 From: duke at openjdk.org (duke) Date: Sat, 24 May 2025 14:21:51 GMT Subject: RFR: 8357644: Add missing CPE statements In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> Message-ID: <-Mzt3yKum66jRPdxCy4z0c5biCuGrt8Rf-FFrcT6YN0=.2e4b8042-e224-4bf1-a385-00504073ef96@github.com> On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N wrote: > Adds missing classpath exception in a couple of files. @Sorna-Sarathi Your change (at version 1778c756b997c47938fff1bf15bb8c6b5b855af5) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25413#issuecomment-2906857408 From markus at headcrashing.eu Sat May 24 14:37:15 2025 From: markus at headcrashing.eu (Markus KARG) Date: Sat, 24 May 2025 16:37:15 +0200 Subject: RFC: 8357183: Improving efficiency of Writer::append(CharSequence) and Writer::append(CharSequence, int, int) / Sub Task of 8356679: Using CharSequence::getChars internally In-Reply-To: References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> Message-ID: Chen, thank you for your approval for a DRAFT PR. Following your proposal, I have published a DRAFT PR at https://github.com/openjdk/jdk/pull/25432 so everybody can see what the actual intended code change looks like, and better focus on that actual code change and its risks and benefits. The intention of that DRAFT PR explicitly is NOT to request code reviews, but solely to serve as a publicly visible piece of code to support the ongoing discussion here on this mailing list. TARGET VERSION: 26 As we are near to JDK 25 GA, the target is inclusion into JDK 26 or later, so no need to rush. Nevertheless, I would be happy if everybody comments ASAP (at least briefly) to keep this discussion alive. PRELIMINARY RISK ANALYSIS: LOW Given the changes at hand now, I have performed a brief corpus analysis using Github Copilot (using the public Code Repositories of OpenJDK itself, but also the repositories of Apache Foundation and Eclipse Foundation) to see if the proposed change implies REAL risk due to its change of behavior. The result was that Github Copilot was UNABLE to find at least one single Java class that would fail after the proposed change of this draft PR. While many classes extend Writer directly or indirectly, only few have (nor their super- nor subclasses) an implementation of the now skipped methods write(String) or write(String, int, int). Those that do have (nor their super- nor subclasses) are NOT receiving append(CharSequence) or append(CharSequence, int, int) calls, or they (or their super- or subclasses) implement write(String) or write(String, int, int) as an alias to append(CharSequence) or append(CharSequence, int, int) - hence they already explicitly do what the DRAFT PR proposes to do implicitly in future. So at least for this brief analysis, the ACTUAL risk to break existing code seems to be rather small actually (in contrast to the ASSUMED risk looking at "append" being there since JDK 5). NB: Having said that, one such class WAS actually found by Github Copilot, but I explicitly removed it from the search result, as I already knew it is still working correctly, as it is an internal "sun" class of OpenJDK which I have already visited manually in preparation of this PR. NEXT STEPS * Please anybody take note of the code change found in the DRAFT PR at https://github.com/openjdk/jdk/pull/25432 in the next few weeks to see if anything prevents us from turning this PR from the DRAFT state into the RFR state. * Unless this discussion points us towards dropping the DRAFT PR, in the next weeks eventually I will open a CSR for approval of the behavior change, basing on the result of the attended brief corpus analysis. Thanks everybody for sharing your comments! -Markus Am 18.05.2025 um 22:50 schrieb Chen Liang: > Hi Markus, > I think you can submit a draft PR - while some people here like Alan > Bateman use draft PRs to indicate "not ready for any review" and > discussions are not forwarded to the mailing lists, they are still > very useful for looking at the change set. > > Note that we are a few short weeks from RDP1 of 25 - while I also wish > improvements can be integrated into the JDK, there is no guarantee > that they will make 25, and we shouldn't rush changes in order to > catch up with a release train. > > Regards, Chen > ------------------------------------------------------------------------ > *From:* core-libs-dev on behalf of > Markus KARG > *Sent:* Sunday, May 18, 2025 10:09 AM > *To:* core-libs-dev at openjdk.org > *Subject:* Re: RFC: 8356679: Using CharSequence::getChars internally > Roger, > > thank you for your comments. > > Following your advice I have splitted the larger work of JDK-8356679 > into sub tasks. > > I would like to start with a first PR implementing the *foundational* > work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For > convenience, attached below is a copy of the description. > > Comments Welcome! > > If everybody is fine with this, I would be happy to get some +1 to > publish the PR for JDK-8357183! > > Am 14.05.2025 um 15:57 schrieb Roger Riggs: > > Hi Markus, > > > > Starting out with the common case is a good idea for the first PR. > > > > I much prefer a PR with a single goal and that comes to a conclusion > > and does not add new features or changes after the PR is submitted. > > I tend to lose interest in PRs with lots of churn, it means I have to > > re-review the bulk of it when there is a change and may wait days to > > let it settle down before coming back to it. > > > > I tend to think the PR was not really ready to be reviewed if simple > > issues and corrections have to be made frequently. > > Do your own checking for typos and copyrights and simple refactoring > > before opening the PR. > > Quality before quantity or speed. > > > > I'm fine with separate Jira issues that clearly delineate a specific > > scope and goal. > > > > The title of this issue (8356679) doesn't identify the real goal. > > It seems to be to improve performance or memory usage, not just to use > > a new API. > > > > These are my personal opinions about contributions and process. > > > > Regards, Roger > > > > > > On 5/14/25 6:48 AM, Markus KARG wrote: > >> Many of the modified classes derive from a common super class and > >> share one needed common change (which is one of the points which are > >> easy to see once you see all of those classes in a single PR, but > >> hard to explain in plaint-text pre-PR mailing list threads), so at > >> least those need to be discussed *together*. But to spare JBS and > >> PRs, I can open the PR with just the first set of changes, and once > >> we agree that this set is fine, I can push the next commit *in the > >> same PR*. Otherwise we would need endless JBS, mailing list threads, > >> and PRs, just to fixe a dozen internal code lines. > >> > >> Having said that, does the current state of this thread count as > >> "reached common agreement to file a PR" or do I still have to wait > >> until more people chime in? > >> > >> -Markus > >> > >> > >> Am 13.05.2025 um 15:10 schrieb Roger Riggs: > >>> Hi Markus, > >>> > >>> A main point was to avoid trying to do everything at once. > >>> The PR comments become hard to follow and intermingled and it takes > >>> longer to get agreement because of the thrash in the PR. > >>> > >>> Roger > >>> > >>> On 5/13/25 5:05 AM, Markus KARG wrote: > >>>> Thank you, Roger. > >>>> > >>>> Actually the method helps in the "toString()" variants, too, as in > >>>> some places we could *get rid* of "toString()" (which is more work > >>>> than "just" a buffer due to the added compression complexity). > >>>> > >>>> In fact, I already took the time to rewrite *all* of them while > >>>> waiting for the approval of this list posting. In *all* cases > >>>> *less* buffering / copying is needed, and *less* "toString()" > >>>> conversion (which is a copy under the hood) is needed. So if I > >>>> would be allowed to show the code as a PR, it would be much easier > >>>> to explain and discuss. > >>>> > >>>> A PR is the best place to discuss "how to code would change". In > >>>> the worst case, let's drop it if we see that it is actually a bad > >>>> thing. > >>>> > >>>> -Markus > >>>> > >>>> > >>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs: > >>>>> Hi Markus, > >>>>> > >>>>> On the surface, its looks constructive. > >>>>> I suspect that many of these cases will turn into discussions > >>>>> about the right/best/better way to buffer the characters. > >>>>> The getChars method only helps when extracting to a char array, > >>>>> many of the current implementations create strings as the > >>>>> intermediary. The advantage of the 1 character at a time technique > >>>>> is not needing a (separated allocated) buffer. > >>>>> Consider taking a few at a time before launching into the whole set. > >>>>> > >>>>> $.02, Roger > >>>>> > >>>>> On 5/11/25 2:45 AM, Markus KARG wrote: > >>>>>> Dear Core Libs Team, > >>>>>> > >>>>>> I am hereby requesting comments on JDK-8356679. > >>>>>> > >>>>>> I would like to invest some time and set up a PR implementing > >>>>>> Chen Liangs's proposal laid out in > >>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your > >>>>>> convenience, the text of that JBS is copied below. According to > >>>>>> the Developer's Guide I do need to get broad agreement BEFORE > >>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show > >>>>>> consent, so I may file a PR. > >>>>>> > >>>>>> Thanks > >>>>>> -Markus > >>>>>> > >>>>>> > >>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679: > >>>>>> > >>>>>> Recently OpenJDK adopted the new method > >>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in > >>>>>> Java 25. As a bulk reader method, it allows potentially improved > >>>>>> efficiency over the previously available char-by-char reader > >>>>>> method CharSequence::charAt(int). > >>>>>> > >>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing > >>>>>> list to use the new method within the internal source code of > >>>>>> OpenJDK for the implementation of Appendables (see > >>>>>> > https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). > >>>>>> The idea behind this is that the implementations might be more > >>>>>> efficient then. > >>>>>> > >>>>>> A quick analysis of the OpenJDK source code identified (at least) > >>>>>> the following classes which could potentially run more efficient > >>>>>> when using CharSequence::getChars internally, thanks to bulk > >>>>>> reading and / or prevention of internal copies / toString() > >>>>>> conversions: > >>>>>> * java.io.Writer > >>>>>> * java.io.StringWriter > >>>>>> * java.io.PrintWriter > >>>>>> * java.io.BufferedWriter > >>>>>> * java.io.CharArrayWriter > >>>>>> * java.io.FileWriter > >>>>>> * java.io.OutputStreamWriter > >>>>>> * sun.nio.cs.StreamEncoder > >>>>>> * java.io.PrintStream > >>>>>> * java.nio.CharBuffer > >>>>>> > >>>>>> In the sense of "eat your own dog food", it makes sense to > >>>>>> implement Chen's idea in (at least) those classes. Possibly more > >>>>>> classes could get identified when taking a deeper look. Besides > >>>>>> the potential efficiency improvements, it would be a good show > >>>>>> case for the usage of the new API. > >>>>>> > >>>>>> The risk of this change should be low, as test coverage exists, > >>>>>> and as the intended changes are solely internal to the > >>>>>> implementation. No API will get changed. In some cases the > >>>>>> JavaDocs will get slightly adapted where it currently exposes the > >>>>>> actual implementation (to not lie in future). > >>>>>> > >>>>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssarathi at openjdk.org Sat May 24 15:08:58 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Sat, 24 May 2025 15:08:58 GMT Subject: Integrated: 8357644: Add missing CPE statements In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com> Message-ID: On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N wrote: > Adds missing classpath exception in a couple of files. This pull request has now been integrated. Changeset: 1f24a541 Author: Sorna Sarathi N Committer: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/1f24a5414d735f9faaabd5b49f786419a40d9da5 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod 8357644: Add missing CPE statements Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/25413 From alanb at openjdk.org Sat May 24 15:59:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 May 2025 15:59:57 GMT Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown In-Reply-To: References: Message-ID: On Sat, 24 May 2025 11:35:33 GMT, Doug Lea
        wrote: > Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3475: > 3473: ds = delayScheduler = null; > 3474: unlockRunState(); > 3475: tryTerminate(false, false); This reset okay, and the schedule methods will throw REE. The change makes me wonder about the OOME "unable to create new native thread" scenario, should the schedule methods propagate it or throw REE with the OOME as cause? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25431#discussion_r2105868632 From liach at openjdk.org Sat May 24 16:06:50 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 24 May 2025 16:06:50 GMT Subject: RFR: 8357685: Change the type of Integer::digits from char[] to byte[] [v2] In-Reply-To: References: Message-ID: On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen wrote: >> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > stable Just noted java compiler has lossy conversion warning, so if we have a >127 char literal in the array initializer, we would encounter a compile error. All good to me. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25426#pullrequestreview-2866371571 From swen at openjdk.org Sat May 24 17:10:56 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 24 May 2025 17:10:56 GMT Subject: Integrated: 8357081: Removed unused methods of HexDigits In-Reply-To: References: Message-ID: On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen wrote: > In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods This pull request has now been integrated. Changeset: b0373537 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/b037353734fd67f8898eb797a041bc1152a18178 Stats: 69 lines in 1 file changed: 0 ins; 69 del; 0 mod 8357081: Removed unused methods of HexDigits Reviewed-by: rriggs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/25258 From shaojin.wensj at alibaba-inc.com Sat May 24 17:55:30 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Sun, 25 May 2025 01:55:30 +0800 Subject: =?UTF-8?B?QWRkIEBTdGFibGUgdG8gamF2YS5sYW5nLkNoYXJhY3RlckRhdGFMYXRpbjEgYW5kIG90aGVy?= =?UTF-8?B?IENoYXJhY3RlckRhdGEgY2xhc3Nlcw==?= Message-ID: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer. such as ```java class CharacterData00 { @Stable static final char[] X = @Stable static final char[] Y = @Stable static final int[] A = @Stable static final char[] B = } ``` - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Sat May 24 23:16:17 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sat, 24 May 2025 23:16:17 +0000 Subject: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes In-Reply-To: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com> References: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com> Message-ID: Hello Shaojin, I think your proposal is reasonable. These arrays are never mutated. Meanwhile I see some declarations like int A[] in CharacterData00, would be nice if you can convert those declarations to like int[] A too. Regards, Chen ________________________________ From: core-libs-dev on behalf of wenshao Sent: Saturday, May 24, 2025 12:55 PM To: core-libs-dev Subject: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer. such as ```java class CharacterData00 { @Stable static final char[] X = @Stable static final char[] Y = @Stable static final int[] A = @Stable static final char[] B = } ``` - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Sun May 25 00:08:32 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 25 May 2025 00:08:32 GMT Subject: RFR: 8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes In-Reply-To: References: Message-ID: On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen wrote: > Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer. make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195: > 1193: result.append(" @Stable static final "); > 1194: result.append(atype); > 1195: result.append(" ").append(name).append("["); While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106007546 From swen at openjdk.org Sun May 25 00:08:32 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 25 May 2025 00:08:32 GMT Subject: RFR: 8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes In-Reply-To: References: Message-ID: On Sat, 24 May 2025 23:04:50 GMT, Chen Liang wrote: >> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer. > > make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195: > >> 1193: result.append(" @Stable static final "); >> 1194: result.append(atype); >> 1195: result.append(" ").append(name).append("["); > > While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`? This will require more changes, and has no benefits other than better coding style. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106030868 From swen at openjdk.org Sun May 25 00:08:32 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 25 May 2025 00:08:32 GMT Subject: RFR: 8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes Message-ID: Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer. ------------- Commit messages: - sealed & final - add @Stable - stable Changes: https://git.openjdk.org/jdk/pull/25430/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357690 Stats: 31 lines in 10 files changed: 15 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25430/head:pull/25430 PR: https://git.openjdk.org/jdk/pull/25430 From liach at openjdk.org Sun May 25 00:08:32 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 25 May 2025 00:08:32 GMT Subject: RFR: 8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes In-Reply-To: References: Message-ID: On Sat, 24 May 2025 23:40:56 GMT, Shaojin Wen wrote: >> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195: >> >>> 1193: result.append(" @Stable static final "); >>> 1194: result.append(atype); >>> 1195: result.append(" ").append(name).append("["); >> >> While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`? > > This will require more changes, and has no benefits other than better coding style. Reasonable. These generated classes have a lot of code improvement opportunities that do not affect program semantics. We should handle those in a dedicated RFE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106038820 From liach at openjdk.org Sun May 25 04:43:55 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 25 May 2025 04:43:55 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 02:11:34 GMT, Shaojin Wen wrote: >> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. >> >> The following is the output information of PrintInlining: >> >> @ 9 java.lang.String:: (12 bytes) inline (hot) >> !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) >> ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big >> >> >> In Java code, the big method that cannot be inlined is the following constructor >> >> >> String(Charset charset, byte[] bytes, int offset, int length) {} >> >> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > create method share variant val & coder src/java.base/share/classes/java/lang/String.java line 569: > 567: } > 568: this.value = str.value; > 569: this.coder = str.coder; Suggestion: this(str); We have integrated flexible constructor bodies. src/java.base/share/classes/java/lang/String.java line 646: > 644: } > 645: > 646: private static String create(Charset charset, byte[] bytes, int offset, int length) { Should we call this "decode", as "create" feels too generic? src/java.base/share/classes/java/lang/String.java line 703: > 701: throw new Error(x); > 702: } > 703: if (COMPACT_STRINGS) { Now we can call other constructors of String, so instead of having this manual handling of char[], we can call `return new String(ca, 0, caLen, null)`. Same for the `clen` version above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106082898 PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106082727 PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106082563 From swen at openjdk.org Sun May 25 04:50:08 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 25 May 2025 04:50:08 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: On Sun, 25 May 2025 04:40:44 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> create method share variant val & coder > > src/java.base/share/classes/java/lang/String.java line 569: > >> 567: } >> 568: this.value = str.value; >> 569: this.coder = str.coder; > > Suggestion: > > this(str); > > We have integrated flexible constructor bodies. public String(String original) { this.value = original.value; this.coder = original.coder; this.hash = original.hash; this.hashIsZero = original.hashIsZero; } this(str) It will lead to more operations, which are not necessary here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106083905 From liach at openjdk.org Sun May 25 05:24:50 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 25 May 2025 05:24:50 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: On Sun, 25 May 2025 04:47:35 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/String.java line 569: >> >>> 567: } >>> 568: this.value = str.value; >>> 569: this.coder = str.coder; >> >> Suggestion: >> >> this(str); >> >> We have integrated flexible constructor bodies. > > public String(String original) { > this.value = original.value; > this.coder = original.coder; > this.hash = original.hash; > this.hashIsZero = original.hashIsZero; > } > > this(str) It will lead to more operations, which are not necessary here. You have shown C2 eliminates this string allocation. Maybe it eliminates these "more operations" too? Imo not worth maintaining separate logic here; this will be problematic when string fields change in the future and we may miss this site that need to update. The simple copy constructor has no issue with this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106088896 From swen at openjdk.org Sun May 25 05:53:10 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 25 May 2025 05:53:10 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v4] In-Reply-To: References: Message-ID: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/String.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25290/files - new: https://git.openjdk.org/jdk/pull/25290/files/fab7728b..4fe4b89d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290 PR: https://git.openjdk.org/jdk/pull/25290 From swen at openjdk.org Sun May 25 06:18:55 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 25 May 2025 06:18:55 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v5] In-Reply-To: References: Message-ID: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25290/files - new: https://git.openjdk.org/jdk/pull/25290/files/4fe4b89d..58583b77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290 PR: https://git.openjdk.org/jdk/pull/25290 From swen at openjdk.org Sun May 25 06:29:57 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 25 May 2025 06:29:57 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: On Sun, 25 May 2025 04:39:24 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> create method share variant val & coder > > src/java.base/share/classes/java/lang/String.java line 703: > >> 701: throw new Error(x); >> 702: } >> 703: if (COMPACT_STRINGS) { > > Now we can call other constructors of String, so instead of having this manual handling of char[], we can call `return new String(ca, 0, caLen, null)`. Same for the `clen` version above. private String(char[] value, int off, int len, Void sig) { if (len == 0) { this.value = "".value; this.coder = "".coder; return; } if (COMPACT_STRINGS) { byte[] val = StringUTF16.compress(value, off, len); this.coder = StringUTF16.coderFromArrayLen(val, len); this.value = val; return; } this.coder = UTF16; this.value = StringUTF16.toBytes(value, off, len); } This constructor has additional processing logic for len == 0. ValueObject may be used here in the future. I think it is better to keep the original structure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106099679 From stuefe at openjdk.org Sun May 25 08:18:11 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 25 May 2025 08:18:11 GMT Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() [v3] In-Reply-To: References: Message-ID: <-4h0JXxUpJFKnz2igmA0lWdfTmeyne_VuxaGGfegu5I=.a3d4185b-b0d4-464f-ac5b-03a6dd7ff43f@github.com> > Hi, please consider the following patch. > > This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc. > > This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens). > > Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409 > > This patch also fixes two subtle bugs: > - we didn't check the return value of the close() inside closeAllFileDescriptors > - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it) > > ---- > > Testing: > > We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC. > > - in the parent JVM, the test opens a file in native code without FD_CLOEXEC > - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open > > I verified that the test correctly detects a broken implementation that leaks file descriptors. > > I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX). > > I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close- - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close- - close dir fd on fcntl error - Mark fds with cloexec, plus test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25301/files - new: https://git.openjdk.org/jdk/pull/25301/files/8543a5ec..aef4e2bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=01-02 Stats: 75 lines in 3 files changed: 4 ins; 69 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301 PR: https://git.openjdk.org/jdk/pull/25301 From dl at openjdk.org Sun May 25 10:54:54 2025 From: dl at openjdk.org (Doug Lea) Date: Sun, 25 May 2025 10:54:54 GMT Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown In-Reply-To: References: Message-ID: On Sat, 24 May 2025 15:57:17 GMT, Alan Bateman wrote: >> Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException. > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3475: > >> 3473: ds = delayScheduler = null; >> 3474: unlockRunState(); >> 3475: tryTerminate(false, false); > > This reset okay, and the schedule methods will throw REE. The change makes me wonder about the OOME "unable to create new native thread" scenario, should the schedule methods propagate it or throw REE with the OOME as cause? OOME (not REE) is thrown if the creation fails in the try-finally, which seems best. But if start() throws OOME (or any other Error), I see that we should do the same back-out as with ISE, but rethrow it now vs rely on the the REE in schedule(). I'll adjust accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25431#discussion_r2106162465 From liach at openjdk.org Sun May 25 12:56:52 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 25 May 2025 12:56:52 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: On Sun, 25 May 2025 06:27:14 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/String.java line 703: >> >>> 701: throw new Error(x); >>> 702: } >>> 703: if (COMPACT_STRINGS) { >> >> Now we can call other constructors of String, so instead of having this manual handling of char[], we can call `return new String(ca, 0, caLen, null)`. Same for the `clen` version above. > > private String(char[] value, int off, int len, Void sig) { > if (len == 0) { > this.value = "".value; > this.coder = "".coder; > return; > } > if (COMPACT_STRINGS) { > byte[] val = StringUTF16.compress(value, off, len); > this.coder = StringUTF16.coderFromArrayLen(val, len); > this.value = val; > return; > } > this.coder = UTF16; > this.value = StringUTF16.toBytes(value, off, len); > } > > > This constructor has additional processing logic for len == 0. > > ValueObject may be used here in the future. I think it is better to keep the original structure. I thought this would both increase cleaniness and reduce code size of the decode method. @minborg What do you think? This also removes one of the switches on COMPACT_STRING. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106193216 From nbenalla at openjdk.org Sun May 25 12:59:55 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sun, 25 May 2025 12:59:55 GMT Subject: RFR: 8356629: Incorrect use of {@linkplain} in java.sql In-Reply-To: References: Message-ID: On Sat, 17 May 2025 17:21:01 GMT, Nizar Benalla wrote: > Please review this trivial patch to fix a javadoc bug. > > TIA Thanks for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25286#issuecomment-2907810545 From nbenalla at openjdk.org Sun May 25 12:59:55 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sun, 25 May 2025 12:59:55 GMT Subject: Integrated: 8356629: Incorrect use of {@linkplain} in java.sql In-Reply-To: References: Message-ID: On Sat, 17 May 2025 17:21:01 GMT, Nizar Benalla wrote: > Please review this trivial patch to fix a javadoc bug. > > TIA This pull request has now been integrated. Changeset: b034710b Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/b034710b2ae5fbfbe619abba86fef3b5a2d685e0 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8356629: Incorrect use of {@linkplain} in java.sql Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/25286 From chen.l.liang at oracle.com Sun May 25 16:17:58 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Sun, 25 May 2025 16:17:58 +0000 Subject: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes In-Reply-To: References: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com> Message-ID: On second thought, we should just focus on adding stable and final as you recommend - we should fix stylistic things with no semantic impact later. ________________________________ From: core-libs-dev on behalf of Chen Liang Sent: Saturday, May 24, 2025 6:16 PM To: core-libs-dev ; wenshao Subject: Re: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes Hello Shaojin, I think your proposal is reasonable. These arrays are never mutated. Meanwhile I see some declarations like int A[] in CharacterData00, would be nice if you can convert those declarations to like int[] A too. Regards, Chen ________________________________ From: core-libs-dev on behalf of wenshao Sent: Saturday, May 24, 2025 12:55 PM To: core-libs-dev Subject: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer. such as ```java class CharacterData00 { @Stable static final char[] X = @Stable static final char[] Y = @Stable static final int[] A = @Stable static final char[] B = } ``` - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sun May 25 17:42:55 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 25 May 2025 17:42:55 GMT Subject: Integrated: 8357685: Change the type of Integer::digits from char[] to byte[] In-Reply-To: References: Message-ID: On Sat, 24 May 2025 02:30:16 GMT, Shaojin Wen wrote: > Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory. This pull request has now been integrated. Changeset: 4a4209ff Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/4a4209ffef8f8d65054cbf46ebf8e169d100c0d8 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod 8357685: Change the type of Integer::digits from char[] to byte[] Reviewed-by: rgiulietti, liach ------------- PR: https://git.openjdk.org/jdk/pull/25426 From shaojin.wensj at alibaba-inc.com Sun May 25 23:57:33 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Mon, 26 May 2025 07:57:33 +0800 Subject: =?UTF-8?B?QWRkIEBTdGFibGUgdG8gQmlnSW50ZWdlciBhbmQgQmlnRGVjaW1hbA==?= Message-ID: <21b4abad-0321-408e-92c2-a87c1ee2e010.shaojin.wensj@alibaba-inc.com> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add @Stable to give the optimizer more information - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From yujige at gmail.com Mon May 26 01:07:45 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 25 May 2025 18:07:45 -0700 Subject: [External] : Re: mapConcurrent() with InterruptedException In-Reply-To: References: Message-ID: Thanks Viktor! Sorry, I was giving myself more time to read the code, but then I lost track. If I'm reading the code right, the current behavior is that if the current thread is interrupted, the mapConcurrent() would suppress the interruption until all elements are processed? (It will then restore the interruption bit) Doesn't this break fail fast? For example, I may have a mapConcurrent() called from within structured concurrency, and that fans out to two operations: ? scope.fork(() -> doA()); scope.fork(() -> doB()); // calls mapConcurrent() internally scope.join().throwIfFailed(); If doA() fails, doB() will be cancelled (thread interrupted). If mapConcurrent() ignores the interruption, and if doB has a long list to process, it'll continue to consume system resources even when the caller no longer needs the results, no? On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang wrote: > >Sorry, did the PR stop using Semaphore? > > No, not that PR. See: > https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e > > The problem with interruption under parallel evaluation is that there is > no general support for propagation of interruption in CountedCompleters. > Adding support for such in (at least) GathererOp needs further study before > contemplating making any changes to mapConcurrent()'s interruption policy. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* Jige Yu > *Sent:* Thursday, 6 February 2025 17:04 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Sorry, did the PR stop using Semaphore? > > I had naively thought that mapConcurrent() will keep a buffer of Future of > all currently-running concurrent tasks (it can be a ConcurrentMap Future> if we don't have to ensure FIFO). > > Upon interruption, the main thread can call .cancel(true) on all pending > Futures; optionally join with the VTs (if we need to block until all VTs > exit); then propagate exception. > > Upon completion, each task just removes itself from the ConcurrentMap. > > Just in case it adds anything. > > > > On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang > wrote: > > After some more investigation it seems tractable to propagate interruption > of the caller in sequential mode, but parallel mode will require much > bigger considerations. > > I made a comment to that effect on the JBS issue: > https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017 > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Viktor Klang > *Sent:* Thursday, 6 February 2025 11:51 > *To:* Jige Yu > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > I think alignment in behavior between parallel Stream and mapConcurrent in > terms of how interruptions are handled is a possible path forward. > > I decided to close the PR for now as I realized my parallel Stream example > had misled me regarding its exception throwing, so I'll need to go back and > refine the solution. > > It still seems solvable though. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Wednesday, 5 February 2025 19:20 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Oh good call! > > I forgot to check what parallel streams do upon interruption (didn't think > they do any blocking calls, but at least the main thread must block). > > On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang > wrote: > > Hi Jige, > > I opened an issue to track the concern, and I have proposed a change which > seems to align well with how parallel streams behave under caller thread > interruption. > > I've opened the following PR for review: > https://github.com/openjdk/jdk/pull/23467 > > > If you are able to make a local OpenJDK build with that solution you could > check if it addresses your use-cases (or not). > > > 8349462: Gatherers.mapConcurrent could support async interrupts by > viktorklang-ora ? Pull Request #23467 ? openjdk/jdk > > This change is likely going to need some extra verbiage in the spec for > mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how > parallel streams work in conjunction with interrup... > github.com > > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Wednesday, 5 February 2025 16:24 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Thanks Viktor! > > I understand the problem. > > The main reason I asked is because I want to understand how the core Java > team thinks of throwing an unchecked exception. > > As explained above, I consider losing cancellability a big deal, a deal > breaker even. And I thought throwing unchecked is more acceptable. Because > the most common reason the mapConcurrent() VT can be interrupted is due to > cancellation from a parent mapConcurrent(), or a parent Structured > Concurrency scope. The cancellation could be either from an organic > exception, or from the downstream not needing more elements, like maybe due > to findFirst() already getting an element. > > In both cases, since the concurrent operation is already cancelled (result > ignored), what exception pops up to the top level isn't that big of a deal > (perhaps only a log record will be seen?) > > But if the core Java team considers it a bad idea, I would love to learn > and adjust. > > On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang > wrote: > > Hi, > > The problem is that mapConcurrent cannot throw InterruptedException > because that is a checked exception, so we cannot clear the interrupted > flag and throw that exception. > > So the updated semantics is to not cut the stream short but instead run to > completion, restoring the interruption flag. > > There exists a couple of alternatives to this approach which I am > contemplating, but they need to be further explored before I consider > moving forward with any of them. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Monday, 27 January 2025 17:00 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Thanks Viktor! > > It looks like the current fix ignores interruption. > > I want to make sure my concern of it defeating cancellation is heard and > understood. > > The scenarios I worry about is for a mapConcurrent() that fans out to > another method call, which internally calls mapConcurrent() as > implementation detail. > > An example: > > List refundHelper(transaction) { > transaction.creditCardAccounts.stream() > .gather(mapConcurrent(acct -> service.refund(acct)) > .toList(); > } > > transactions.stream() > .gather(mapConcurrent(transaction -> refundHelper(transaction)); > > > It seems undesirable that in such a case all the service.refund() calls > become non cancellable, because the only way the outer mapConcurrent() > cancels the refundHelper() calls is through Thread.interrupt() the virtual > threads that call refundHelper(), which would then be disabled by the inner > mapConcurrent(). > > Does this example make sense to you? I can further explain if anything > isn't clear. > > But I want to make sure the decision to disable interruption is deliberate > judgement call that such nested mapConcurrent() is unlikely,or not > important. > > Cheers, > > > > On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang > wrote: > > Hi! > > Please see: https://github.com/openjdk/jdk/pull/23100 > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 26 January 2025 23:03 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* [External] : Re: mapConcurrent() with InterruptedException > > Checking in on what you've found out, Viktor. > > From where we left off, I understand that you were looking at alternatives > instead of silent truncation? > > Have you reached any conclusion? > > We touched on disallowing interruption during mapConcurrent(). I still > have concerns with disabling cancellation, because it basically undoes this > API note from the javadoc > > : > > API Note: In progress tasks will be attempted to be cancelled, on a > best-effort basis, in situations where the downstream no longer wants to > receive any more elements. > In reality, people will use mapConcurrent() to fan out rpcs. Sometimes > these rpcs are just a single blocking call; yet sometimes they may > themselves be a Structured Concurrency scope, with 2 or 3 rpcs that > constitute a single logical operation. Under two conditions, cancellation > is imho important semantic: > > 1. The downstream code uses filter().findFirst(), and when it sees an > element, it will return and no longer needs the other pending rpcs to > complete. If cancellation is disabled, these unnecessary rpcs will waste > system resources. > 2. One of the rpc throws and the Stream pipeline needs to propagate > the exception. Again, if the other rpcs cannot be cancelled, we'll have > many zombie rpcs. > > Zombie rpcs may or may not be a deal breaker, depending on the specific > use case. But for a JDK library, losing cancellation would have a negative > impact on usability. > > My 2c, > > > On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang > wrote: > > Hi Ben, > > Thanks for raising these questions?getting feedback is crucial in the > Preview stage of features. > > I wrote a reply to the Reddit thread so I'll just summarize here: > > It is important to note that *mapConcurrent()* is not a part of the > Structured Concurrency JEPs, so it is not designed to join SC scopes. > > I'm currently experimenting with ignoring-but-restoring interrupts on the > "calling thread" for *mapConcurrent()*, as well as capping > work-in-progress to *maxConcurrency* (not only capping the concurrency > but also the amount of completed-but-yet-to-be-pushed work). Both of these > adjustments should increase predictability of behavior in the face of > blocking operations with variable delays. > > Another adjustment I'm looking at right now is to harden/improve the > cleanup to wait for concurrent tasks to acknowledge cancellation, so that > once the finisher is done executing the VTs are known to have terminated. > > As for not preserving the encounter order, that would be a completely > different thing, and I'd encourage you to experiment with that if that > functionality would be interesting for your use-case(s). > > Again, thanks for your feedback! > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Friday, 3 January 2025 17:53 > *To:* core-libs-dev at openjdk.org > *Subject:* mapConcurrent() with InterruptedException > > Hi Java Experts, > > I sent this email incorrectly to loom-dev@ and was told on Reddit that > core-libs-dev is the right list. > > The question is about the behavior of mapConcurrent() when the thread is > interrupted. > > Currently mapConcurrent()'s finisher phase will re-interrupt the thread, > then stop at whatever element that has already been processed and return. > > This strikes me as a surprising behavior, because for example if I'm > running: > > Stream.of(1, 2, 3) > .gather(mapConcurrent(i -> i * 2)) > .toList() > > and the thread is being interrupted, the result could be any of [2], [2, > 4] or [2, 4, 6]. > > Since thread interruption is cooperative, there is no guarantee that the > thread being interrupted will just abort. It's quite possible that it'll > keep going and then will use for example [2] as the result of doubling the > list of [1, 2, 3], which is imho incorrect. > > In the Reddit > thread, > someone argued that interruption rarely happens so it's more of a > theoretical issue. But interruption can easily happen in Structured > Concurrency or in mapConcurrent() itself if any subtask has failed in order > to cancel/interrupt the other ongoing tasks. > > There had been discussion about alternative strategies: > > 1. Don't respond to interruption and just keep running to completion. > 2. Re-interrupt thread and wrap the InterruptedException in a standard > unchecked exception (StructuredConcurrencyInterruptedException?). > > > I have concerns with option 1 because it disables cancellation propagation > when mapConcurrent() itself is used in a subtask of a parent > mapConcurrent() or in a StructuredConcurrencyScope. > > Both equivalent Future-composition async code, or C++'s fiber trees > support cancellation propagation and imho it's a critical feature or else > it's possible that a zombie thread is still sending RPCs long after the > main thread has exited (failed, or falled back to some default action). > > My arguments for option 2: > > 1. InterruptedException is more error prone than traditional checked > exceptions for *users* to catch and handle. They can forget to > re-interrupt the thread. It's so confusing that even seasoned programmers > may not know they are *supposed to* re-interrupt the thread. > 2. With Stream API using functional interfaces like Supplier, > Function, the option of just tacking on "throws IE" isn't available to many > users. > 3. With Virtual Threads, it will be more acceptable, or even become > common to do blocking calls from a stream operation (including but > exclusive to mapConcurrent()). So the chance users are forced to deal with > IE will become substantially higher. > 4. Other APIs such as the Structured Concurrency API have already > started wrapping system checked exceptions like ExecutionException, > TimeoutException in unchecked exceptions ( join() > for > example). > 5. Imho, exceptions that we'd rather users not catch and handle but > instead should mostly just propagate up as is, should be unchecked. > > There is also a side discussion > about > whether mapConcurrent() is better off preserving input order or push to > downstream as soon as an element is computed. I'd love to discuss that > topic too but maybe it's better to start a separate thread? > > Thank you and cheers! > > Ben Yu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Mon May 26 05:46:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 May 2025 05:46:50 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null In-Reply-To: References: Message-ID: <_L16HJaL2iFRPFnS4dyzoVSbAx5jofgsWdOfMqpFq3E=.cb5f0a1d-4269-4e95-a3f5-181242a8050e@github.com> On Fri, 23 May 2025 16:05:08 GMT, Steffen Nie?ing wrote: > `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE. The change looks OK to me. Please update the copyright year on the file from `1999, 2024,` to `1999, 2025,`. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2867281818 From epeter at openjdk.org Mon May 26 06:58:53 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 May 2025 06:58:53 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong wrote: > JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). > > Two key areas require improvement: > 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. > 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. > > This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. > > Main changes: > 1. Java-side API refactoring: > - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on > architectures like AArch64. > 2. C2 compiler IR refactoring: > - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. > 3. Backend changes: > - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. > > Performance: > The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: > > Benchmark Mode Cnt Unit SIZE Before After Gain > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.312 935.269 1.02 > GatherOperationsBenchmark.micr... It seems reasonable. @jatin-bhateja should definitively look over this, or someone else from Intel who knows this code well :) I'll launch some testing now :) src/hotspot/share/opto/vectorIntrinsics.cpp line 1203: > 1201: // Class> vectorIndexClass, int indexLength, > 1202: // Object base, long offset, > 1203: // W indexVector1, W index_vector2, W index_vector3, W index_vector4, Are we doing a mix of `CamelCase` and `with_underscore` on purpose? src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 495: > 493: Class> vectorIndexClass, > 494: int indexLength, Object base, long offset, > 495: W indexVector1, W indexVector2, W indexVector3, W indexVector4, Here you went for all `camelCase`, just an observation :) ------------- PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2867447489 PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106674102 PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106673987 From xgong at openjdk.org Mon May 26 07:20:30 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 26 May 2025 07:20:30 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Mon, 26 May 2025 06:51:12 GMT, Emanuel Peter wrote: >> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). >> >> Two key areas require improvement: >> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. >> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. >> >> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. >> >> Main changes: >> 1. Java-side API refactoring: >> - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on >> architectures like AArch64. >> 2. C2 compiler IR refactoring: >> - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. >> 3. Backend changes: >> - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. >> >> Performance: >> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: >> >> Benchmark Mode Cnt Unit SIZE Before After Gain >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.31... > > src/hotspot/share/opto/vectorIntrinsics.cpp line 1203: > >> 1201: // Class> vectorIndexClass, int indexLength, >> 1202: // Object base, long offset, >> 1203: // W indexVector1, W index_vector2, W index_vector3, W index_vector4, > > Are we doing a mix of `CamelCase` and `with_underscore` on purpose? This would be a naming style issue. Thanks for pointing out. I will fix it once I update this PR. It should be aligned with definition in `VectorSupport.java`. > src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 495: > >> 493: Class> vectorIndexClass, >> 494: int indexLength, Object base, long offset, >> 495: W indexVector1, W indexVector2, W indexVector3, W indexVector4, > > Here you went for all `camelCase`, just an observation :) Yeah, I choose to use `camelCase` style here to align with other parameter naming styles in this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106693179 PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106692107 From alanb at openjdk.org Mon May 26 07:22:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 07:22:49 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote: >> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects wording change suggestions Spec update and src changes looks good. I only skimmed through the test changes (not a detailed review) and they look reasonable. I assume you've done some "test repeat" jobs to ensure that any variance in the version of "expect" on test machines doesn't cause any issues. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2867506507 From viktor.klang at oracle.com Mon May 26 07:30:15 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Mon, 26 May 2025 07:30:15 +0000 Subject: [External] : Re: mapConcurrent() with InterruptedException In-Reply-To: References: Message-ID: Yes, the updated Gatherers.mapConcurrent will continue under interruption until done, and then restore the interrupt status of the calling thread. It cannot (reasonably) do anything else?if it were to throw InterruptedException, it couldn't since that is a checked exception and there's no tracking of checked exceptions throughout a Stream, and that is the specified behavior to handle thread interrupts (i.e. clear flag and throw InterruptedException, which is not possible in this case; or, make sure that interrupt status is maintained, which is possible in this case. I have given it some more thought in the meantime, but I haven't arrived in something more satisfactory than that, yet. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu Sent: Monday, 26 May 2025 03:07 To: Viktor Klang Cc: core-libs-dev at openjdk.org Subject: Re: [External] : Re: mapConcurrent() with InterruptedException Thanks Viktor! Sorry, I was giving myself more time to read the code, but then I lost track. If I'm reading the code right, the current behavior is that if the current thread is interrupted, the mapConcurrent() would suppress the interruption until all elements are processed? (It will then restore the interruption bit) Doesn't this break fail fast? For example, I may have a mapConcurrent() called from within structured concurrency, and that fans out to two operations: ? scope.fork(() -> doA()); scope.fork(() -> doB()); // calls mapConcurrent() internally scope.join().throwIfFailed(); If doA() fails, doB() will be cancelled (thread interrupted). If mapConcurrent() ignores the interruption, and if doB has a long list to process, it'll continue to consume system resources even when the caller no longer needs the results, no? On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang > wrote: >Sorry, did the PR stop using Semaphore? No, not that PR. See: https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e The problem with interruption under parallel evaluation is that there is no general support for propagation of interruption in CountedCompleters. Adding support for such in (at least) GathererOp needs further study before contemplating making any changes to mapConcurrent()'s interruption policy. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Thursday, 6 February 2025 17:04 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: mapConcurrent() with InterruptedException Sorry, did the PR stop using Semaphore? I had naively thought that mapConcurrent() will keep a buffer of Future of all currently-running concurrent tasks (it can be a ConcurrentMap if we don't have to ensure FIFO). Upon interruption, the main thread can call .cancel(true) on all pending Futures; optionally join with the VTs (if we need to block until all VTs exit); then propagate exception. Upon completion, each task just removes itself from the ConcurrentMap. Just in case it adds anything. On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang > wrote: After some more investigation it seems tractable to propagate interruption of the caller in sequential mode, but parallel mode will require much bigger considerations. I made a comment to that effect on the JBS issue: https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017 Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Viktor Klang > Sent: Thursday, 6 February 2025 11:51 To: Jige Yu > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: mapConcurrent() with InterruptedException I think alignment in behavior between parallel Stream and mapConcurrent in terms of how interruptions are handled is a possible path forward. I decided to close the PR for now as I realized my parallel Stream example had misled me regarding its exception throwing, so I'll need to go back and refine the solution. It still seems solvable though. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Wednesday, 5 February 2025 19:20 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: mapConcurrent() with InterruptedException Oh good call! I forgot to check what parallel streams do upon interruption (didn't think they do any blocking calls, but at least the main thread must block). On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang > wrote: Hi Jige, I opened an issue to track the concern, and I have proposed a change which seems to align well with how parallel streams behave under caller thread interruption. I've opened the following PR for review: https://github.com/openjdk/jdk/pull/23467 If you are able to make a local OpenJDK build with that solution you could check if it addresses your use-cases (or not). [https://opengraph.githubassets.com/00e04f8a63bde12217df087df7ef8edee563adf7e925d07c75bdeae092180094/openjdk/jdk/pull/23467] 8349462: Gatherers.mapConcurrent could support async interrupts by viktorklang-ora ? Pull Request #23467 ? openjdk/jdk This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how parallel streams work in conjunction with interrup... github.com Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Wednesday, 5 February 2025 16:24 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: mapConcurrent() with InterruptedException Thanks Viktor! I understand the problem. The main reason I asked is because I want to understand how the core Java team thinks of throwing an unchecked exception. As explained above, I consider losing cancellability a big deal, a deal breaker even. And I thought throwing unchecked is more acceptable. Because the most common reason the mapConcurrent() VT can be interrupted is due to cancellation from a parent mapConcurrent(), or a parent Structured Concurrency scope. The cancellation could be either from an organic exception, or from the downstream not needing more elements, like maybe due to findFirst() already getting an element. In both cases, since the concurrent operation is already cancelled (result ignored), what exception pops up to the top level isn't that big of a deal (perhaps only a log record will be seen?) But if the core Java team considers it a bad idea, I would love to learn and adjust. On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang > wrote: Hi, The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception. So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag. There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Monday, 27 January 2025 17:00 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: mapConcurrent() with InterruptedException Thanks Viktor! It looks like the current fix ignores interruption. I want to make sure my concern of it defeating cancellation is heard and understood. The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail. An example: List refundHelper(transaction) { transaction.creditCardAccounts.stream() .gather(mapConcurrent(acct -> service.refund(acct)) .toList(); } transactions.stream() .gather(mapConcurrent(transaction -> refundHelper(transaction)); It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent(). Does this example make sense to you? I can further explain if anything isn't clear. But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important. Cheers, On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang > wrote: Hi! Please see: https://github.com/openjdk/jdk/pull/23100 Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Sunday, 26 January 2025 23:03 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: [External] : Re: mapConcurrent() with InterruptedException Checking in on what you've found out, Viktor. From where we left off, I understand that you were looking at alternatives instead of silent truncation? Have you reached any conclusion? We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc: API Note: In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements. In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic: 1. The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources. 2. One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs. Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability. My 2c, On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang > wrote: Hi Ben, Thanks for raising these questions?getting feedback is crucial in the Preview stage of features. I wrote a reply to the Reddit thread so I'll just summarize here: It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes. I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays. Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated. As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s). Again, thanks for your feedback! Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Jige Yu > Sent: Friday, 3 January 2025 17:53 To: core-libs-dev at openjdk.org > Subject: mapConcurrent() with InterruptedException Hi Java Experts, I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list. The question is about the behavior of mapConcurrent() when the thread is interrupted. Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return. This strikes me as a surprising behavior, because for example if I'm running: Stream.of(1, 2, 3) .gather(mapConcurrent(i -> i * 2)) .toList() and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6]. Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect. In the Reddit thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks. There had been discussion about alternative strategies: 1. Don't respond to interruption and just keep running to completion. 2. Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?). I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope. Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action). My arguments for option 2: 1. InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread. 2. With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users. 3. With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher. 4. Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join() for example). 5. Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked. There is also a side discussion about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread? Thank you and cheers! Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbaesken at openjdk.org Mon May 26 07:45:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 26 May 2025 07:45:38 GMT Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG de_DE.UTF-8 Message-ID: On a 'german' Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with FEIN: hi now! java.lang.RuntimeException: System.err does not contain: FINE: hi now! at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1447) The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment. ------------- Commit messages: - JDK-8357561 Changes: https://git.openjdk.org/jdk/pull/25441/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25441&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357561 Stats: 16 lines in 3 files changed: 12 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25441/head:pull/25441 PR: https://git.openjdk.org/jdk/pull/25441 From ihse at openjdk.org Mon May 26 07:47:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 07:47:02 GMT Subject: RFR: 8356977: UTF-8 cleanups In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com> References: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com> Message-ID: On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato wrote: >> I found a few other places in the code that can be cleaned up after the conversion to UTF-8. > > test/jdk/sun/text/resources/LocaleDataTest.java line 106: > >> 104: * FormatData/fr_FR/MonthNames/0=janvier >> 105: * FormatData/fr_FR/MonthNames/1=f?vrier >> 106: * LocaleNames/fr_FR/US=?tats-Unis > > This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct. ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160 From mbaesken at openjdk.org Mon May 26 08:16:03 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 26 May 2025 08:16:03 GMT Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG de_DE.UTF-8 [v2] In-Reply-To: References: Message-ID: > On a 'german' Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test > java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with > > > FEIN: hi now! > java.lang.RuntimeException: System.err does not contain: FINE: hi now! > at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1447) > > > The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust LocalizedLevelName too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25441/files - new: https://git.openjdk.org/jdk/pull/25441/files/76db640f..ec6d03d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25441&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25441&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25441/head:pull/25441 PR: https://git.openjdk.org/jdk/pull/25441 From ihse at openjdk.org Mon May 26 08:20:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:20:19 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Restore MenuShortcut.java - Restore LocaleDataTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25228/files - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228 PR: https://git.openjdk.org/jdk/pull/25228 From ihse at openjdk.org Mon May 26 08:20:46 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:20:46 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com> On Thu, 22 May 2025 21:43:20 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Restore MenuShortcut.java >> - Restore LocaleDataTest.java > > src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49: > >> 47: * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by >> 48: *

        >> 49: * MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false); > > This is javadoc inJava SE specification. As is the Action case below. > I can't think of any actual harm from this change, so OK, but I am not seeing why it is needed. The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. I did this since I thought it increased readability of the source code, but I can just as well revert it. > test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63: > >> 61: >> 62: private static final String INSTRUCTIONS = >> 63: "A string \u201C" + TEXT + "\u201D is drawn at eight different " > > I really don't like these tests being changed. It isn't part of the JDK build. > People compile these in all sorts of locales. > Please revert all the changes in the client tests. Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then. The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it? Let me know if you still want me to revert it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659 PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184 From ihse at openjdk.org Mon May 26 08:21:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:21:16 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com> On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie wrote: >> I found a few other places in the code that can be cleaned up after the conversion to UTF-8. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Restore MenuShortcut.java > - Restore LocaleDataTest.java test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90: > 88: printKey(e); > 89: int keychar = e.getKeyChar(); > 90: if (keychar == 27) { // Escape character is 27 or \u001b @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it? test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188: > 186: + "\"After\" lists.\n" > 187: + " Added printers are highlighted with " > 188: + "green color, removed ones \u2014 with " @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error. Do you still want me to revert it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492 PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974 From ihse at openjdk.org Mon May 26 08:24:36 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:24:36 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com> References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com> Message-ID: On Thu, 22 May 2025 21:26:08 GMT, Phil Race wrote: >> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France): >> >> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark. >> - U+00A0 (No-Break Space NBSP) preceding colon. >> >> Similar conventions are used in other French speaking countries. > >> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. > >> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. > > > I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed > > the Java unicode escape to UTF-8 for the localised message string. > > You propose restoring it to Java escape. > > > I wouldn't be surprised if the next message drop reverses what you reversed. > > I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes > > since that is very much a Java thing. So you are probably making the translation job harder. > > > So I am suggesting you leave all of the translation files as is. > Which might mean withdrawing this PR. Fair enough. This was meant to be an improvement in readability, not a hindrance for working efficiently. I'll withdraw this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2106804794 From ihse at openjdk.org Mon May 26 08:24:38 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:24:38 GMT Subject: Withdrawn: 8356980: Better handling of non-breaking space In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie wrote: > Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. > > I have checked: > * U+00A0 NO-BREAK SPACE (NBSP) > * U+202F NARROW NO-BREAK SPACE (NNBSP) > * U+2007 FIGURE SPACE > * U+2060 WORD JOINER > > In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25234 From ihse at openjdk.org Mon May 26 08:25:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:25:07 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: <-HdnkBjrOxo3jUA8jSYhmElKM55oIcSRYYgu70KPR8M=.24dfddf4-6890-4a61-9cef-85f1a2c1238a@github.com> On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote: > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. @JoeWang-Java @naotoj Can you help review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908936863 From ihse at openjdk.org Mon May 26 08:27:45 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:27:45 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote: > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. @justin-curtis-lu Are these files handled by the translation team? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908942083 From claes.redestad at oracle.com Mon May 26 08:57:41 2025 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 26 May 2025 08:57:41 +0000 Subject: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes In-Reply-To: References: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com> Message-ID: <8F456C2E-99E6-46AE-890A-B1B72055026B@oracle.com> > On second thought, we should just focus on adding stable and final as you recommend - we should fix stylistic things with no semantic impact later. I?ll note that the code generator used to emit these CharacterData classes ? build.tools.generatecharacter.GenerateCharacter ? has legacy support to emit both Java and C code. This explain the choice to emit C-style arrays as a deliberate choice to simplify the code generator logic. I can?t find any use of this -c flag in our build or elsewhere though, so perhaps a little bit of clean up is in order. From alanb at openjdk.org Mon May 26 09:32:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 09:32:45 GMT Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG de_DE.UTF-8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken wrote: >> On a 'german' Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test >> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with >> >> >> FEIN: hi now! >> java.lang.RuntimeException: System.err does not contain: FINE: hi now! >> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> >> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust LocalizedLevelName too test/jdk/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java line 357: > 355: } > 356: LogStream.err.println(test.name() + ": PASSED"); > 357: Locale.setDefault(savedLocale); For othervm tests then I assume there is no need to restore. For tests that may run in the same VM as other tests when try-finally can be used to restore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25441#discussion_r2106894148 From alan.bateman at oracle.com Mon May 26 09:47:53 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 26 May 2025 10:47:53 +0100 Subject: RFC: 8357183: Improving efficiency of Writer::append(CharSequence) and Writer::append(CharSequence, int, int) / Sub Task of 8356679: Using CharSequence::getChars internally In-Reply-To: References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> Message-ID: <3b5d20ae-ba24-4f55-ba04-8931821510df@oracle.com> On 24/05/2025 15:37, Markus KARG wrote: > > Chen, > > > thank you for your approval for a DRAFT PR. > > > Following your proposal, I have published a DRAFT PR at > https://github.com/openjdk/jdk/pull/25432 so everybody can see what > the actual intended code change looks like, and better focus on that > actual code change and its risks and benefits. The intention of that > DRAFT PR explicitly is NOT to request code reviews, but solely to > serve as a publicly visible piece of code to support the ongoing > discussion here on this mailing list. > > > TARGET VERSION: 26 > > > As we are near to JDK 25 GA, the target is inclusion into JDK 26 or > later, so no need to rush. Nevertheless, I would be happy if everybody > comments ASAP (at least briefly) to keep this discussion alive. > > > PRELIMINARY RISK ANALYSIS: LOW > Writer was retrofitted to implement Appendable in JDK 5 with the 3-arg append documented to behave "in exactly the same as ..." the write(String) method. That's 20 years of subclasses that might be depending on this behavior. Also 20 years of subclasses that may depend on the 3-arg append calling the 1-arg append. So my initial reaction is that the risk may not be low and this proposal will require significant analysis of Writer implementations before the compatibility risk can be assessed. -Alan From dfuchs at openjdk.org Mon May 26 10:04:07 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 May 2025 10:04:07 GMT Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG de_DE.UTF-8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken wrote: >> On a 'german' Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test >> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with >> >> >> FEIN: hi now! >> java.lang.RuntimeException: System.err does not contain: FINE: hi now! >> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> >> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust LocalizedLevelName too Thanks for the patch! Restoring to the savedLocale at the end of main is not strictly needed since tests run in /othervm mode, but it's not wrong to restore it either. LGTM. Give me some time to test these proposed changes in our CI. ------------- PR Review: https://git.openjdk.org/jdk/pull/25441#pullrequestreview-2867904187 From michaelm at openjdk.org Mon May 26 10:31:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 26 May 2025 10:31:39 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Merge branch 'master' into 8348986-exceptions - update - reduced number of new categories - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Review update - review update - Merge branch 'master' into 8348986-exceptions - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=10 Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From pminborg at openjdk.org Mon May 26 11:26:52 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 26 May 2025 11:26:52 GMT Subject: RFR: 8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes In-Reply-To: References: Message-ID: <_DQFSQ_9pkAj4Rf9E-ONh4DavkQTg85zEEPSXS6ok7A=.183704c5-165e-4210-95fe-444fcea4da9e@github.com> On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen wrote: > Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer. We could add '@Stable` to `static final char[][][] charMap` as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25430#issuecomment-2909388887 From dfuchs at openjdk.org Mon May 26 11:33:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 May 2025 11:33:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2868122303 From pminborg at openjdk.org Mon May 26 12:02:55 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 26 May 2025 12:02:55 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: References: Message-ID: <_sTXM6OTeajXZgl0g4fqyuITxumngvoBxT1cDNyBCFw=.29df110c-305f-4c71-a369-9c56a799f247@github.com> On Sun, 25 May 2025 12:54:03 GMT, Chen Liang wrote: >> private String(char[] value, int off, int len, Void sig) { >> if (len == 0) { >> this.value = "".value; >> this.coder = "".coder; >> return; >> } >> if (COMPACT_STRINGS) { >> byte[] val = StringUTF16.compress(value, off, len); >> this.coder = StringUTF16.coderFromArrayLen(val, len); >> this.value = val; >> return; >> } >> this.coder = UTF16; >> this.value = StringUTF16.toBytes(value, off, len); >> } >> >> >> This constructor has additional processing logic for len == 0. >> >> ValueObject may be used here in the future. I think it is better to keep the original structure. > > I thought this would both increase cleaniness and reduce code size of the decode method. @minborg What do you think? This also removes one of the switches on COMPACT_STRING. I think it is better to keep the code smaller rather than saving 0.2 ns for skipping the zero-length check, which might get optimized away anyhow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107187594 From redestad at openjdk.org Mon May 26 12:14:52 2025 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 May 2025 12:14:52 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v3] In-Reply-To: <_sTXM6OTeajXZgl0g4fqyuITxumngvoBxT1cDNyBCFw=.29df110c-305f-4c71-a369-9c56a799f247@github.com> References: <_sTXM6OTeajXZgl0g4fqyuITxumngvoBxT1cDNyBCFw=.29df110c-305f-4c71-a369-9c56a799f247@github.com> Message-ID: <-eqT0GnSEhjr0MDVe7ywxx1e5m4UUVYn4VmI_VJ3bYQ=.949b3b59-1790-45da-899a-6e09188941f1@github.com> On Mon, 26 May 2025 12:00:02 GMT, Per Minborg wrote: >> I thought this would both increase cleaniness and reduce code size of the decode method. @minborg What do you think? This also removes one of the switches on COMPACT_STRING. > > I think it is better to keep the code smaller rather than saving 0.2 ns for skipping the zero-length check, which might get optimized away anyhow. That zero-length check in `String(char[], int, int, Void)` was done as an optimization, too, so would be good if we leveraged it in paths that currently miss out for consistency. It was done maybe not so much for speed but to reduce memory and allocation pressure (empty `String`s are surprisingly common in many apps). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107206228 From jpai at openjdk.org Mon May 26 12:33:32 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 May 2025 12:33:32 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed Message-ID: Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. ------------- Commit messages: - add test - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed Changes: https://git.openjdk.org/jdk/pull/25449/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357708 Stats: 533 lines in 3 files changed: 440 ins; 58 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/25449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25449/head:pull/25449 PR: https://git.openjdk.org/jdk/pull/25449 From nbenalla at openjdk.org Mon May 26 12:44:01 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 26 May 2025 12:44:01 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > update javadoc based on feedback All files have been reviewed. Thanks All! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25287#issuecomment-2909611326 From nbenalla at openjdk.org Mon May 26 12:44:01 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 26 May 2025 12:44:01 GMT Subject: Integrated: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA This pull request has now been integrated. Changeset: bd095896 Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/bd095896dd6e3fccb932f3d9823008766e9ab18d Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base Reviewed-by: weijun, liach ------------- PR: https://git.openjdk.org/jdk/pull/25287 From dl at openjdk.org Mon May 26 12:54:06 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 26 May 2025 12:54:06 GMT Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown [v2] In-Reply-To: References: Message-ID: > Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: rethrow Errors in startDelayScheduler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25431/files - new: https://git.openjdk.org/jdk/pull/25431/files/eeb5119e..675aff74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25431&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25431&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25431.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25431/head:pull/25431 PR: https://git.openjdk.org/jdk/pull/25431 From nbenalla at openjdk.org Mon May 26 13:07:06 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 26 May 2025 13:07:06 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v4] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - ... and 4 more: https://git.openjdk.org/jdk/compare/bd095896...b79e5022 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=03 Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From swen at openjdk.org Mon May 26 13:19:08 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 26 May 2025 13:19:08 GMT Subject: RFR: 8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes [v2] In-Reply-To: References: Message-ID: > Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: add '@stabletostatic final char[][][] charMap`, from @minborg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25430/files - new: https://git.openjdk.org/jdk/pull/25430/files/d5936dd5..d9f0e5e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25430/head:pull/25430 PR: https://git.openjdk.org/jdk/pull/25430 From swen at openjdk.org Mon May 26 13:23:07 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 26 May 2025 13:23:07 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v6] In-Reply-To: References: Message-ID: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25290/files - new: https://git.openjdk.org/jdk/pull/25290/files/58583b77..4f3eea73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=04-05 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290 PR: https://git.openjdk.org/jdk/pull/25290 From liach at openjdk.org Mon May 26 14:58:00 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 May 2025 14:58:00 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v6] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 13:23:07 GMT, Shaojin Wen wrote: >> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. >> >> The following is the output information of PrintInlining: >> >> @ 9 java.lang.String:: (12 bytes) inline (hot) >> !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) >> ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big >> >> >> In Java code, the big method that cannot be inlined is the following constructor >> >> >> String(Charset charset, byte[] bytes, int offset, int length) {} >> >> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @liach src/java.base/share/classes/java/lang/String.java line 661: > 659: // ascii > 660: if (ad.isASCIICompatible() && !StringCoding.hasNegatives(bytes, offset, length)) { > 661: if (COMPACT_STRINGS) { Replace this with `return iso88591(bytes, offset, length)`; src/java.base/share/classes/java/lang/String.java line 673: > 671: value = new byte[length]; > 672: ad.decodeToLatin1(bytes, offset, length, value); > 673: coder = LATIN1; With the other optimizations, you can make this `return new String(value, LATIN1)` and remove the `value` and `coder` local variable declarations. src/java.base/share/classes/java/lang/String.java line 680: > 678: char[] ca = new char[en]; > 679: int clen = ad.decode(bytes, offset, length, ca); > 680: if (COMPACT_STRINGS) { This can be `return new String(ca, 0, cLen, null);` too, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107508429 PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107510678 PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107506207 From pminborg at openjdk.org Mon May 26 15:08:52 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 26 May 2025 15:08:52 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 19:52:50 GMT, Chen Liang wrote: > Can we remove all meaningless `!Architecture.isLittleEndian()` calls and use the platform-specific endianness unsafe primitives instead? For compensation, we can add a check in each of fill2/fill3/fill4 that `assert value == Integer/Short/Long.reverseBytes(value)` if you think that is necessary. Let's take a look at that under a separate PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2910041204 From mchhipa at openjdk.org Mon May 26 15:11:50 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Mon, 26 May 2025 15:11:50 GMT Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> Message-ID: <9WV8wrYTbOPzYeRG13qM2D1YjqTzgzlQqqu9WYy_Uok=.77e6f0d3-442f-4b5a-9f5e-4c4c5e38bfa1@github.com> On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov wrote: > Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/25360#issuecomment-2910047397 From yujige at gmail.com Mon May 26 15:31:06 2025 From: yujige at gmail.com (Jige Yu) Date: Mon, 26 May 2025 08:31:06 -0700 Subject: [External] : Re: mapConcurrent() with InterruptedException In-Reply-To: References: Message-ID: Yeah, I think I missed the task cancellation and the joining part. When the mapConcurrent() thread is interrupted, it propagates the cancellation to the child threads. And if any of the children threads (running the user-provided Function) receives that cancellation, it will still need to catch it and handle interruption. That means the interruption isn't swallowed. If the user code wants to abort, they can always just throw an unchecked exception and catch it from the caller of mapConcurrent(). That should do for most of the IO type work. This makes sense. On Mon, May 26, 2025 at 12:30?AM Viktor Klang wrote: > Yes, the updated Gatherers.mapConcurrent will continue under interruption > until done, and then restore the interrupt status of the calling thread. > > It cannot (reasonably) do anything else?if it were to throw > InterruptedException, it couldn't since that is a checked exception and > there's no tracking of checked exceptions throughout a Stream, and that is > the specified behavior to handle thread interrupts (i.e. clear flag and > throw InterruptedException, which is not possible in this case; or, make > sure that interrupt status is maintained, which is possible in this case. > > I have given it some more thought in the meantime, but I haven't arrived > in something more satisfactory than that, yet. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Monday, 26 May 2025 03:07 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Thanks Viktor! > > Sorry, I was giving myself more time to read the code, but then I lost > track. > > If I'm reading the code right, the current behavior is that if the current > thread is interrupted, the mapConcurrent() would suppress the interruption > until all elements are processed? (It will then restore the interruption > bit) > > Doesn't this break fail fast? > > For example, I may have a mapConcurrent() called from within structured > concurrency, and that fans out to two operations: > ? > scope.fork(() -> doA()); > scope.fork(() -> doB()); // calls mapConcurrent() internally > scope.join().throwIfFailed(); > > If doA() fails, doB() will be cancelled (thread interrupted). > > If mapConcurrent() ignores the interruption, and if doB has a long list to > process, it'll continue to consume system resources even when the caller no > longer needs the results, no? > > > On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang > wrote: > > >Sorry, did the PR stop using Semaphore? > > No, not that PR. See: > https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e > > > The problem with interruption under parallel evaluation is that there is > no general support for propagation of interruption in CountedCompleters. > Adding support for such in (at least) GathererOp needs further study before > contemplating making any changes to mapConcurrent()'s interruption policy. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* Jige Yu > *Sent:* Thursday, 6 February 2025 17:04 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Sorry, did the PR stop using Semaphore? > > I had naively thought that mapConcurrent() will keep a buffer of Future of > all currently-running concurrent tasks (it can be a ConcurrentMap Future> if we don't have to ensure FIFO). > > Upon interruption, the main thread can call .cancel(true) on all pending > Futures; optionally join with the VTs (if we need to block until all VTs > exit); then propagate exception. > > Upon completion, each task just removes itself from the ConcurrentMap. > > Just in case it adds anything. > > > > On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang > wrote: > > After some more investigation it seems tractable to propagate interruption > of the caller in sequential mode, but parallel mode will require much > bigger considerations. > > I made a comment to that effect on the JBS issue: > https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017 > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Viktor Klang > *Sent:* Thursday, 6 February 2025 11:51 > *To:* Jige Yu > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > I think alignment in behavior between parallel Stream and mapConcurrent in > terms of how interruptions are handled is a possible path forward. > > I decided to close the PR for now as I realized my parallel Stream example > had misled me regarding its exception throwing, so I'll need to go back and > refine the solution. > > It still seems solvable though. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Wednesday, 5 February 2025 19:20 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Oh good call! > > I forgot to check what parallel streams do upon interruption (didn't think > they do any blocking calls, but at least the main thread must block). > > On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang > wrote: > > Hi Jige, > > I opened an issue to track the concern, and I have proposed a change which > seems to align well with how parallel streams behave under caller thread > interruption. > > I've opened the following PR for review: > https://github.com/openjdk/jdk/pull/23467 > > > If you are able to make a local OpenJDK build with that solution you could > check if it addresses your use-cases (or not). > > > 8349462: Gatherers.mapConcurrent could support async interrupts by > viktorklang-ora ? Pull Request #23467 ? openjdk/jdk > > This change is likely going to need some extra verbiage in the spec for > mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how > parallel streams work in conjunction with interrup... > github.com > > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Wednesday, 5 February 2025 16:24 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Thanks Viktor! > > I understand the problem. > > The main reason I asked is because I want to understand how the core Java > team thinks of throwing an unchecked exception. > > As explained above, I consider losing cancellability a big deal, a deal > breaker even. And I thought throwing unchecked is more acceptable. Because > the most common reason the mapConcurrent() VT can be interrupted is due to > cancellation from a parent mapConcurrent(), or a parent Structured > Concurrency scope. The cancellation could be either from an organic > exception, or from the downstream not needing more elements, like maybe due > to findFirst() already getting an element. > > In both cases, since the concurrent operation is already cancelled (result > ignored), what exception pops up to the top level isn't that big of a deal > (perhaps only a log record will be seen?) > > But if the core Java team considers it a bad idea, I would love to learn > and adjust. > > On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang > wrote: > > Hi, > > The problem is that mapConcurrent cannot throw InterruptedException > because that is a checked exception, so we cannot clear the interrupted > flag and throw that exception. > > So the updated semantics is to not cut the stream short but instead run to > completion, restoring the interruption flag. > > There exists a couple of alternatives to this approach which I am > contemplating, but they need to be further explored before I consider > moving forward with any of them. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Monday, 27 January 2025 17:00 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException > > Thanks Viktor! > > It looks like the current fix ignores interruption. > > I want to make sure my concern of it defeating cancellation is heard and > understood. > > The scenarios I worry about is for a mapConcurrent() that fans out to > another method call, which internally calls mapConcurrent() as > implementation detail. > > An example: > > List refundHelper(transaction) { > transaction.creditCardAccounts.stream() > .gather(mapConcurrent(acct -> service.refund(acct)) > .toList(); > } > > transactions.stream() > .gather(mapConcurrent(transaction -> refundHelper(transaction)); > > > It seems undesirable that in such a case all the service.refund() calls > become non cancellable, because the only way the outer mapConcurrent() > cancels the refundHelper() calls is through Thread.interrupt() the virtual > threads that call refundHelper(), which would then be disabled by the inner > mapConcurrent(). > > Does this example make sense to you? I can further explain if anything > isn't clear. > > But I want to make sure the decision to disable interruption is deliberate > judgement call that such nested mapConcurrent() is unlikely,or not > important. > > Cheers, > > > > On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang > wrote: > > Hi! > > Please see: https://github.com/openjdk/jdk/pull/23100 > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 26 January 2025 23:03 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* [External] : Re: mapConcurrent() with InterruptedException > > Checking in on what you've found out, Viktor. > > From where we left off, I understand that you were looking at alternatives > instead of silent truncation? > > Have you reached any conclusion? > > We touched on disallowing interruption during mapConcurrent(). I still > have concerns with disabling cancellation, because it basically undoes this > API note from the javadoc > > : > > API Note: In progress tasks will be attempted to be cancelled, on a > best-effort basis, in situations where the downstream no longer wants to > receive any more elements. > In reality, people will use mapConcurrent() to fan out rpcs. Sometimes > these rpcs are just a single blocking call; yet sometimes they may > themselves be a Structured Concurrency scope, with 2 or 3 rpcs that > constitute a single logical operation. Under two conditions, cancellation > is imho important semantic: > > 1. The downstream code uses filter().findFirst(), and when it sees an > element, it will return and no longer needs the other pending rpcs to > complete. If cancellation is disabled, these unnecessary rpcs will waste > system resources. > 2. One of the rpc throws and the Stream pipeline needs to propagate > the exception. Again, if the other rpcs cannot be cancelled, we'll have > many zombie rpcs. > > Zombie rpcs may or may not be a deal breaker, depending on the specific > use case. But for a JDK library, losing cancellation would have a negative > impact on usability. > > My 2c, > > > On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang > wrote: > > Hi Ben, > > Thanks for raising these questions?getting feedback is crucial in the > Preview stage of features. > > I wrote a reply to the Reddit thread so I'll just summarize here: > > It is important to note that *mapConcurrent()* is not a part of the > Structured Concurrency JEPs, so it is not designed to join SC scopes. > > I'm currently experimenting with ignoring-but-restoring interrupts on the > "calling thread" for *mapConcurrent()*, as well as capping > work-in-progress to *maxConcurrency* (not only capping the concurrency > but also the amount of completed-but-yet-to-be-pushed work). Both of these > adjustments should increase predictability of behavior in the face of > blocking operations with variable delays. > > Another adjustment I'm looking at right now is to harden/improve the > cleanup to wait for concurrent tasks to acknowledge cancellation, so that > once the finisher is done executing the VTs are known to have terminated. > > As for not preserving the encounter order, that would be a completely > different thing, and I'd encourage you to experiment with that if that > functionality would be interesting for your use-case(s). > > Again, thanks for your feedback! > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Friday, 3 January 2025 17:53 > *To:* core-libs-dev at openjdk.org > *Subject:* mapConcurrent() with InterruptedException > > Hi Java Experts, > > I sent this email incorrectly to loom-dev@ and was told on Reddit that > core-libs-dev is the right list. > > The question is about the behavior of mapConcurrent() when the thread is > interrupted. > > Currently mapConcurrent()'s finisher phase will re-interrupt the thread, > then stop at whatever element that has already been processed and return. > > This strikes me as a surprising behavior, because for example if I'm > running: > > Stream.of(1, 2, 3) > .gather(mapConcurrent(i -> i * 2)) > .toList() > > and the thread is being interrupted, the result could be any of [2], [2, > 4] or [2, 4, 6]. > > Since thread interruption is cooperative, there is no guarantee that the > thread being interrupted will just abort. It's quite possible that it'll > keep going and then will use for example [2] as the result of doubling the > list of [1, 2, 3], which is imho incorrect. > > In the Reddit > thread, > someone argued that interruption rarely happens so it's more of a > theoretical issue. But interruption can easily happen in Structured > Concurrency or in mapConcurrent() itself if any subtask has failed in order > to cancel/interrupt the other ongoing tasks. > > There had been discussion about alternative strategies: > > 1. Don't respond to interruption and just keep running to completion. > 2. Re-interrupt thread and wrap the InterruptedException in a standard > unchecked exception (StructuredConcurrencyInterruptedException?). > > > I have concerns with option 1 because it disables cancellation propagation > when mapConcurrent() itself is used in a subtask of a parent > mapConcurrent() or in a StructuredConcurrencyScope. > > Both equivalent Future-composition async code, or C++'s fiber trees > support cancellation propagation and imho it's a critical feature or else > it's possible that a zombie thread is still sending RPCs long after the > main thread has exited (failed, or falled back to some default action). > > My arguments for option 2: > > 1. InterruptedException is more error prone than traditional checked > exceptions for *users* to catch and handle. They can forget to > re-interrupt the thread. It's so confusing that even seasoned programmers > may not know they are *supposed to* re-interrupt the thread. > 2. With Stream API using functional interfaces like Supplier, > Function, the option of just tacking on "throws IE" isn't available to many > users. > 3. With Virtual Threads, it will be more acceptable, or even become > common to do blocking calls from a stream operation (including but > exclusive to mapConcurrent()). So the chance users are forced to deal with > IE will become substantially higher. > 4. Other APIs such as the Structured Concurrency API have already > started wrapping system checked exceptions like ExecutionException, > TimeoutException in unchecked exceptions ( join() > for > example). > 5. Imho, exceptions that we'd rather users not catch and handle but > instead should mostly just propagate up as is, should be unchecked. > > There is also a side discussion > about > whether mapConcurrent() is better off preserving input order or push to > downstream as soon as an element is computed. I'd love to discuss that > topic too but maybe it's better to start a separate thread? > > Thank you and cheers! > > Ben Yu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon May 26 15:48:10 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Mon, 26 May 2025 15:48:10 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null [v2] In-Reply-To: References: Message-ID: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com> > `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE. Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision: 8357597: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25419/files - new: https://git.openjdk.org/jdk/pull/25419/files/e70cb289..38854aa1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25419&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25419&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25419/head:pull/25419 PR: https://git.openjdk.org/jdk/pull/25419 From duke at openjdk.org Mon May 26 15:48:10 2025 From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=) Date: Mon, 26 May 2025 15:48:10 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null [v2] In-Reply-To: <_L16HJaL2iFRPFnS4dyzoVSbAx5jofgsWdOfMqpFq3E=.cb5f0a1d-4269-4e95-a3f5-181242a8050e@github.com> References: <_L16HJaL2iFRPFnS4dyzoVSbAx5jofgsWdOfMqpFq3E=.cb5f0a1d-4269-4e95-a3f5-181242a8050e@github.com> Message-ID: On Mon, 26 May 2025 05:43:49 GMT, Jaikiran Pai wrote: >> Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357597: Update copyright year > > The change looks OK to me. Please update the copyright year on the file from `1999, 2024,` to `1999, 2025,`. @jaikiran Thanks for spotting this. I've adjusted the copyright year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25419#issuecomment-2910140949 From liach at openjdk.org Mon May 26 15:50:54 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 May 2025 15:50:54 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null [v2] In-Reply-To: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com> References: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com> Message-ID: <9KttBy25fwV50qY-52hO7oGuHnCORBYEmsCpvAN80fU=.6f0f90ba-9247-45bd-b1e5-7c45bdd3ae91@github.com> On Mon, 26 May 2025 15:48:10 GMT, Steffen Nie?ing wrote: >> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE. > > Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision: > > 8357597: Update copyright year Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2868803766 From alanb at openjdk.org Mon May 26 15:52:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 15:52:55 GMT Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 12:54:06 GMT, Doug Lea

        wrote: >> Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException. > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > rethrow Errors in startDelayScheduler Latest version looks good, and Thread.start throwing OOME will be propagated. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25431#pullrequestreview-2868806444 From jpai at openjdk.org Mon May 26 15:56:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 May 2025 15:56:55 GMT Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null [v2] In-Reply-To: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com> References: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com> Message-ID: On Mon, 26 May 2025 15:48:10 GMT, Steffen Nie?ing wrote: >> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE. > > Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision: > > 8357597: Update copyright year Thank you for the update. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2868813762 From dfuchs at openjdk.org Mon May 26 15:59:50 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 May 2025 15:59:50 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed In-Reply-To: References: Message-ID: On Mon, 26 May 2025 12:28:16 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? > > As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. > > The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. > > tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 100: > 98: // Add a new reply to the queue of unprocessed replies. > 99: try { > 100: replies.put(ber); So theoretically this could get into the queue after one of the two markers has already been put in the queue, since we no longer use the lock. The question is: is this a problem? I'd be tempted to say no - except that getReplyBer() will take the markers out of the queue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2107600300 From jpai at openjdk.org Mon May 26 16:18:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 May 2025 16:18:50 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed In-Reply-To: References: Message-ID: On Mon, 26 May 2025 15:57:17 GMT, Daniel Fuchs wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? >> >> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. >> >> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. >> >> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. > > src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 100: > >> 98: // Add a new reply to the queue of unprocessed replies. >> 99: try { >> 100: replies.put(ber); > > So theoretically this could get into the queue after one of the two markers has already been put in the queue, since we no longer use the lock. The question is: is this a problem? I'd be tempted to say no - except that getReplyBer() will take the markers out of the queue. Hello Daniel, > I'd be tempted to say no - except that getReplyBer() will take the markers out of the queue. That's correct - the change intentionally removes the lock and also lets the close/cancel markers land into the queue so that if the `getReplyBer()` is already blocked in a `take()` or `poll()` call, then it will be unblocked and if it isn't yet blocked on those calls then a subsequent call will find these markers (which are distinct for close and cancel). Adding these (distinct) markers will also allow for an ordered identifiable content in the queue - some replies followed by close/cancel marker or a close/cancel marker followed by replies. Additionally, the `addRequest()`, `close()` and `cancel()` methods of this `LdapRequet` get called by a single thread managed by the `Connection` class, so there isn't expected to be concurrent calls across these methods. So, I think, removing the lock and letting the (distinct) markers end up in the queue makes this code in the `LdapRequest` simpler. The `getReplyBer()` the implementation polls the ordered queue, so it find all replies that have arrived before the cancel/close marker is encountered. Once it encounters those markers it can then throw the relevant exception as per its current specified behaviour. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2107620182 From shade at openjdk.org Mon May 26 16:41:24 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 May 2025 16:41:24 GMT Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init Message-ID: SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly Additional testing: - [x] Linux x86_64 server fastdebug, `java/util/concurrent` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/25452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357797 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25452/head:pull/25452 PR: https://git.openjdk.org/jdk/pull/25452 From alanb at openjdk.org Mon May 26 16:41:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 16:41:51 GMT Subject: RFR: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang wrote: > While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size). > > Includes a regression test which yields an OOME if this change is omitted. Looks okay, I assume you'll bump the copyright headers before integration. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25418#pullrequestreview-2868874619 From alanb at openjdk.org Mon May 26 16:44:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 16:44:52 GMT Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug In-Reply-To: References: Message-ID: On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon wrote: > Hi, > > This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines. > A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable. > > Thanks, > Michael test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 35: > 33: * @requires vm.debug == true & vm.continuations > 34: * @requires vm.gc.Z > 35: * @run main/othervm/timeout=400 -XX:+UnlockDiagnosticVMOptions Increasing the timeout is fine. There isn't anything in the bug report to suggest anything else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25331#discussion_r2107643430 From alanb at openjdk.org Mon May 26 16:49:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 16:49:51 GMT Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init In-Reply-To: References: Message-ID: On Mon, 26 May 2025 16:37:01 GMT, Aleksey Shipilev wrote: > SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util/concurrent` src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 70: > 68: this.joiner = joiner; > 69: this.threadFactory = threadFactory; > 70: this.flock = ThreadFlock.open((name != null) ? name : Objects.toIdentityString(this)); Unnecessary but okay. Do you mind moving it to the end of constructor as the fields are initialized in order declaration order in this constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25452#discussion_r2107647128 From dfuchs at openjdk.org Mon May 26 16:55:50 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 May 2025 16:55:50 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed In-Reply-To: References: Message-ID: On Mon, 26 May 2025 16:16:44 GMT, Jaikiran Pai wrote: > Additionally, the addRequest(), close() and cancel() methods of this LdapRequet get called by a single thread managed by the Connection class, so there isn't expected to be concurrent calls across these methods. I am not seeing that - close() is called by Connection.cleanup() which seems to be callable asynchronously. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2107652428 From msheppar at openjdk.org Mon May 26 17:10:54 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 17:10:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved. new file => copyright ? Copyright (c) 2025, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107664521 From shade at openjdk.org Mon May 26 17:16:01 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 May 2025 17:16:01 GMT Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes Message-ID: SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are allocating and using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the object allocation on common path to allow optional constant folding. We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state. Additional testing: - [x] Linux x86_64 server fastdebug, `java/util` ------------- Commit messages: - A bit better comment - Better fix - Fix Changes: https://git.openjdk.org/jdk/pull/25456/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25456&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357798 Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25456/head:pull/25456 PR: https://git.openjdk.org/jdk/pull/25456 From shade at openjdk.org Mon May 26 17:17:30 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 May 2025 17:17:30 GMT Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init [v2] In-Reply-To: References: Message-ID: > SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util/concurrent` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Move to the end ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25452/files - new: https://git.openjdk.org/jdk/pull/25452/files/711a3474..9518cb62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25452&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25452&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25452/head:pull/25452 PR: https://git.openjdk.org/jdk/pull/25452 From shade at openjdk.org Mon May 26 17:17:30 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 May 2025 17:17:30 GMT Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 16:46:49 GMT, Alan Bateman wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Move to the end > > src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 70: > >> 68: this.joiner = joiner; >> 69: this.threadFactory = threadFactory; >> 70: this.flock = ThreadFlock.open((name != null) ? name : Objects.toIdentityString(this)); > > Unnecessary but okay. Do you mind moving it to the end of constructor as the fields are initialized in order declaration order in this constructor. Yeah, explicit use of `ST_NEW` avoids future accidents, e.g. if we ever introduce a new state that would have to shuffle states around. Moved to the end of constructor now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25452#discussion_r2107669807 From alanb at openjdk.org Mon May 26 17:19:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 17:19:50 GMT Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:17:30 GMT, Aleksey Shipilev wrote: >> SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/util/concurrent` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Move to the end Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25452#pullrequestreview-2868916918 From msheppar at openjdk.org Mon May 26 17:31:54 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 17:31:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130: > 128: public abstract String output(); > 129: > 130: protected String output(boolean enhance) { to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot suggest refactor rename this method name to composeFilteredMessageText or composeFilteredText or just compose ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107682303 From msheppar at openjdk.org Mon May 26 17:42:59 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 17:42:59 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58: > 56: * public static SensitiveInfo filterUserName(String name) > 57: */ > 58: public final class Exceptions { maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107691017 From raffaello.giulietti at oracle.com Mon May 26 18:04:19 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 26 May 2025 20:04:19 +0200 Subject: Add @Stable to BigInteger and BigDecimal In-Reply-To: <21b4abad-0321-408e-92c2-a87c1ee2e010.shaojin.wensj@alibaba-inc.com> References: <21b4abad-0321-408e-92c2-a87c1ee2e010.shaojin.wensj@alibaba-inc.com> Message-ID: <505b67f5-a031-464e-861b-2438b004e5d8@oracle.com> Depending on which static final arrays, this might be fine. On 2025-05-26 01:57, wenshao wrote: > Some static final arrays of BigInteger and BigDecimal are stable and > immutable. We should add @Stable to give the optimizer more information > > - > Shaojin Wen From msheppar at openjdk.org Mon May 26 18:15:56 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 18:15:56 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/java/net/HostPortrange.java line 73: > 71: > 72: // first separate string into two fields: hoststr, portstr > 73: String hoststr = null, portstr = null; you could take the opportunity to update the HostPortrange constructor signature refactor rename the parameter str to hostname ;-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107715671 From rgiulietti at openjdk.org Mon May 26 18:49:01 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 26 May 2025 18:49:01 GMT Subject: RFR: 8357808: Add a command line option for specifying a counter in TestRandomFloatingDecimal Message-ID: Add a `-Dcount=N` command line option to specify the number of random samples per test (default is 10'000). ------------- Commit messages: - 8357808: Add a command line option for specifying a counter in TestRandomFloatingDecimal Changes: https://git.openjdk.org/jdk/pull/25460/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25460&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357808 Stats: 25 lines in 1 file changed: 18 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25460.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25460/head:pull/25460 PR: https://git.openjdk.org/jdk/pull/25460 From rgiulietti at openjdk.org Mon May 26 18:59:10 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 26 May 2025 18:59:10 GMT Subject: RFR: 8357808: Add a command line option for specifying a counter in TestRandomFloatingDecimal [v2] In-Reply-To: References: Message-ID: > Add a `-Dcount=N` command line option to specify the number of random samples per test (default is 10'000). Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Changed option name to "samples". ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25460/files - new: https://git.openjdk.org/jdk/pull/25460/files/982fd166..c95940a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25460&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25460&range=00-01 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/25460.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25460/head:pull/25460 PR: https://git.openjdk.org/jdk/pull/25460 From liach at openjdk.org Mon May 26 19:03:49 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 May 2025 19:03:49 GMT Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote: > SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are allocating and using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the object allocation on common path to allow optional constant folding. > > We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util` How is this an allocation? I examined `javap -c -p -v java.util.ReverseOrderListView` and confirmed this compiles to `Boolean.valueOf` in class files, which involves no new allocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2910469082 From msheppar at openjdk.org Mon May 26 19:09:53 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 19:09:53 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253: > 251: return; > 252: enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo"); > 253: enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket") This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket. Consider the following: includeInException specifies the type of information that maybe included in an enhanced exception e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All This defines an information policy developer are familiar with packages, so a second property specified the "domain" of application of an information policy: enhancedException.packages specifies a list of packages where the includeInException information policy will apply an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107759746 From swen at openjdk.org Mon May 26 19:20:06 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 26 May 2025 19:20:06 GMT Subject: RFR: 8357289: Break down the String constructor into smaller methods [v7] In-Reply-To: References: Message-ID: > Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline. > > The following is the output information of PrintInlining: > > @ 9 java.lang.String:: (12 bytes) inline (hot) > !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot) > ! @ 8 java.lang.String:: (852 bytes) failed to inline: hot method too big > > > In Java code, the big method that cannot be inlined is the following constructor > > > String(Charset charset, byte[] bytes, int offset, int length) {} > > The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25290/files - new: https://git.openjdk.org/jdk/pull/25290/files/4f3eea73..77c7249e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=05-06 Stats: 20 lines in 1 file changed: 0 ins; 15 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290 PR: https://git.openjdk.org/jdk/pull/25290 From alanb at openjdk.org Mon May 26 19:25:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 19:25:00 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> References: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> Message-ID: On Mon, 26 May 2025 19:06:56 GMT, Mark Sheppard wrote: >> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into 8348986-exceptions >> - update >> - reduced number of new categories >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Review update >> - review update >> - Merge branch 'master' into 8348986-exceptions >> - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 > > src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253: > >> 251: return; >> 252: enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo"); >> 253: enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket") > > This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket. > > Consider the following: > includeInException specifies the type of information that maybe included in an enhanced exception > e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All > This defines an information policy > > developer are familiar with packages, so a second property specified the "domain" of application of an information policy: enhancedException.packages specifies a list of packages where the includeInException information policy will apply > > an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages > This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket. I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo". It does mean repurposing the name but it's a good name going forward. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107784068 From msheppar at openjdk.org Mon May 26 20:24:50 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 20:24:50 GMT Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug In-Reply-To: References: Message-ID: <3klPqRWuHRjTINe-m0HnznQ7nnhJPgXCE65elhZTPT8=.8e0210c8-de03-41e4-bb73-3b17828462e4@github.com> On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon wrote: > Hi, > > This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines. > A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable. > > Thanks, > Michael it takes typically between 4 and 8 minutes for the test to complete. The current jtreg timeout is 20 minutes The important parts of the bug report are missing, that is the failure Handler details and in particular the jstack traces, thread dumps etc.. The failure handler was not fully run indicating that the JVM hand difficulty responding to various serviceability commands. If there are millions of virtual threads then providing those JVM details could be difficult. Allowing another 6 minutes could provide some extra time for the JVM to get through it shutdown work, if there was some impediment causing a delay in the termination of the othervm process, or a slow thread scheduling at the OS level. Otherwise it will be 26 minutes timeout rather than 20 mins This test has been recently run over 1000 times in a number test repeat runs with failure ... so its very much intermittent The fact that the process capture details were not obtained maybe indicative of a deeper issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25331#issuecomment-2910578033 From msheppar at openjdk.org Mon May 26 20:42:54 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 20:42:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt a builder pattern for the creation of the filter exceptions, for example FilteredExceptionBuilder / EnhancedExceptionBuilder. It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder. EnhancedExceptionBuilder::class() ::exceptionMessage() ::port() ::hostname() ::userDetails() ::filterPolicy() ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2910598238 From msheppar at openjdk.org Mon May 26 21:46:52 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 21:46:52 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> Message-ID: On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253: >> >>> 251: return; >>> 252: enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo"); >>> 253: enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket") >> >> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket. >> >> Consider the following: >> includeInException specifies the type of information that maybe included in an enhanced exception >> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All >> This defines an information policy >> >> developer are familiar with packages, so a second property specified the "domain" of application of an information policy: enhancedException.packages specifies a list of packages where the includeInException information policy will apply >> >> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages > >> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket. > > I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo". It does mean repurposing the name but it's a good name going forward. The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. But equally the setting hostInfoExclSocket suggests some knowledge of APIs is available, so there is a contradiction in the rationale presented above Also the setting enhancedNonSocketExceptionText is inclusive of the setting enhancedSocketExceptionText, which adds further subtleties to the configuration, which was previously suggested should be avoided. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107873149 From liach at openjdk.org Mon May 26 22:19:50 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 May 2025 22:19:50 GMT Subject: RFR: 8357808: Add a command line option for specifying a counter in TestRandomFloatingDecimal [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 18:59:10 GMT, Raffaello Giulietti wrote: >> Add a `-Dcount=N` command line option to specify the number of random samples per test (default is 10'000). > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changed option name to "samples". Looks reasonable. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25460#pullrequestreview-2869201038 From liach at openjdk.org Mon May 26 22:28:50 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 May 2025 22:28:50 GMT Subject: RFR: 8357681: Fixed the DigitList::toString method causing incorrect results during debugging In-Reply-To: References: Message-ID: On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen wrote: > When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results. This is a formatting-related class. Calling i18n devs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2910708066 From dl at openjdk.org Mon May 26 22:40:55 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 26 May 2025 22:40:55 GMT Subject: Integrated: 8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown In-Reply-To: References: Message-ID: On Sat, 24 May 2025 11:35:33 GMT, Doug Lea
        wrote: > Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException. This pull request has now been integrated. Changeset: 2c034f57 Author: Doug Lea
        URL: https://git.openjdk.org/jdk/commit/2c034f57d6b4229aaf195fdd6efd016cf694855f Stats: 34 lines in 2 files changed: 27 ins; 1 del; 6 mod 8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/25431 From alanb at openjdk.org Tue May 27 06:12:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 May 2025 06:12:53 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> Message-ID: On Mon, 26 May 2025 21:44:32 GMT, Mark Sheppard wrote: > The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. Right, what is now "hostInfoExclSocket" is a confusing category and not easy to explain to anyone. However it is the long standing default. If you relax the default then security people will complain. If you make it more strict then developers will complain as it makes troubleshooting harder. With the current proposal then nobody has to deal with this confusing named category. Instead, if you want reveal more exceptions then you run with the property set to hostInfo, a category that is much simpler to understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2108262111 From duke at openjdk.org Tue May 27 07:07:54 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 27 May 2025 07:07:54 GMT Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote: > SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are allocating and using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the object allocation on common path to allow optional constant folding. > > We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util` Well, this?does at?least make?`ReverseOrderListView` have?the?same layout?size as?before [JDK?8356080] and?no?longer grow?when `?XX:?UseCompressedOops` is?used. -------------------------------------------------------------------------------- Also, shouldn?t?`ReverseOrderListView`?s `final`?fields already?be?trusted to?be?immutable? [JDK?8356080]: https://bugs.openjdk.org/browse/JDK-8356080 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911387045 From shade at openjdk.org Tue May 27 07:38:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 May 2025 07:38:52 GMT Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes In-Reply-To: References: Message-ID: On Mon, 26 May 2025 19:01:35 GMT, Chen Liang wrote: > How is this an allocation? I examined `javap -c -p -v java.util.ReverseOrderListView` and confirmed this compiles to `Boolean.valueOf` in class files, which involves no new allocation. Yeah, I brain-fogged a little here. Still, it makes sense to avoid an _object_ when a primitive field would do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911481864 From alanb at openjdk.org Tue May 27 07:47:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 May 2025 07:47:50 GMT Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote: > SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding. > > We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util` Does SonarCloud scan source code or class files? I'm wondering if there is anything to feedback to them on this report. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911514103 From shade at openjdk.org Tue May 27 07:53:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 May 2025 07:53:56 GMT Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes In-Reply-To: References: Message-ID: <2A7YzhkDJCiTzT0ZmaL6XkuhjcE-tJFn72O7COye3Ts=.8abec49d-db63-4a9c-988c-cee328c5e081@github.com> On Tue, 27 May 2025 07:45:35 GMT, Alan Bateman wrote: > Does SonarCloud scan source code or class files? I'm wondering if there is anything to feedback to them on this report. I think both. But as I said, I misunderstood the report: it tells me we are using a boxed `Boolean`, likely unnecessarily -- which is true. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911530334 From michaelm at openjdk.org Tue May 27 08:16:32 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 27 May 2025 08:16:32 GMT Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug [v2] In-Reply-To: References: Message-ID: > Hi, > > This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines. > A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25331/files - new: https://git.openjdk.org/jdk/pull/25331/files/58cdec19..90f5874b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25331&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25331&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25331/head:pull/25331 PR: https://git.openjdk.org/jdk/pull/25331 From alanb at openjdk.org Tue May 27 08:19:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 May 2025 08:19:55 GMT Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug [v2] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 08:16:32 GMT, Michael McMahon wrote: >> Hi, >> >> This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines. >> A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > test update Okay ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25331#pullrequestreview-2870130662 From michaelm at openjdk.org Tue May 27 08:39:55 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 27 May 2025 08:39:55 GMT Subject: Integrated: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug In-Reply-To: References: Message-ID: On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon wrote: > Hi, > > This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines. > A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable. > > Thanks, > Michael This pull request has now been integrated. Changeset: 7cb6e5eb Author: Michael McMahon URL: https://git.openjdk.org/jdk/commit/7cb6e5eb3e004ad974a0c49e83014844f9f7cabb Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/25331 From shaojin.wensj at alibaba-inc.com Tue May 27 08:54:02 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Tue, 27 May 2025 16:54:02 +0800 Subject: =?UTF-8?B?QWRkIGBAU3RhYmxlYCB0byBCaWdJbnRlZ2VyIGFuZCBCaWdEZWNpbWFs?= Message-ID: <26da8afe-646c-4043-bba6-71bb3f6ad68b.shaojin.wensj@alibaba-inc.com> Some final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbaesken at openjdk.org Tue May 27 08:57:50 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 27 May 2025 08:57:50 GMT Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG de_DE.UTF-8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken wrote: >> On a 'german' Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test >> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with >> >> >> FEIN: hi now! >> java.lang.RuntimeException: System.err does not contain: FINE: hi now! >> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> >> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust LocalizedLevelName too Hi Daniel, thanks for the review ! how were the tests in your CI ? Noticed some download errors in the GHA, seems this caused a lot of (unrelated) test errors . ------------- PR Comment: https://git.openjdk.org/jdk/pull/25441#issuecomment-2911722135 PR Comment: https://git.openjdk.org/jdk/pull/25441#issuecomment-2911724854 From vklang at openjdk.org Tue May 27 09:19:57 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 27 May 2025 09:19:57 GMT Subject: Integrated: 8357647 : Stream gatherers forward upstream size information to downstream In-Reply-To: References: Message-ID: On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang wrote: > While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size). > > Includes a regression test which yields an OOME if this change is omitted. This pull request has now been integrated. Changeset: aea32ec5 Author: Viktor Klang URL: https://git.openjdk.org/jdk/commit/aea32ec5060a2e57947dc3e5d14613241e223ce4 Stats: 40 lines in 2 files changed: 37 ins; 1 del; 2 mod 8357647: Stream gatherers forward upstream size information to downstream Reviewed-by: liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25418 From duke at openjdk.org Tue May 27 09:28:19 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 27 May 2025 09:28:19 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v13] In-Reply-To: References: Message-ID: > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont 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 updates from master - More tweaking... - Tweaking exact wording. - Tweaking exact wording. - Don't use JUnit utils in TestNg. - Changes based on feedback - Changes based on feedback - Fixed test. - Changes based on review feedback. - Changes based on review feedback. - ... and 3 more: https://git.openjdk.org/jdk/compare/9c8b2f42...593c3a9b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/92355287..593c3a9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=11-12 Stats: 112295 lines in 2398 files changed: 65646 ins; 32848 del; 13801 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From vklang at openjdk.org Tue May 27 09:41:27 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 27 May 2025 09:41:27 GMT Subject: RFR: 8356553 : Incorrect uses of {@link} in AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer Message-ID: I had to tweak the language a bit to better reflect the intent of the text. ------------- Commit messages: - Updating the Javadoc of AQS and AQLS to link to a public version of the method Changes: https://git.openjdk.org/jdk/pull/25462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356553 Stats: 24 lines in 2 files changed: 1 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25462/head:pull/25462 PR: https://git.openjdk.org/jdk/pull/25462 From jai.forums2013 at gmail.com Tue May 27 09:44:06 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 27 May 2025 15:14:06 +0530 Subject: Add `@Stable` to BigInteger and BigDecimal In-Reply-To: <26da8afe-646c-4043-bba6-71bb3f6ad68b.shaojin.wensj@alibaba-inc.com> References: <26da8afe-646c-4043-bba6-71bb3f6ad68b.shaojin.wensj@alibaba-inc.com> Message-ID: Is this a duplicate of what's already being discussed here https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/146692.html? -Jaikiran On 27/05/25 2:24 pm, wenshao wrote: > Some final arrays of BigInteger and BigDecimal are stable and > immutable. We should add `@Stable` to give the optimizer more information > > - > Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Tue May 27 09:45:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 May 2025 09:45:56 GMT Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:17:30 GMT, Aleksey Shipilev wrote: >> SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/util/concurrent` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Move to the end Looks simple enough to me, and unlikely to cause conflicts/problems, so I am integrating now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25452#issuecomment-2911874358 From shade at openjdk.org Tue May 27 09:45:57 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 May 2025 09:45:57 GMT Subject: Integrated: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init In-Reply-To: References: Message-ID: On Mon, 26 May 2025 16:37:01 GMT, Aleksey Shipilev wrote: > SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util/concurrent` This pull request has now been integrated. Changeset: b9db99d7 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/b9db99d7f7e3720c7e34fbcd22ff9529054601f6 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/25452 From kbarrett at openjdk.org Tue May 27 10:02:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 May 2025 10:02:55 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v7] In-Reply-To: References: Message-ID: <_dk_yVITVE3bDKtFMBDvvjkgL8CylYo-m7X99EH9z1o=.c0a913a0-d25a-4205-9fcf-809172618a12@github.com> > Please review this change which adds a native method providing the > implementation of Reference::get. Referece::get is an intrinsic candidate, so > this native method implementation is only used when the intrinsic is not. > > Currently there is intrinsic support by the interpreter, C1, C2, and graal, > which are always used. With this change we can later remove all the > per-platform interpreter intrinsic implementations, and might also remove the > C1 intrinsic implementation. > > Testing: > (1) mach5 tier1-6 normal (so using all the existing intrinsics). > (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. Kim Barrett 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 'master' into native-reference-get - Merge branch 'master' into native-reference-get - use new waitForRefProc, some tidying - Merge branch 'master' into native-reference-get - remove timeout by using waitForReferenceProcessing - make ill-timed gc in non-concurrent case less likely - fix test package use - add package decl to test - parameterized return type of native get0 - test native method - ... and 1 more: https://git.openjdk.org/jdk/compare/ae6b12b7...4387e2fe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24315/files - new: https://git.openjdk.org/jdk/pull/24315/files/6b4e4c76..4387e2fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=05-06 Stats: 94918 lines in 1870 files changed: 55489 ins; 28462 del; 10967 mod Patch: https://git.openjdk.org/jdk/pull/24315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315 PR: https://git.openjdk.org/jdk/pull/24315 From aturbanov at openjdk.org Tue May 27 10:04:54 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 27 May 2025 10:04:54 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 11:52:34 GMT, Per Minborg wrote: >> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. >> >> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. >> >> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). >> >> This PR passes tier1, tier2, and tier3 on multiple platforms. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark to reflect new fill method test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java line 53: > 51: @State(Scope.Thread) > 52: @OutputTimeUnit(TimeUnit.NANOSECONDS) > 53: @Fork(value = 3, jvmArgs = { "--add-opens=java.base/jdk.internal.misc=ALL-UNNAMED","--add-opens=java.base/jdk.internal.foreign=ALL-UNNAMED"}) Suggestion: @Fork(value = 3, jvmArgs = {"--add-opens=java.base/jdk.internal.misc=ALL-UNNAMED", "--add-opens=java.base/jdk.internal.foreign=ALL-UNNAMED"}) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2108774005 From markus at headcrashing.eu Tue May 27 11:14:40 2025 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 27 May 2025 13:14:40 +0200 Subject: RFC: 8357183: Improving efficiency of Writer::append(CharSequence) and Writer::append(CharSequence, int, int) / Sub Task of 8356679: Using CharSequence::getChars internally In-Reply-To: <3b5d20ae-ba24-4f55-ba04-8931821510df@oracle.com> References: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com> <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com> <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com> <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu> <3b5d20ae-ba24-4f55-ba04-8931821510df@oracle.com> Message-ID: <370a4f5a-4847-447b-ab28-cd2213015da3@headcrashing.eu> > > Writer was retrofitted to implement Appendable in JDK 5 with the 3-arg > append documented to behave "in exactly the same as ..." the > write(String) method. That's 20 years of subclasses that might be > depending on this behavior. Also 20 years of subclasses that may > depend on the 3-arg append calling the 1-arg append. So my initial > reaction is that the risk may not be low and this proposal will > require significant analysis of Writer implementations before the > compatibility risk can be assessed. > > -Alan Nobody intends to hastily merge this. I already wrote (multiply) that an intensive analysis has to be performed and a KI? based analysis of Github WAS already performed. From duke at openjdk.org Tue May 27 11:30:40 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 27 May 2025 11:30:40 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v14] In-Reply-To: References: Message-ID: <3SOzBKrNslFY6xVPq1TgAeX5eSiaPpy1Jo_VXjEqcE8=.2de6ca06-97ce-43cd-a4a1-3b2a39c95192@github.com> > Adding read-only support to ZipFileSystem. > > The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned. > > This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate. > > By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Tweak wording again... ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25178/files - new: https://git.openjdk.org/jdk/pull/25178/files/593c3a9b..3e93e53f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178 PR: https://git.openjdk.org/jdk/pull/25178 From msheppar at openjdk.org Tue May 27 11:30:52 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 27 May 2025 11:30:52 GMT Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> Message-ID: <2BJWUoiV5qr1LC0SYK64C2y1_X8hJTsNzI3MXvTf8qA=.884e686a-8724-4eb7-8178-9e632144dae0@github.com> On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov wrote: > Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test Marked as reviewed by msheppar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25360#pullrequestreview-2870691165 From liach at openjdk.org Tue May 27 11:35:52 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 May 2025 11:35:52 GMT Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after JDK-8356080 In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote: > SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding. > > We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util` If we do use byte, please add constant static final fields instead of magic that requires navigation from pass site to fields. Pinging @minborg too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2912178849 From duke at openjdk.org Tue May 27 11:36:53 2025 From: duke at openjdk.org (duke) Date: Tue, 27 May 2025 11:36:53 GMT Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> Message-ID: <1NzQLsy5gde9k1Lt7Tg4Npe9w6JhZ8qEeF1Fll1j6sE=.bd5f3774-b7fd-48ef-a7b3-a0e436f97604@github.com> On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov wrote: > Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test @serhiysachkov Your change (at version a977e3ca9cc40f0a2af2d8faaf5cfd8adace60f2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25360#issuecomment-2912179884 From duke at openjdk.org Tue May 27 11:40:57 2025 From: duke at openjdk.org (serhiysachkov) Date: Tue, 27 May 2025 11:40:57 GMT Subject: Integrated: 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com> Message-ID: On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov wrote: > Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test This pull request has now been integrated. Changeset: b4b11d77 Author: Serhiy Sachkov Committer: Mark Sheppard URL: https://git.openjdk.org/jdk/commit/b4b11d777137c21c8808bbba5bdf20a2b4ff5be6 Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 mod 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test Reviewed-by: msheppar ------------- PR: https://git.openjdk.org/jdk/pull/25360 From shade at openjdk.org Tue May 27 12:02:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 May 2025 12:02:55 GMT Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after JDK-8356080 In-Reply-To: References: Message-ID: On Tue, 27 May 2025 11:33:28 GMT, Chen Liang wrote: > If we do use byte, please add constant static final fields instead of magic that requires navigation from pass site to fields. My initial version did this, and IMO it was worse off: https://github.com/openjdk/jdk/pull/25456/commits/06d3f7feb0565d8bc5f662e5696e10a56aeded37. Positive/negative maps to true/false pretty well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2912250157 From pminborg at openjdk.org Tue May 27 12:03:41 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 12:03:41 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v6] In-Reply-To: References: Message-ID: <-_-E4pvswblhrUiDwCgk8Rh9UiBRlmpsaqmCWjnx7gQ=.4b6598f9-eecf-4f35-b599-326fe4de8a88@github.com> > This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes. > > This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced. > > It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code). > > This PR passes tier1, tier2, and tier3 on multiple platforms. 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 seven additional commits since the last revision: - Merge branch 'master' into fill-overlap - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java Co-authored-by: Andrey Turbanov - Update benchmark to reflect new fill method - Simplify - Add case for long operations and break out methods - Correct typo in comment - Simplify the fill method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25383/files - new: https://git.openjdk.org/jdk/pull/25383/files/5c878bbd..d0cd7bbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=04-05 Stats: 57007 lines in 827 files changed: 38176 ins; 13844 del; 4987 mod Patch: https://git.openjdk.org/jdk/pull/25383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383 PR: https://git.openjdk.org/jdk/pull/25383 From pminborg at openjdk.org Tue May 27 12:10:52 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 12:10:52 GMT Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5] In-Reply-To: References: Message-ID: <_3aObg-v3Yux4WGDVwd1hxFFtF3bQ7WgmVRaBySEXxo=.6b86e557-8abd-4fc6-b80b-653488242b55@github.com> On Mon, 26 May 2025 15:06:02 GMT, Per Minborg wrote: > > Can we remove all meaningless `!Architecture.isLittleEndian()` calls and use the platform-specific endianness unsafe primitives instead? For compensation, we can add a check in each of fill2/fill3/fill4 that `assert value == Integer/Short/Long.reverseBytes(value)` if you think that is necessary. > > Let's take a look at that under a separate PR. https://bugs.openjdk.org/browse/JDK-8357857 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2912269520 From liach at openjdk.org Tue May 27 12:16:51 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 May 2025 12:16:51 GMT Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after JDK-8356080 In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote: > SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding. > > We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/util` Sure, I think I will hear what per minborg prefers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2912286080 From pminborg at openjdk.org Tue May 27 13:09:58 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 13:09:58 GMT Subject: RFR: 8356706: Foreign tests timeout after passing on linux-x64-zero In-Reply-To: References: Message-ID: On Thu, 15 May 2025 09:49:10 GMT, Per Minborg wrote: > This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin). I am closing this PR without integrating, as it has been fixed elsewhere (see issue) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25248#issuecomment-2912450694 From pminborg at openjdk.org Tue May 27 13:09:58 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 13:09:58 GMT Subject: Withdrawn: 8356706: Foreign tests timeout after passing on linux-x64-zero In-Reply-To: References: Message-ID: On Thu, 15 May 2025 09:49:10 GMT, Per Minborg wrote: > This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25248 From dfuchs at openjdk.org Tue May 27 13:36:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 27 May 2025 13:36:56 GMT Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4] In-Reply-To: References: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com> <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com> Message-ID: On Mon, 19 May 2025 12:24:28 GMT, Jaikiran Pai wrote: >> Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did: >> >> >> diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java >> index e2fddd96fe8..f54b5360ac5 100644 >> --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java >> +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java >> @@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem { >> private final Path zfpath; >> final ZipCoder zc; >> private final ZipPath rootdir; >> - // Starts in readOnly (safe mode), but might be reset at the end of initialization. >> - private boolean readOnly = true; >> + private final boolean readOnly; >> >> // default time stamp for pseudo entries >> private final long zfsDefaultTimeStamp = System.currentTimeMillis(); >> @@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) { >> >> // Determining a release version uses 'this' instance to read paths etc. >> Optional multiReleaseVersion = determineReleaseVersion(env); >> - >> - // Set the version-based lookup function for multi-release JARs. >> - this.entryLookup = >> - multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity()); >> - >> // We only allow read-write zip/jar files if they are not multi-release >> // JARs and the underlying file is writable. >> this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath); >> @@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) { >> : "the ZIP file is not writable"; >> throw new IOException(reason); >> } >> + // Set the version-based lookup function for multi-release JARs. >> + this.entryLookup = >> + multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity()); >> + >> } >> >> /** >> >> >> >> >> With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change. >> >> Making it `final` and having... > > On second thought, may be this isn't enough. I see that I missed the fact that `determineReleaseVersion()` requires access to `this`. Please leave this in the current form that you have in your PR. I need a few more moments to consider if anything needs to be changed. final members are good! Alternatively if making it final is not an option you could consider replacing: private boolean readOnly; with private boolean readWrite; I looked at where `readOnly` was used and there are not that many places, so inverting the flag might not be too intrusive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2109210071 From alanb at openjdk.org Tue May 27 14:01:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 May 2025 14:01:19 GMT Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a ByteBuffer throw UOE if backed by shared memory segment In-Reply-To: References: Message-ID: On Tue, 20 May 2025 07:37:34 GMT, Per Minborg wrote: > This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used. > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Marked as reviewed by alanb (Reviewer). I think the src changes are good. There are 13 methods across the 5 APIs that need tests for confined/shared/auto to ensure that we have all cases covered. The tests in the PR are okay but I think we will need a follow-on JBS issue to cover all the cases and avoid surprises. ------------- PR Review: https://git.openjdk.org/jdk/pull/25321#pullrequestreview-2871212681 PR Comment: https://git.openjdk.org/jdk/pull/25321#issuecomment-2912622466 From aph at openjdk.org Tue May 27 15:36:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 May 2025 15:36:14 GMT Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8] In-Reply-To: References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com> Message-ID: On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic). >> >> >> Benchmark (aligned) (size) Mode Cnt Score Error Units >> MemorySegmentFillUnsafe.panama true 262143 avgt 10 7295.638 ? 0.422 ns/op >> MemorySegmentFillUnsafe.panama false 262143 avgt 10 8345.300 ? 80.161 ns/op >> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ? 0.180 ns/op >> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ? 0.232 ns/op > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Copyright format correction > One thing that sometimes helps is a count leading zeroes followed by a multiway switch at the start, or just before the tail, to get started at the right place in the tail (its log-size cascade), for very small inputs. > > This PR #25383 uses clz in that way. > > It also uses an overlapping-store technique to reduce an O(lg N) tail to an O(1) tail, which also depends on the clz step. > My rough notes on the relative performance of overlapping loads and stores are here FWIW: https://cr.openjdk.org/~jrose/jvm/PartialMemoryWord.cpp Mmm, interesting. I had a look at the M1 timings to see what might be going on, and I think it's because the processor can in each clock execute 8 instructions but only one taken branch. It can, however, execute two not-taken branches per clock. At present, if our block is 1 (mod 64) bytes long, then we have a string of 5 taken branches and 1 not-taken branch. However, I couldn't see anything in the JMH results. I realized on closer inspection that performance was very much limited by the C2-generated caller, which is doing far more work than the intrinsic itself. I eventually tweaked the benchmark to call the intrinsic 1000 times, and trivially converting us to ns. I'm not keen on the overlapping-store technique in this case because the code gets IMHO unjustifiably complex, but also we would have different timing behaviour for differently aligned fill operations. This seems to me a bit much for something that should be fairly simple. I did, however, implement the clz-optimized tail. It's great for very short strings (mod 64) but it's worse for the range 32...63 (mod 64). It's also missing the early exit from the log-size cascade, which short-circuits fills that are a whole number of words long. I tried another thing, which was to have _two_ cascades: one of whole-word-sized stores, and one from 0 to 7 bytes. This was better for fills that are a whole number of words long and some other cases, but had its own timing spikes in a few places (e.g. 36 bytes.) I measured the total time for arrays of size 1-128 bytes, and took the average throughput. A: this PR, as checked in. 6.5 cycles/op, 1.8ns. B: one clz-optimized tail. 6.9 cycles/op, 1.9ns. C: two clz-optimized tails. 7.2 cycles/op, 2.0ns. In conclusion: there isn't much in it. We could do better by keeping this code as short as possible, which would allow us to inline the whole thing into its caller rather than the palaver of a C-ABI call to the stub. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2913030626 From duke at openjdk.org Tue May 27 15:38:15 2025 From: duke at openjdk.org (Edoardo Luppi) Date: Tue, 27 May 2025 15:38:15 GMT Subject: RFR: 8266013: Unexpected replacement character handling on stateful CharsetEncoder [v2] In-Reply-To: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com> References: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com> Message-ID: On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi wrote: >> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data. >> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset. >> EBCDIC Mix charset encoder is stateful encoder. >> Shift code should be added by switching character set. >> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F" >> SI is not in right place. >> >> Also ISO2022 related charsets use escape sequence to switch character set. >> But same kind of issue is there. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > 8266013: Unexpected replacement character handling on stateful CharsetEncoder Hey! Any way this PR could be picked up again? It could be split into two parts, one for EBCDIC, and one for ISO. The EBCDIC part should be straightforward as it should not impact template files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/3719#issuecomment-2913031847 From nbenalla at openjdk.org Tue May 27 15:53:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 27 May 2025 15:53:51 GMT Subject: RFR: 8356553 : Incorrect uses of {@link} in AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer In-Reply-To: References: Message-ID: On Tue, 27 May 2025 09:35:51 GMT, Viktor Klang wrote: > I had to tweak the language a bit to better reflect the intent of the text. Thanks for doing this! There are no longer any links to private types in `java.util.concurrent` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25462#issuecomment-2913093192 From naoto at openjdk.org Tue May 27 16:03:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 May 2025 16:03:53 GMT Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v5] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 07:18:59 GMT, Alan Bateman wrote: > I assume you've done some "test repeat" jobs to ensure that any variance in the version of "expect" on test machines doesn't cause any issues. Actually I have not. Thanks for reminding. So I ran this through our internal CI on Linux x64, macOS x64, and macOS AArch64. Across 10 tasks (i.e., machines), each with 30 repetitions, that?s a total of 900 test runs?all completed without failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2913132945 From rgiulietti at openjdk.org Tue May 27 16:22:58 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 27 May 2025 16:22:58 GMT Subject: RFR: 8356891: Some code simplifications in BigInteger [v22] In-Reply-To: References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com> Message-ID: <6D8Ue6zaCiXkmqoEjxeugzD4cGKc6l_ks9pa9Monc-0=.3e9d38a4-4276-4090-aafb-9c8795eddf95@github.com> On Wed, 21 May 2025 09:12:49 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Correct typo in comment src/java.base/share/classes/java/math/BigInteger.java line 4547: > 4545: * If the source is trusted the copying may be skipped. > 4546: */ > 4547: private static int[] stripLeadingZeroInts(int[] val, boolean trusted) { I suggest to restore `trustedStripLeadingZeroInts()`, with an implementation that just invokes this one with `trusted` set to `true`. And then restore the `trustedStripLeadingZeroInts()` invocations. The name is more intent-revealing and somewhat more conventional. src/java.base/share/classes/java/math/BigInteger.java line 4732: > 4730: /* Allocate output array. If all non-sign ints are 0x00, we must > 4731: * allocate space for one extra output int. */ > 4732: for (i = a.length - 1; i >= keep && a[i] == 0; i--) // Skip trailing zeros I think there's no need to check for `i >= keep`. Suggestion: for (i = a.length - 1; a[i] == 0; i--) // Skip trailing zeros ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2109478579 PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2109510018 From henryjen at openjdk.org Tue May 27 16:23:47 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 27 May 2025 16:23:47 GMT Subject: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v15] In-Reply-To: References: Message-ID: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Henry Jen 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: - Merge remote-tracking branch 'openjdk/master' into open - Merge remote-tracking branch 'openjdk/master' into open - Minor tweaks - Assure >0 exit code and fix typos - Validator to take a file, use term JAR file - Mismatched order is considered invalid - Adapt review feedback - Address review feedback - Adjust message based on review feedback - Move all validation into EntryValidator, update the document - ... and 7 more: https://git.openjdk.org/jdk/compare/e7422102...2690e69f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24430/files - new: https://git.openjdk.org/jdk/pull/24430/files/bf82d668..2690e69f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=13-14 Stats: 130765 lines in 2801 files changed: 79963 ins; 35168 del; 15634 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From joehw at openjdk.org Tue May 27 16:27:56 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 27 May 2025 16:27:56 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote: > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. java.xml changes look good to me. But as you already asked, the translation team owns most of these files. ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2871771071 From jlu at openjdk.org Tue May 27 16:34:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 27 May 2025 16:34:52 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: On Mon, 26 May 2025 08:25:30 GMT, Magnus Ihse Bursie wrote: >> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. > > @justin-curtis-lu Are these files handled by the translation team? @magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913234396 From naoto at openjdk.org Tue May 27 16:37:56 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 May 2025 16:37:56 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5f
      ScriptNewOld