On Mon, 31 Jul 2023 13:34:30 GMT, Jim Laskey wrote:
>> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent
>> caching scheme for Carrier objects. The technique used is generally useful
>> for a variety of caching schemes and is being moved to be shared in other
>> parts o
On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote:
> In its initial form, the changes are tested on Linux. Later on, I'll do
> cross-platform builds to make sure there aren't any, say, windows-specific
> changes that are needed as well.
>
PS Builds pass on all platforms (linux, mac, and window
On Fri, 2 Feb 2024 16:40:45 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/lang/String.java line 2506:
>>
>>> 2504: fromIndex = Math.max(0, fromIndex);
>>> 2505: return isLatin1() ? StringLatin1.indexOf(value, ch,
>>> fromIndex, value.length)
>>> 2506:
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
After the "this-escape" lint warning was added to javac (JDK-8015831), the base
module was not updated to be able to compile with this warning enabled. This PR
makes the necessary changes to allow the base module to build with the warning
enabled.
-
Commit messages:
- JDK-8325189:
On Fri, 2 Feb 2024 22:43:28 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to p
On Thu, 1 Feb 2024 16:24:16 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch optimizes sub-word gather operation for x86 targets with AVX2 and
>> AVX512 features.
>>
>> Following is the summary of changes:-
>>
>> 1) Intrinsify sub-word gather using hybrid algorithm which initially
>> pa
On Fri, 2 Feb 2024 22:46:34 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reworded spec
>
> src/java.base/share/classes/java/text/DateFormat.java line 751:
>
>> 749: * @implSpec A {@link Charac
> Implementing "loose matching" of space separators in both
> `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
> parsing. This will effectively fix the NNBSP issues on parsing time with
> am/pm markers introduced with CLDR version 42
> (https://inside.java/2023/03/28/q
On Fri, 2 Feb 2024 21:08:33 GMT, Joe Wang wrote:
> You are right, Joe. Apps using `java.time` formatters would still need to
> make changes to their code base. However, the bar is significantly lower.
> They would have to write some ugly workaround without this fix.
I'd also expect that applic
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Fri, 2 Feb 2024 20:47:29 GMT, Naoto Sato wrote:
>> Implementing "loose matching" of space separators in both
>> `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
>> parsing. This will effectively fix the NNBSP issues on parsing time with
>> am/pm markers introduced
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to provide pattern support for the more recently added JDK F
On Fri, 2 Feb 2024 22:35:17 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect Naoto's comments
>
> src/java.base/share/classes/java/text/MessageFormat.java line 377:
>
>> 375: * Calendar cal =
On Fri, 2 Feb 2024 22:16:30 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
>> which adds MessageFormat pattern support for the following subformats:
>> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
>> intended to p
On Fri, 2 Feb 2024 22:11:17 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/text/MessageFormat.java line 676:
>>
>>> 674: * java.time.format.DateTimeFormatter}. In addition, {@code
>>> DateTimeFormatter}
>>> 675: * does not implement {@code equals()}, and thus cannot be
>>>
On Fri, 2 Feb 2024 22:13:39 GMT, Justin Lu wrote:
> > Slightly tangential question (since you're talking about adding new
> > subformats)...
> > Has it ever been considered to add `MessageFormat` itself as a subformat
> > option?
> > It's not as crazy an idea as it sounds :) Here's an example:
On Thu, 1 Feb 2024 19:50:30 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect Naoto's comments
>
> src/java.base/share/classes/java/text/MessageFormat.java line 370:
>
>> 368: *
>> 369: * Mess
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to provide pattern support for the more recently added JDK F
On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to prov
On Fri, 2 Feb 2024 20:53:14 GMT, Claes Redestad wrote:
>> This patch streamlines and specializes various `String::indexOf` methods.
>> Mainly avoids the need for clamping and doing checks that are redundant in
>> almost all cases, moving the checks to the API boundary where they are
>> needed.
On Fri, 2 Feb 2024 18:45:22 GMT, Vladimir Kozlov wrote:
> I don't see x86 changes. Why?
The 2-byte variants for `string_equals`, if they ever existed, seems to be gone:
// fast string equals
instruct string_equals(rdi_RegP str1, rsi_RegP str2, rcx_RegI cnt, rax_RegI
result,
On Wed, 24 Jan 2024 14:34:03 GMT, Eirik Bjørsnøs wrote:
> Please review this PR to fix to a regression in ZipFileSystem, introduced by
> JDK-8322565 in PR #17170.
>
> When `Files.setPosixFilePermissions` is called on an existing MSDOS entry,
> then `Entry.posixPerms` field will be -1 (all 1s i
On Fri, 2 Feb 2024 20:53:14 GMT, Claes Redestad wrote:
>> This patch streamlines and specializes various `String::indexOf` methods.
>> Mainly avoids the need for clamping and doing checks that are redundant in
>> almost all cases, moving the checks to the API boundary where they are
>> needed.
Also see https://github.com/openjdk/jdk/pull/15614, which removes caching
in `AbstractMap` etc, meaning once Valhalla is out, the anonymous set will
be a value object with no overhead. In addition, hotspot already has an
escape analysis mechanism which can optimize iterators to index for loops
if i
On Fri, 2 Feb 2024 21:20:29 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR to fix to a regression in ZipFileSystem, introduced by
>> JDK-8322565 in PR #17170.
>>
>> When `Files.setPosixFilePermissions` is called on an existing MSDOS entry,
>> then `Entry.posixPerms` field will be -1 (all
On Fri, 2 Feb 2024 21:17:48 GMT, Eirik Bjørsnøs wrote:
>> test/jdk/jdk/nio/zipfs/TestPosix.java line 757:
>>
>>> 755: try (FileSystem fs = FileSystems.newFileSystem(ZIP_FILE,
>>> ENV_POSIX)) {
>>> 756: Path path = fs.getPath("hello.txt");
>>> 757: Files.setPosixF
On Fri, 2 Feb 2024 20:01:06 GMT, Lance Andersen wrote:
> It might be helpful to show the before/after output of the CEN fields here
> just for extra clarity
Thanks! Can you take a look at 4bb77e1 which shows the `zipdetails` output for
relevant fields before/after calling `setPosixFilePermissi
> Please review this PR to fix to a regression in ZipFileSystem, introduced by
> JDK-8322565 in PR #17170.
>
> When `Files.setPosixFilePermissions` is called on an existing MSDOS entry,
> then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic
> introduced by JDK-8322565 did not
On Fri, 2 Feb 2024 20:59:13 GMT, Naoto Sato wrote:
> > Since the default parsing mode is strict in java.time.format, applications
> > would still have to make code changes when moving existing code to the new
> > JDK releases.
>
> You are right, Joe. Apps using `java.time` formatters would sti
On Fri, 2 Feb 2024 20:47:29 GMT, Naoto Sato wrote:
>> Implementing "loose matching" of space separators in both
>> `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
>> parsing. This will effectively fix the NNBSP issues on parsing time with
>> am/pm markers introduced
On Fri, 2 Feb 2024 19:31:55 GMT, Joe Wang wrote:
> Since the default parsing mode is strict in java.time.format, applications
> would still have to make code changes when moving existing code to the new
> JDK releases.
You are right, Joe. Apps using `java.time` formatters would still need to m
See: https://bugs.openjdk.org/browse/JDK-8193128
Jason
From: core-libs-dev on behalf of Ryan Ernst
Sent: Friday, February 2, 2024 1:42 PM
To: core-libs-dev@openjdk.org
Subject: Object creation from iterating Map.of()/Set.of()/List.of()
The newer “of” methods i
> This patch streamlines and specializes various `String::indexOf` methods.
> Mainly avoids the need for clamping and doing checks that are redundant in
> almost all cases, moving the checks to the API boundary where they are
> needed.
>
> This improves performance both at peak and during star
On Fri, 2 Feb 2024 20:19:51 GMT, Eirik Bjørsnøs wrote:
> > I think the change is OK, any reason to not make it
> > `externalFileAttributes`?
>
> None other than length / verbosity. But since this refers to the _attributes
> of the external file_, dropping any name element also loses some seman
> Implementing "loose matching" of space separators in both
> `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
> parsing. This will effectively fix the NNBSP issues on parsing time with
> am/pm markers introduced with CLDR version 42
> (https://inside.java/2023/03/28/q
On Fri, 2 Feb 2024 19:55:51 GMT, Lance Andersen wrote:
> I think the change is OK, any reason to not make it `externalFileAttributes`?
None other than length / verbosity. But since this refers to the _attributes
of the external file_, dropping any name element also loses some semantics,
intro
On Sun, 28 Jan 2024 22:23:38 GMT, Vladimir Yaroslavskiy
wrote:
>> Hi Vladimir (@iaroslavski),
>>
>> Please see the JMH data below.
>>
>> Thanks,
>> Vamsi
>>
>> Benchmark (builder) (size) Mode Cnt Score Error
>> Units
>> ArraysSort.Int.a15RANDOM 600
On Wed, 24 Jan 2024 10:28:46 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests we retire the ZIP test
>> `NoExtensionSignature` along with its `test.jar` test vector.
>>
>> The concern of a missing data descriptor signature is covered by the
>> recently updated `DataDescript
On Mon, 22 Jan 2024 13:58:00 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which makes `DeflaterOutputStream.close()` always
>> close its wrapped output stream exactly once.
>>
>> Currently, closing of the wrapped output stream happens outside the finally
>> block where `finish()` is c
On Wed, 24 Jan 2024 14:34:03 GMT, Eirik Bjørsnøs wrote:
> Please review this PR to fix to a regression in ZipFileSystem, introduced by
> JDK-8322565 in PR #17170.
>
> When `Files.setPosixFilePermissions` is called on an existing MSDOS entry,
> then `Entry.posixPerms` field will be -1 (all 1s i
On Tue, 30 Jan 2024 16:17:13 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
>> the
The newer “of” methods in collections are really nice, they make creating these
collections much easier and often result in better performance.
However, the empty collection cases with Map.of()/Set.of()/List.of() has one
small downside. The implementations within ImmutableCollections use
non-sp
On Thu, 1 Feb 2024 23:12:46 GMT, Naoto Sato wrote:
> Implementing "loose matching" of space separators in both
> `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient
> parsing. This will effectively fix the NNBSP issues on parsing time with
> am/pm markers introduced with
On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote:
> This patch streamlines and specializes various `String::indexOf` methods.
> Mainly avoids the need for clamping and doing checks that are redundant in
> almost all cases, moving the checks to the API boundary where they are
> needed.
>
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Fri, 2 Feb 2024 01:57:18 GMT, Archie Cobbs wrote:
>> Please consider this fix to ensure that going from `MessageFormat` to
>> pattern string via `toPattern()` and then back via `new MessageFormat()`
>> results in a format that is equivalent to the original.
>>
>> The quoting and escaping ru
On Fri, 2 Feb 2024 01:54:12 GMT, Archie Cobbs wrote:
>> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line
>> 70:
>>
>>> 68: @BeforeAll
>>> 69: public static void setup() {
>>> 70: savedLocale = Locale.getDefault();
>>
>> I'm not sure we need to save t
On Fri, 2 Feb 2024 01:57:18 GMT, Archie Cobbs wrote:
>> Please consider this fix to ensure that going from `MessageFormat` to
>> pattern string via `toPattern()` and then back via `new MessageFormat()`
>> results in a format that is equivalent to the original.
>>
>> The quoting and escaping ru
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the me
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
This pull request has now been integrated.
Changeset: adc36040
Author:Joe Darcy
URL:
https://git.open
> This change mirrors what we did for ConcurrentHashMap in
> https://github.com/openjdk/jdk/pull/17116. When we add all entries from one
> map to anther, we should resize that map to the size of the sum of both maps.
>
> I used the command below to run the benchmarks. I set a high heap to reduce
On Fri, 2 Feb 2024 14:53:51 GMT, Roger Riggs wrote:
> LGTM for the core-libs point of view. (And what I understand of the assembler)
Thanks!
I'll try to get someone from the compiler team to look over the assembler
change. @TobiHartmann, can you help get some eyes on this?
-
PR C
On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote:
> This patch streamlines and specializes various `String::indexOf` methods.
> Mainly avoids the need for clamping and doing checks that are redundant in
> almost all cases, moving the checks to the API boundary where they are
> needed.
>
On Sun, 28 Jan 2024 22:23:38 GMT, Vladimir Yaroslavskiy
wrote:
>> Hi Vladimir (@iaroslavski),
>>
>> Please see the JMH data below.
>>
>> Thanks,
>> Vamsi
>>
>> Benchmark (builder) (size) Mode Cnt Score Error
>> Units
>> ArraysSort.Int.a15RANDOM 600
On Mon, 29 Jan 2024 19:45:41 GMT, Paul Sandoz wrote:
> The implementation of method `VectorSpecies::fromMemorySegment`, in
> `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on
> the offset argument when the method is compiled by C2 (bounds checks are
> performed when in
> Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to
> account for the effect of the method on the file offset as returned by
> `getFilePointer`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8325152:
On Fri, 2 Feb 2024 16:20:21 GMT, ExE Boss wrote:
>> This patch streamlines and specializes various `String::indexOf` methods.
>> Mainly avoids the need for clamping and doing checks that are redundant in
>> almost all cases, moving the checks to the API boundary where they are
>> needed.
>>
On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote:
> This patch streamlines and specializes various `String::indexOf` methods.
> Mainly avoids the need for clamping and doing checks that are redundant in
> almost all cases, moving the checks to the API boundary where they are
> needed.
>
On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add kludge to BufferedRenderPipe.c for AIX
>
> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
>
>> 29:
>> 30: ifeq
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Fri, 2 Feb 2024 15:48:04 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365:
>>
>>> 363: #else
>>> 364: // Make sure we link to the 64-bit version of the functions
>>> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64
On Fri, 2 Feb 2024 07:02:43 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add kludge to BufferedRenderPipe.c for AIX
>
> src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94:
>
On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote:
>> The restricted javac warning is disabled for java.base, but could be enabled
>> by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
Inspired by (the later backed-out)
[JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable
`-Wpedantic` for clang. This has already found some irregularities in the code,
like mistakenly using `#import` instead of `#include`. In this patch, I disable
warnings for these i
On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote:
> This patch streamlines and specializes various `String::indexOf` methods.
> Mainly avoids the need for clamping and doing checks that are redundant in
> almost all cases, moving the checks to the API boundary where they are
> needed.
>
This patch streamlines and specializes various `String::indexOf` methods.
Mainly avoids the need for clamping and doing checks that are redundant in
almost all cases, moving the checks to the API boundary where they are needed.
This improves performance both at peak and during startup/warmup. S
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote:
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
> det
On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote:
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
> det
Hello Xiao,
I don't have enough knowledge of this area to provide any insight into
the issue. However, just to try and get the discussion started, do you
have any sample code of your application which shows how the application
uses the ForkJoinPool? More specifically what APIs do you use in th
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
76 matches
Mail list logo
