Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]

2024-02-26 Thread Julian Waters
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >

Re: RFR: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c

2024-02-26 Thread Daniel Jeliński
On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote: > Please help review this trivial change. This was branched from > https://github.com/openjdk/jdk/pull/18013, based on discussion with > @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks LGTM - Marked as

Re: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]

2024-02-26 Thread Jatin Bhateja
On Wed, 21 Feb 2024 15:51:21 GMT, Scott Gibbons wrote: >> Hi @asgibbons , >> >> I am getting following error with slowdebug build on Meteor Lake system. >> >> >> ERROR: Build failed for target 'images' in configuration >> 'linux-x86_64-server-slowdebug' (exit code 2) >> >> === Output from f

Re: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v7]

2024-02-26 Thread Joe Darcy
> 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 > > details the inputs with generate the worst-case observed

Re: RFR: 8325485: IncrementInstructions.of(int, int) is not storing the args [v2]

2024-02-26 Thread Chen Liang
On Fri, 9 Feb 2024 10:47:08 GMT, Adam Sotona wrote: >> ClassFile API provides two sets of instructions implementations (bound and >> unbound). >> Unbound implementation of `IncrementInstruction::constant` returns invalid >> value. >> This bug discovered a hole in the ClassFile API test coverag

Re: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v6]

2024-02-26 Thread Joe Darcy
> 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 > > details the inputs with generate the worst-case observed

Re: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v5]

2024-02-26 Thread Joe Darcy
> 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 > > details the inputs with generate the worst-case observed

RFR: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c

2024-02-26 Thread Jiangli Zhou
Please help review this trivial change. This was branched from https://github.com/openjdk/jdk/pull/18013, based on discussion with @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks - Commit messages: - 8326714: Make file-local functions static in src/java.ba

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v15]

2024-02-26 Thread Jatin Bhateja
On Mon, 26 Feb 2024 13:47:35 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments resolutions > > Reposting link to a conversation that is marked "resolved": > https://github.com/open

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Jatin Bhateja
On Mon, 26 Feb 2024 15:05:24 GMT, Emanuel Peter wrote: >> I was referring to the various arrays as well above. I think it would be >> exactly more concise if you defined a local label in the loop body. > > Have you had a look at `C2_MacroAssembler::rtm_counters_update`? Correct, with each succe

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v16]

2024-02-26 Thread Jatin Bhateja
> 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 > partially unrolls scalar loop to accumulates values from gather ind

Integrated: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c

2024-02-26 Thread Jiangli Zhou
On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote: > Please help review this trivial fix for resolving `ld: error: duplicate > symbol: closeDescriptors` when static linking with both libjdwp and libjava, > thanks. This pull request has now been integrated. Changeset: 0901dede Author:Ji

Re: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2]

2024-02-26 Thread Jiangli Zhou
On Tue, 27 Feb 2024 00:34:49 GMT, Serguei Spitsyn wrote: >> Jiangli Zhou has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address plummercj's comment and make forkedChildProcess static. >> - Revert src/java.base/unix/native/libjava/chi

Re: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2]

2024-02-26 Thread Serguei Spitsyn
On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate >> symbol: closeDescriptors` when static linking with both libjdwp and libjava, >> thanks. > > Jiangli Zhou has updated the pull request incrementally with two additi

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]

2024-02-26 Thread Naoto Sato
On Mon, 26 Feb 2024 22:38:50 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java >> >> Co-authored-by: Andrey Turbanov > > tes

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5]

2024-02-26 Thread Naoto Sato
On Mon, 26 Feb 2024 22:11:31 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing review comments > > src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java > li

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5]

2024-02-26 Thread Naoto Sato
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The > `COMPAT` locale data was introduced for applications' migratory purposes > transitioning to `CLDR`. It is becoming a technical debt and now is the time > to remove it (we've been emitting a warning at JVM startup sin

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v4]

2024-02-26 Thread Naoto Sato
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The > `COMPAT` locale data was introduced for applications' migratory purposes > transitioning to `CLDR`. It is becoming a technical debt and now is the time > to remove it (we've been emitting a warning at JVM startup sin

Re: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2]

2024-02-26 Thread Jiangli Zhou
On Mon, 26 Feb 2024 23:50:11 GMT, Chris Plummer wrote: > Looks good. Thanks for the quick review, @plummercj. - PR Comment: https://git.openjdk.org/jdk/pull/18013#issuecomment-1965539618

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v3]

2024-02-26 Thread Justin Lu
On Mon, 26 Feb 2024 23:37:16 GMT, Naoto Sato wrote: >> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The >> `COMPAT` locale data was introduced for applications' migratory purposes >> transitioning to `CLDR`. It is becoming a technical debt and now is the time >> to r

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]

2024-02-26 Thread Justin Lu
On Mon, 26 Feb 2024 21:32:22 GMT, Naoto Sato wrote: >> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The >> `COMPAT` locale data was introduced for applications' migratory purposes >> transitioning to `CLDR`. It is becoming a technical debt and now is the time >> to r

Re: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2]

2024-02-26 Thread Chris Plummer
On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate >> symbol: closeDescriptors` when static linking with both libjdwp and libjava, >> thanks. > > Jiangli Zhou has updated the pull request incrementally with two additi

