On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu wrote:
> Please review this PR which improves occurrences of lazy computation in
> `Locale` and `BaseLocale`.
>
> Existing lazy initialization strategies such as CHM, static nested class, and
> local inner class are replaced with Stable Values.
>
> L
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
On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato wrote:
>> The parallel loading of JavaTimeSupplementary was a historical artifact from
>> the introduction of JSR 310, which additionally loads resouces that had not
>> existed before. Since the COMPAT locale provider which relied on this
>> mechanis
On Fri, 2 May 2025 03:53:23 GMT, Shaojin Wen wrote:
>> This is an optimization for decimal Integer.parseInt and Long.parseLong,
>> which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance
>> improvements
On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) wrote:
> Rename auxilliary to auxiliary
Marked as reviewed by syan (Committer).
What does `chore` mean
I create a JBS issue for this PR
https://bugs.openjdk.org/browse/JDK-8359067, you should change the PR title to
"8359067: Fix typo in DelaySch
Rename auxilliary to auxiliary
-
Commit messages:
- chore: Fix typo in DelayScheduler
Changes: https://git.openjdk.org/jdk/pull/25685/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25685&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8359067
Stats: 1 line in 1 fi
On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu wrote:
>> Please review this PR which improves occurrences of lazy computation in
>> `Locale` and `BaseLocale`.
>>
>> Existing lazy initialization strategies such as CHM, static nested class,
>> and local inner class are replaced with Stable Values.
>
Relax testing the inequality `usable_space <= free_space` to testing the
inequality `usable_space <= total_space`.
-
Commit messages:
- 8351010: Test java/io/File/GetXSpace.java failed: / usable space 56380809216
> free space 14912244940
Changes: https://git.openjdk.org/jdk/pull/2
On Mon, 9 Jun 2025 21:45:12 GMT, Naoto Sato wrote:
>> I will leave this question to I18N reviewers, who are ultimately in charge
>> of DigitList.
>
> The existing implementation does not throw
> `NumberFormatException`/`ArithmeticException`, but `ParseException` if
> parsing is failing. I woul
On Mon, 9 Jun 2025 22:03:37 GMT, Johannes Graham wrote:
>> The existing implementation does not throw
>> `NumberFormatException`/`ArithmeticException`, but `ParseException` if
>> parsing is failing. I would expect the same here.
>
> Sorry, I'm not seeing where the original could throw ParseExce
On Tue, 10 Jun 2025 02:38:29 GMT, Fei Yang wrote:
> FYI: I submitted to testing in QEMU-system / Ubuntu 25.04 (fastdebug jdk
> build and 256-bit RVV) and I see `compiler/vectorization`,
> `compiler/vectorapi` and `jdk_vector` tests are passing.
Thank you very much!
-
PR Comment:
On Mon, 9 Jun 2025 22:08:08 GMT, Naoto Sato wrote:
>> Sorry, I'm not seeing where the original could throw ParseException.
>
> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw
> NumberFormatException/ArithmeticException, but ParseException, so if this
> piece of cod
> 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
On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato wrote:
>> The parallel loading of JavaTimeSupplementary was a historical artifact from
>> the introduction of JSR 310, which additionally loads resouces that had not
>> existed before. Since the COMPAT locale provider which relied on this
>> mechanis
On Mon, 9 Jun 2025 21:03:27 GMT, Brian Burkhalter wrote:
> Relax testing the inequality `usable_space <= free_space` to testing the
> inequality `usable_space <= total_space`.
Although the native system call `statfs` (Unix) and native function
`GetDiskFreeSpaceExW` (Windows) might collect the
On Thu, 5 Jun 2025 00:10:57 GMT, Chen Liang wrote:
>> This one is a little odd. The parse methods that call `getLong` are not
>> supposed to throw `NumberFormatException` either. So wherever `getLong` is
>> called, it must be preceded by a check to `fitsIntoLong`, which should avoid
>> any exc
On Mon, 9 Jun 2025 22:46:50 GMT, Johannes Graham wrote:
>> 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.parseUnsigned
On Mon, 9 Jun 2025 22:57:24 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed the bundle
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 214:
>
>> 212: in
On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato wrote:
>> The parallel loading of JavaTimeSupplementary was a historical artifact from
>> the introduction of JSR 310, which additionally loads resouces that had not
>> existed before. Since the COMPAT locale provider which relied on this
>> mechanis
> 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 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 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
The parallel loading of JavaTimeSupplementary was a historical artifact from
the introduction of JSR 310, which additionally loads resouces that had not
existed before. Since the COMPAT locale provider which relied on this mechanism
has been removed, and the CLDR resource bundles now include tho
On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato wrote:
>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource
>> files in `java.base` are supposed to be US English only, but they also need
>> to use UTF-8 as some of the names are non-ASCII (e.g., Türkiye)
>
> Naoto Sato has up
On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato wrote:
> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource
> files in `java.base` are supposed to be US English only, but they also need
> to use UTF-8 as some of the names are non-ASCII (e.g., Türkiye)
This pull request has n
> The parallel loading of JavaTimeSupplementary was a historical artifact from
> the introduction of JSR 310, which additionally loads resouces that had not
> existed before. Since the COMPAT locale provider which relied on this
> mechanism has been removed, and the CLDR resource bundles now inc
> 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
On Mon, 9 Jun 2025 13:41:10 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
>>
> 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
On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote:
> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after
> JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used
> jdk.internal.ac
On Mon, 9 Jun 2025 15:52:24 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
>>
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
Please review this PR which finishes Applet removal for the test:
jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
`testclasses.jar` is updated such that the two classes no longer extend Applet.
$ javap fo\ o.class
public class fo o {
}
$ javap æ$'\302\211'$'\302\213'å$'\302\206'$'\302
On Sat, 7 Jun 2025 17:36:40 GMT, Johannes Graham wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review - Moving all ISO resources to LocaleISOData & blessed modifier
>> order for languageTag
>
> src/java.base/share/
On Thu, 8 May 2025 14:27:07 GMT, kabutz wrote:
>> 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?
On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham wrote:
> 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`
>
On Wed, 4 Jun 2025 23:15:37 GMT, Chen Liang wrote:
>> 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`
On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham wrote:
> 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`
>
On Wed, 4 Jun 2025 23:59:38 GMT, Johannes Graham wrote:
>> src/java.base/share/classes/java/text/DigitList.java line 198:
>>
>>> 196: }
>>> 197: long pow10 = Math.powExact(10L, Math.max(0, decimalAt -
>>> count));
>>> 198: return Math.multiplyExact(v, pow10);
>>
>> Thes
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 cached St
> 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
On Mon, 9 Jun 2025 13:41:10 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
>>
On Mon, 9 Jun 2025 13:11:34 GMT, Viktor Klang wrote:
>> What would you like to do if the invariant fails inside linkFirst() and
>> linkLast()? Should we throw an AssertionError each time?
>
> No, I was more thinking keeping it as it was: (return true/false from
> linkFirst / linkLast depending
On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg wrote:
> This PR proposes to simplify lazy computation related to resource bundles.
> Previously, some objects were computed lazily using a double-checked locking
> algorithm. StableValues offers a more robust and succinct solution.
>
>
> This P
On Tue, 13 May 2025 13:16:45 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 e
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 incr
On Mon, 9 Jun 2025 09:24:57 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
On Thu, 8 May 2025 13:53:31 GMT, kabutz wrote:
>> 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 co
On Mon, 9 Jun 2025 09:20:31 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 bas
Hi Jige,
Yes, let's see what developers need. 👍
In the meantime, I want to reiterate that it is possible to build what you're
asking for, outside of the JDK. To gather experience, feedback, and ultimately
decide if the feature is worthwhile.
Cheers,
√
Viktor Klang
Software Architect, Java Pl
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
On Mon, 9 Jun 2025 11:58:03 GMT, kabutz wrote:
>> @kabutz I'd think maintaining the invariants within linkFirst and linkLast
>> would be preferable (`count` must be re-read under the lock anyway)
>
> What would you like to do if the invariant fails inside linkFirst() and
> linkLast()? Should we
> 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
On Tue, 27 May 2025 16:31:47 GMT, Justin Lu wrote:
>> @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.
I have now reverted the c
> 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
On Tue, 27 May 2025 17:01:13 GMT, Naoto Sato 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 st
56 matches
Mail list logo
