Re: RFR: 8356080: Address post-integration comments for Stable Values [v3]

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 shou

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3]

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 >>> 16

Integrated: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out

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 t

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v6]

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 iss

Re: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath [v3]

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 > a

Re: RFR: 8356420: Provide examples on wrapping System.in [v6]

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. > > Nao

Re: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

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/Fo

Re: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v2]

> 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://

Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3]

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: >> h

Re: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v10]

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).

Re: RFR: 8356420: Provide examples on wrapping System.in [v6]

> 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 a

Re: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v7]

> 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_OPT

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

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 objec

Re: RFR: 8356420: Provide examples on wrapping System.in [v5]

> 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 a

Re: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v12]

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 fo

Re: RFR: 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default

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 R

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

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. > > Nao

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

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. > > Nao

RFR: 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default

`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:

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

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. > > Nao

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

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

Re: RFR: 8356644: Update encoding declaration to UTF-8

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 eff

Re: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v6]

> 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_OPT

Re: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v3]

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 i

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v18]

> 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

Re: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5]

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-com

Re: RFR: 8355393: Create a Test case to have special cases coverage for currency.getInstance() [v2]

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

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

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. > > Nao

Re: RFR: 8077587: BigInteger Roots [v10]

> 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 an

Re: RFR: 8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory [v4]

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

Re: RFR: 8356420: Provide examples on wrapping System.in [v3]

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: * } >>

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

> 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 a

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v17]

> 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

Re: RFR: 8077587: BigInteger Roots [v9]

> 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

Re: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5]

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-com

Re: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5]

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-com

Re: RFR: 8356420: Provide examples on wrapping System.in [v3]

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: Usuall

Re: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5]

> 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_OPT

Re: RFR: 8356080: Address post-integration comments for Stable Values [v3]

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 wit

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v16]

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

Re: RFR: 8356080: Address post-integration comments for Stable Values [v3]

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 collec

Re: RFR: 8356080: Address post-integration comments for Stable Values [v2]

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-follow

Re: RFR: 8356080: Address post-integration comments for Stable Values [v3]

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 collec

Integrated: 8348351: Improve lazy initialization of the available currencies set

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

Re: RFR: 8348351: Improve lazy initialization of the available currencies set [v2]

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 inclu

Re: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7]

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 incremen

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3]

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: *

Re: RFR: 8077587: BigInteger Roots [v8]

> 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

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3]

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: *

Re: RFR: 8077587: BigInteger Roots [v7]

> 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.o

Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3]

> 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 >

Integrated: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME

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

Re: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME

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

Re: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME

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

Re: RFR: 8353197: Document preconditions for JavaLangAccess methods [v5]

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/shar

Re: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7]

> 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 mer

Re: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME

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

Re: RFR: 8077587: BigInteger Roots [v6]

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

Re: RFR: 8353197: Document preconditions for JavaLangAccess methods [v6]

> 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: Ro

Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v2]

> 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 >

Re: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v3]

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 i

Re: RFR: 8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory [v4]

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); >> >> T

Re: RFC: 8356679: Using CharSequence::getChars internally

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 in

Re: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v3]

> 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:

Re: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property [v2]

> 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:

Re: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property

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

Re: RFR: 8077587: BigInteger Roots [v6]

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

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v6]

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 iss

Re: RFR: 8353197: Document preconditions for JavaLangAccess methods [v5]

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 revisi

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.

RFC: 8356679: Using CharSequence::getChars internally

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 Devel

Proposal: Add new methods get(int) and set(int, E) to ArrayDeque

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

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 S

RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager

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://d

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v3]

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 l

RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME

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/

Re: potential performance improvement in sun.nio.cs.UTF_8

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

Re: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v4]

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-comm

Re: RFR: 8356694: Removed unused subclass audits in ObjectInput/OutputStream

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 th

Re: RFR: 8356694: Removed unused subclass audits in ObjectInput/OutputStream

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 th

Re: RFR: 8356080: Address post-integration comments for Stable Values [v3]

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 collec

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v6]

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 iss

Re: potential performance improvement in sun.nio.cs.UTF_8

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 a

Re: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

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.jav

Re: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

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.

Re: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

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

Re: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

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

RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

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 head

Re: RFR: 8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

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

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v6]

> 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 u

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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. A

Re: RFR: 8350765: Need to pin when accessing thread container from virtual thread [v2]

> 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 c

Re: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class

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

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v5]

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 iss

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v5]

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 runni

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v5]

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 >

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v5]

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 iss

Re: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]

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

Re: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out [v5]

> 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 u

Re: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with empty file data [v3]

> 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 in

  1   2   >