Integrated: JDK-8325898: ChoiceFormat returns erroneous result when formatting bad pattern

2024-02-26 Thread Justin Lu
On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu wrote: > Please review this PR which handles an edge case pattern bug with > ChoiceFormat. > > > var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to > "0.0#foo|1.0#bar|1.0#" > d.format(1) // unexpectedly returns "" > > > Not

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v3]

2024-02-26 Thread Naoto Sato
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The > `COMPAT` locale data was introduced for applications' migratory purposes > transitioning to `CLDR`. It is becoming a technical debt and now is the time > to remove it (we've been emitting a warning at JVM startup sin

Re: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2]

2024-02-26 Thread Jiangli Zhou
On Mon, 26 Feb 2024 20:37:45 GMT, Chris Plummer wrote: >> Jiangli Zhou has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address plummercj's comment and make forkedChildProcess static. >> - Revert src/java.base/unix/native/libjava/child

Re: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function [v2]

2024-02-26 Thread Jiangli Zhou
> Please help review this trivial fix for resolving `ld: error: duplicate > symbol: closeDescriptors` when static linking with both libjdwp and libjava, > thanks. Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: - Address plummercj's

Re: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2]

2024-02-26 Thread Jiangli Zhou
On Mon, 26 Feb 2024 22:15:00 GMT, Jiangli Zhou wrote: >> src/java.base/unix/native/libjava/childproc.h line 134: >> >>> 132: int closeSafely(int fd); >>> 133: int isAsciiDigit(char c); >>> 134: int closeDescriptors(void); >> >> It seems that most of the APIs in this file should be static. I don

Re: RFR: JDK-8325898: ChoiceFormat returns erroneous result when formatting bad pattern [v6]

2024-02-26 Thread Justin Lu
> Please review this PR which handles an edge case pattern bug with > ChoiceFormat. > > > var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to > "0.0#foo|1.0#bar|1.0#" > d.format(1) // unexpectedly returns "" > > > Not only does this lead to faulty formatting results, bu

Re: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function

