Re: RFR: 8354242: VectorAPI: combine vector not operation with compare [v8]

On Wed, 11 Jun 2025 05:08:35 GMT, Emanuel Peter wrote: >> erifan has updated the pull request incrementally with one additional commit >> since the last revision: >> >> Support negating unsigned comparison for BoolTest::mask >> >> Added a static method `negate_mask(mask btm)` into BoolTe

Re: RFR: 8354242: VectorAPI: combine vector not operation with compare [v8]

On Fri, 6 Jun 2025 10:38:11 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)) >> => (VectorMas

Re: RFR: 8354242: VectorAPI: combine vector not operation with compare [v8]

On Fri, 6 Jun 2025 10:38:11 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)) >> => (VectorMas

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v7]

On Tue, 22 Apr 2025 19:36:00 GMT, Artur Barashev wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 499 commits: >> >> - merge latest changes from master branch >> - http3: improve H3ConnectionPoolTest.java >

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v7]

On Fri, 6 Jun 2025 12:00:37 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](http

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v7]

On Fri, 6 Jun 2025 12:00:37 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](http

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v7]

On Fri, 6 Jun 2025 12:00:37 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](http

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v7]

On Fri, 6 Jun 2025 12:00:37 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](http

RFR: 8358819: The first year is not displayed correctly in Japanese Calendar

This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "元" rather than the numeral "1". The issue ari

Re: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]

On Thu, 15 May 2025 23:59:41 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, a

Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v9]

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

Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v8]

On Tue, 10 Jun 2025 16:37:26 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use a fixed threashold for fill > > src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java

Re: RFR: 8345292: Improve javadocs for MemorySegment::getStrings defining word boundary cases [v2]

On Tue, 10 Jun 2025 15:50:08 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update after comments > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1302: > >> 1300

Re: RFR: 8345292: Improve javadocs for MemorySegment::getStrings defining word boundary cases [v2]

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset > charset)` method documentation with respect to multi-octet concerns. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update after comments

Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v8]

On Thu, 5 Jun 2025 19:05: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 ha

Re: javac confused by generics on class?

I've replied here (and moved the thread in compiler-dev) -- please follow up there if anything feels missing: https://mail.openjdk.org/pipermail/compiler-dev/2025-June/030756.html Maurizio On 10/06/2025 17:20, Éamonn McManus wrote: This question would probably be better asked on Stack Overflow

Re: javac confused by generics on class?

This question would probably be better asked on Stack Overflow or the like. The short answer is that the compiler is following the language spec. §4.8 says: > The type of a constructor (§8.8

Re: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v6]

On Tue, 10 Jun 2025 10:13:20 GMT, Viktor Klang wrote: >> kabutz has updated the pull request incrementally with one additional commit >> since the last revision: >> >> Whitespace > > src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java > line 225: > >> 223: ++co

Re: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v8]

> 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

Re: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v7]

> 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

Re: RFR: 8345292: Improve javadocs for MemorySegment::getStrings defining word boundary cases

On Tue, 10 Jun 2025 09:01:17 GMT, Per Minborg wrote: > This PR proposes to improve the 'MemorySegment.getString(long offset, Charset > charset)` method documentation with respect to multi-octet concerns. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1301: > 1299: *

javac confused by generics on class?

Hello, When doing refactorings to take advantage of newer Java features, I hit a new and weird edge case. I trimmed down the code several times, and ended up with the following tiny reproducer, and I don't understand what javac is complaining about even with javac 24: (Note: unlike the original c

Re: RFR: 8358880: Performance of parsing with DecimalFormat can be improved [v3]

On Mon, 9 Jun 2025 22:41:21 GMT, Johannes Graham wrote: >> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not >> throw NumberFormatException/ArithmeticException, but ParseException, so if >> this piece of code need to throw something, it should be `ParseException` > > The `

Re: RFR: 8358880: Performance of parsing with DecimalFormat can be improved [v3]

> This PR replaces construction of intermediate strings to be parsed with more > direct manipulation of numbers. It also has a more streamlined mechanism of > handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong` > > As a small side-effect it also eliminates the use of a

Re: RFR: 8359067: Fix typo in DelayScheduler.java

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) wrote: > Rename auxilliary to auxiliary Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25685#pullrequestreview-2913582933

Re: RFR: 8359067: Fix typo in DelayScheduler.java

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) wrote: > Rename auxilliary to auxiliary Marked as reviewed by vklang (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25685#pullrequestreview-2913606115

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v39]

> 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

Withdrawn: 8355393: Create a Test case to have special cases coverage for currency.getInstance()

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

Re: RFR: 8359067: Fix typo in DelayScheduler.java

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) wrote: > Rename auxilliary to auxiliary Thanks for finding and fixing this. - Marked as reviewed by dl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25685#pullrequestreview-2912920005

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v2]

On Fri, 25 Apr 2025 19:07:37 GMT, Artur Barashev wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 409 commits: >> >> - merge latest changes from master branch >> - http3: add missing separator to Http3Disc

Re: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v6]

On Mon, 9 Jun 2025 16:53:07 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 beha

Re: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]

On Thu, 15 May 2025 23:59:41 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, a

Re: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]

On Thu, 15 May 2025 23:59:41 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, a

RFR: 8345292: Improve javadocs for MemorySegment::getStrings defining word boundary cases

This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns. - Commit messages: - Add info for multi-octet Charsets Changes: https://git.openjdk.org/jdk/pull/25715/files Webrev: https://webrevs.

Re: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment

On Mon, 2 Jun 2025 16:03:49 GMT, Christian Stein wrote: >> right I agree that if there is common code we should extract it in a helper >> method > > Or the handling of `#` can be merged with the previous case ... somehow. Extracting a method wouldn't really simplify the code, as many local vari

Re: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2]

On Mon, 9 Jun 2025 04:03:28 GMT, David Holmes wrote: >> test/lib/jdk/test/lib/process/OutputBuffer.java line 150: >> >>> 148: this.p = p; >>> 149: logProgress("Gathering output"); >>> 150: boolean verbose = Boolean.getBoolean("outputanalyzer.verbose"); >> >> Putting a system p