2024-02-26 Thread Jiangli Zhou
On Mon, 26 Feb 2024 20:40:52 GMT, Chris Plummer wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate >> symbol: closeDescriptors` when static linking with both libjdwp and libjava, >> thanks. > > src/java.base/unix/native/libjava/childproc.h line 134: > >> 132: int

Integrated: 8325506: Ensure randomness is only read from provided SecureRandom object

2024-02-26 Thread Weijun Wang
On Thu, 8 Feb 2024 16:34:00 GMT, Weijun Wang wrote: > Many crypto service classes require a `SecureRandom` object at > initialization. This test goes through each of them and calculates (generate, > encrypt, sign,...) twice with the same `SecureRandom` object and ensures the > output is the sa

Re: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object [v4]

2024-02-26 Thread Valerie Peng
On Sat, 17 Feb 2024 14:08:12 GMT, Weijun Wang wrote: >> Many crypto service classes require a `SecureRandom` object at >> initialization. This test goes through each of them and calculates >> (generate, encrypt, sign,...) twice with the same `SecureRandom` object and >> ensures the output is t

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

2024-02-26 Thread Maurizio Cimadamore
On Mon, 26 Feb 2024 19:19:56 GMT, Jorn Vernee wrote: >> Found the right one: >> https://github.com/openjdk/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb > > Switched back to using the old generator (and removed the newer one): > https://github.com/openjdk/jdk/pull/18007/commits/fad15a66b6

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v3]

2024-02-26 Thread Maurizio Cimadamore
On Mon, 26 Feb 2024 19:17:56 GMT, Jorn Vernee wrote: >> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, >> regardless of the underlying platform. This means that atomic access modes >> work on memory segments wrapping `long[]` or `double[]`, as they already do >> when

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]

2024-02-26 Thread Naoto Sato
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The > `COMPAT` locale data was introduced for applications' migratory purposes > transitioning to `CLDR`. It is becoming a technical debt and now is the time > to remove it (we've been emitting a warning at JVM startup sin

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]

2024-02-26 Thread Naoto Sato
On Mon, 26 Feb 2024 16:39:29 GMT, Magnus Ihse Bursie wrote: >> Actually, as the file currently in the PR, it does not seem like it does >> anything at all, since we no longer create `_the.locale_resources`. Or... >> hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I >> wond

Re: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4]

2024-02-26 Thread Eirik Bjørsnøs
On Mon, 26 Feb 2024 19:54:11 GMT, Alan Bateman wrote: > > I'm wondering if the somewhat tedious "number of compressed bytes input so > > far" could be further simplified. Besides being a long repetition from the > > leading sentence, when used in this sentence, we actually mean to refer to > >

Re: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v8]

2024-02-26 Thread Eirik Bjørsnøs
On Mon, 26 Feb 2024 19:35:26 GMT, Lance Andersen wrote: > This sentence to me seems a bit hard to digest and you basically get the > point across in the `@deprecated` message This new text was added after a discussion with Alan (see above) concluded that the method should specify its behavior

Re: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v9]

2024-02-26 Thread Eirik Bjørsnøs
> Please review this PR which proposes that we officially deprecate the > following four methods in the `java.util.zip` package: > > * `Inflater.getTotalIn()` > * `Inflater.getTotalOut()` > * `Deflater.getTotalIn()` > * `Deflater.getTotalOut()` > > Since these legacy methods return `int`, they c

Re: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function

2024-02-26 Thread Chris Plummer
On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote: > Please help review this trivial fix for resolving `ld: error: duplicate > symbol: closeDescriptors` when static linking with both libjdwp and libjava, > thanks. src/java.base/unix/native/libjava/childproc.h line 134: > 132: int closeSafe

RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function

2024-02-26 Thread Jiangli Zhou
Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. - Commit messages: - Make closeDescriptors() as static function in src/java.base/unix/native/libjava/childproc.c and src/jdk

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]

2024-02-26 Thread Magnus Ihse Bursie
> The idea of setting up general "toolchains" in the native build was good, but > it turned out that we really only need a single toolchain, with a single > twist: if it should use CC or CPP to link. This is better described by a > specific argument to SetupNativeCompilation, LANG := C++ or LANG

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution

2024-02-26 Thread Magnus Ihse Bursie
On Sat, 24 Feb 2024 06:04:40 GMT, Julian Waters wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >> spe

RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc

2024-02-26 Thread Lance Andersen
This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.T

Re: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4]

2024-02-26 Thread Alan Bateman
On Mon, 26 Feb 2024 15:04:01 GMT, Eirik Bjørsnøs wrote: > I'm wondering if the somewhat tedious "number of compressed bytes input so > far" could be further simplified. Besides being a long repetition from the > leading sentence, when used in this sentence, we actually mean to refer to > the "

Re: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v8]

2024-02-26 Thread Lance Andersen
On Mon, 26 Feb 2024 14:29:19 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which proposes that we officially deprecate the >> following four methods in the `java.util.zip` package: >> >> * `Inflater.getTotalIn()` >> * `Inflater.getTotalOut()` >> * `Deflater.getTotalIn()` >> * `Deflater.ge

Re: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer [v4]

2024-02-26 Thread Daniel Fuchs
On Mon, 15 Jan 2024 08:36:43 GMT, Stefan Karlsson wrote: >> Tests using ProcessTools.executeProcess gets the following output written to >> stdout: >> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 >> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

2024-02-26 Thread Jorn Vernee
On Mon, 26 Feb 2024 19:13:41 GMT, Jorn Vernee wrote: >> That doesn't seem to be the right PR link? > > Found the right one: > https://github.com/openjdk/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb Switched back to using the old generator (and removed the newer one): https://github.com/

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

2024-02-26 Thread Jorn Vernee
On Mon, 26 Feb 2024 19:10:39 GMT, Jorn Vernee wrote: >> test/jdk/java/foreign/TestLayouts.java line 164: >> >>> 162: ); >>> 163: assertEquals(struct.byteSize(), 1 + 1 + 2 + 4 + 8); >>> 164: assertEquals(struct.byteAlignment(), 8); >> >> Looking at this PR: >> https://git

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v3]

2024-02-26 Thread Jorn Vernee
> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, > regardless of the underlying platform. This means that atomic access modes > work on memory segments wrapping `long[]` or `double[]`, as they already do > when using `MethodHandless::arrayAccessVarHandle`. > > After di

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

2024-02-26 Thread Jorn Vernee
On Mon, 26 Feb 2024 16:21:38 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> review comments > > test/jdk/java/foreign/TestLayouts.java line 164: > >> 162: ); >> 163: asser

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v12]

2024-02-26 Thread Severin Gehwolf
On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 46 commits: >> >> - Add @enablePreview for JImageValidator that uses classfile API >> - Fix SystemModulesPlu

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v17]

2024-02-26 Thread Severin Gehwolf
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jm

Re: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v4]

2024-02-26 Thread Chen Liang
> API changes as discussed on the mailing list: > https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html > > Additional questions: > 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE` Chen Liang has updated the pull request with a new target base due to a merge o

Re: RFR: 8310994: Add JFR event for selection operations [v3]

2024-02-26 Thread Alan Bateman
On Mon, 26 Feb 2024 14:14:21 GMT, Daniel Fuchs wrote: > Maybe that's OK - and maybe in that case the onus is on the user to set a > threshold greater than 1500ms? The threshold is 20ms so these timed-select ops in the HTTP client will record an event when they timeout. - PR Revie

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v16]

2024-02-26 Thread Severin Gehwolf
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jm

Re: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v3]

2024-02-26 Thread Alan Bateman
On Mon, 26 Feb 2024 06:00:13 GMT, Jaikiran Pai wrote: >>> (In passing, the casing of "zip file" is very inconsistent in the javadoc, >>> it's "ZIP file" in some places, "zip file" in others, the change here uses >>> "Zip file"). >> >> Thank you for pointing out the discrepancy above. >> >> Le

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK

2024-02-26 Thread Magnus Ihse Bursie
On Mon, 26 Feb 2024 16:33:02 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58: >> >>> 56: ifeq ($(MODULE), jdk.localedata) >>> 57: $(shell $(RM) >>> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaIn

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK

2024-02-26 Thread Magnus Ihse Bursie
On Mon, 26 Feb 2024 14:20:40 GMT, Erik Joelsson wrote: >> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The >> `COMPAT` locale data was introduced for applications' migratory purposes >> transitioning to `CLDR`. It is becoming a technical debt and now is the time >> t

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

2024-02-26 Thread Maurizio Cimadamore
On Mon, 26 Feb 2024 16:05:51 GMT, Jorn Vernee wrote: >> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, >> regardless of the underlying platform. This means that atomic access modes >> work on memory segments wrapping `long[]` or `double[]`, as they already do >> when

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v8]

2024-02-26 Thread Claes Redestad
> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via > Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Stray space - Changes: - all: https://gi

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7]

2024-02-26 Thread Claes Redestad
On Mon, 26 Feb 2024 15:50:55 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java >> >>Co-authored-by: Raffaello Giuliett

Integrated: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-26 Thread Claes Redestad
On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via > Data- and ObjectInputStream > > Testing: tier1-3 This pull request has now been integrated. Changeset: 9a9cfbe0 Author:Claes Redestad URL: https://gi

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

2024-02-26 Thread Jorn Vernee
On Mon, 26 Feb 2024 15:10:55 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> review comments > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 328: > >> 326: *

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

2024-02-26 Thread Jorn Vernee
> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, > regardless of the underlying platform. This means that atomic access modes > work on memory segments wrapping `long[]` or `double[]`, as they already do > when using `MethodHandless::arrayAccessVarHandle`. > > After di

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v2]

2024-02-26 Thread Magnus Ihse Bursie
> The idea of setting up general "toolchains" in the native build was good, but > it turned out that we really only need a single toolchain, with a single > twist: if it should use CC or CPP to link. This is better described by a > specific argument to SetupNativeCompilation, LANG := C++ or LANG

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7]

2024-02-26 Thread Roger Riggs
On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via >> Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional > commits since the last r

Integrated: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment

2024-02-26 Thread Lance Andersen
On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen wrote: > Please review this PR which addresses the handling of invalid UTF-8 byte > sequences in the entry name of a LOC file header and a Zip file comment which > is returned via ZipFile::getComment. > > As part of the change, `ZipFile::getComm

Integrated: 8326653: Remove jdk.internal.reflect.UTF8

2024-02-26 Thread Claes Redestad
On Mon, 26 Feb 2024 11:05:10 GMT, Claes Redestad wrote: > jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when > generating some classes. > > Since JDK 9 we have a fast-path (which avoids creating encoders) for > UTF-8-encoding strings which is bootstrapped very early,

Re: RFR: 8319648: java/lang/SecurityManager tests ignore vm flags

2024-02-26 Thread Sean Mullan
On Thu, 15 Feb 2024 17:06:25 GMT, Matthew Donovan wrote: > In this PR I updated the tests to use the newer > ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child > processes. test/jdk/java/lang/System/SecurityManagerWarnings.java line 135: > 133: if (prop == n

Re: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2]

2024-02-26 Thread Viktor Klang
On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when >> generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for >> UTF-8-encoding strings which is bootstrapped very ea

Re: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2]

2024-02-26 Thread Claes Redestad
On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when >> generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for >> UTF-8-encoding strings which is bootstrapped very ea

Re: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc

2024-02-26 Thread Maurizio Cimadamore
On Mon, 26 Feb 2024 13:24:11 GMT, Jorn Vernee wrote: > This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, > regardless of the underlying platform. This means that atomic access modes > work on memory segments wrapping `long[]` or `double[]`, as they already do > when usin

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6]

2024-02-26 Thread Archie Cobbs
On Mon, 26 Feb 2024 06:51:12 GMT, Jaikiran Pai wrote: >> Archie Cobbs 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

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Emanuel Peter
On Mon, 26 Feb 2024 15:05:03 GMT, Emanuel Peter wrote: >> Hi @eme64 , I was referring to allocation of label's array. To be concise >> and avoid hand unrolling of loop, I chose an array of labels. > > I was referring to the various arrays as well above. I think it would be > exactly more conci

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Emanuel Peter
On Mon, 26 Feb 2024 14:58:53 GMT, Jatin Bhateja wrote: >> I could not find any other case with the same pattern, of initializing a >> list of Labels. >> >> On the other hand, I can find cases where we already do what I am saying: >> `C2_MacroAssembler::rtm_counters_update` > > Hi @eme64 , I was

Re: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4]

2024-02-26 Thread Eirik Bjørsnøs
On Sun, 25 Feb 2024 15:19:59 GMT, Alan Bateman wrote: > For the class description then it might be simpler to reduce the new text > down to one sentence, e.g. @AlanBateman Thanks for the condensed text, that's indeed much better! I've pushed your suggestion, only adding a link around Integer.

Re: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2]

2024-02-26 Thread Claes Redestad
On Mon, 26 Feb 2024 14:47:06 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove temporary microbenchmark > > src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line > 2

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Jatin Bhateja
On Mon, 26 Feb 2024 13:31:05 GMT, Emanuel Peter wrote: >> At the risk of becoming too nit-picky: which allocations are you talking >> about? Given you only have a single src and a single dst for this >> label/jump. So you won't use `_patch_overflow`. And therefore, all >> allocations are on th

Re: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v13]

2024-02-26 Thread Jatin Bhateja
On Thu, 22 Feb 2024 03:15:10 GMT, Scott Gibbons wrote: >> Re-write the IndexOf code without the use of the pcmpestri instruction, only >> using AVX2 instructions. This change accelerates String.IndexOf on average >> 1.3x for AVX2. The benchmark numbers: >> >> >> Benchmark

Re: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2]

2024-02-26 Thread Alan Bateman
On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when >> generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for >> UTF-8-encoding strings which is bootstrapped very ea

Re: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2]

2024-02-26 Thread Roger Riggs
On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when >> generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for >> UTF-8-encoding strings which is bootstrapped very ea

Re: RFR: 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes survive minor garbage collections

2024-02-26 Thread Doug Lea
On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang wrote: > More aggressively breaking chains in order to prevent nodes promoted to older > generations standing in the way for collecting younger nodes. I decided that > it was most efficient to add this logic to the else-branch of updating the > fi

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK

2024-02-26 Thread Erik Joelsson
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote: > This PR intends to remove the legacy `COMPAT` locale data from the JDK. The > `COMPAT` locale data was introduced for applications' migratory purposes > transitioning to `CLDR`. It is becoming a technical debt and now is the time > to remov

Re: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v8]

2024-02-26 Thread Eirik Bjørsnøs
> Please review this PR which proposes that we officially deprecate the > following four methods in the `java.util.zip` package: > > * `Inflater.getTotalIn()` > * `Inflater.getTotalOut()` > * `Deflater.getTotalIn()` > * `Deflater.getTotalOut()` > > Since these legacy methods return `int`, they c

Re: RFR: 8310994: Add JFR event for selection operations [v3]

2024-02-26 Thread Daniel Fuchs
On Wed, 3 Jan 2024 11:11:40 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add select timeout field to the event > > src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 153: > >> 151:

RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc

2024-02-26 Thread Jorn Vernee
This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`. After discussion, we

Re: RFR: 8310994: Add JFR event for selection operations [v2]

2024-02-26 Thread Daniel Fuchs
On Wed, 13 Dec 2023 18:49:08 GMT, Daniel Fuchs wrote: >> Tim Prinzing 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 s

Re: RFR: 8310994: Add JFR event for selection operations [v2]

2024-02-26 Thread Daniel Fuchs
On Wed, 13 Dec 2023 18:58:40 GMT, Tim Prinzing wrote: >> src/java.base/share/classes/jdk/internal/event/SelectorSelectEvent.java line >> 41: >> >>> 39: public class SelectorSelectEvent extends Event { >>> 40: >>> 41: public int selectionKeyCount; >> >> I still believe we should record the

Integrated: 8326099: GZIPOutputStream should use Deflater.getBytesRead() instead of Deflater.getTotalIn()

2024-02-26 Thread Eirik Bjørsnøs
On Sat, 17 Feb 2024 12:08:38 GMT, Eirik Bjørsnøs wrote: > Please review this cleanup PR in preparation for deprecating > `Deflater.getTotalIn()` in JDK-8326096. > > This PR replaces `GZIPOutputStream.writeTrailer`'s call to > `Deflater.getTotalIn()` with a call to `Deflater.getBytesRead()` fo

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v15]

2024-02-26 Thread Emanuel Peter
On Mon, 26 Feb 2024 13:14:24 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 >> p

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Emanuel Peter
On Mon, 26 Feb 2024 13:24:05 GMT, Emanuel Peter wrote: >> To avoid invariant initializations to happen within the loop, compiler will >> unroll this small loop and will forward the initializations, if it does not >> then we can save redundant allocation within loop. > > At the risk of becoming

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Emanuel Peter
On Mon, 26 Feb 2024 13:09:22 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584: >> >>> 1582: if (elem_bt == T_SHORT) { >>> 1583: Label case0, case1, case2, case3; >>> 1584: Label* larr[] = {&case0, &case1, &case2, &case3}; >> >> Not sure if I asked t

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Emanuel Peter
On Mon, 26 Feb 2024 13:06:19 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template >> line 4840: >> >>> 4838: >>> 4839: // Check indices are within array bounds. >>> 4840: // FIXME: Check index under mask controlling. >>

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v13]

2024-02-26 Thread Jatin Bhateja
On Mon, 26 Feb 2024 09:36:09 GMT, Emanuel Peter wrote: >> 64 bit sub-word SPECIES will either hold 8 bytes values or 4 short values, >> algorithm appropriately handle it. > > Are you saying that the constraints are too relaxed, but currently no outside > algorithm would pass something bad? > Bu

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v13]

2024-02-26 Thread Jatin Bhateja
On Mon, 26 Feb 2024 09:37:33 GMT, Emanuel Peter wrote: >> I'll rereview after > > So xtmp1...3 and rtmp cannot have more descriptive names? These are temporary variable and appropriately named. - PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502587427

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Jatin Bhateja
On Mon, 26 Feb 2024 09:39:01 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments resolutions. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584: > >> 1582: if (elem_bt =

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v15]

2024-02-26 Thread Jatin Bhateja
> 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 > partially unrolls scalar loop to accumulates values from gather ind

Re: RFR: 8318650: Optimized subword gather for x86 targets. [v14]

2024-02-26 Thread Jatin Bhateja
On Mon, 26 Feb 2024 09:47:50 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments resolutions. > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template >

Re: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2]

2024-02-26 Thread Claes Redestad
> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when > generating some classes. > > Since JDK 9 we have a fast-path (which avoids creating encoders) for > UTF-8-encoding strings which is bootstrapped very early, so it seems safe to > rewire this and remove the UTF8 hel

RFR: 8326653: Remove jdk.internal.reflect.UTF8

2024-02-26 Thread Claes Redestad
jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class wh

  1   2   >