Re: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18 [v2]

2023-02-01 Thread Alan Bateman
On Wed, 25 Jan 2023 12:12:12 GMT, Ichiroh Takiguchi wrote: > We checked String.getByte()/new > String(...)/Reader/Writer/ByteArrayOutputStream.toString()... Is there good > way to pick up which parts need to be fixed ? I don't think there is so you may have to audit the classes that use

Re: RFR: 8301569: list mode of jmod and jimage cannot be used normally in turkish locale

2023-02-01 Thread Alan Bateman
On Wed, 1 Feb 2023 09:26:17 GMT, Glavo wrote: >> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1474: >> >>> 1472: String verb = words.get(0); >>> 1473: try { >>> 1474: options.mode = Enum.valueOf(Mode.class, >>>

Re: RFR: 8301367: Add exception handler method to the BaseLdapServer

2023-02-01 Thread Vyom Tewari
On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov wrote: > The proposed change adds a new exception handler method to the > `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. > It will allow LDAP tests to customize the handling of server-side exceptions. > > The

Re: RFR: 8301637: ThreadLocalRandom.current().doubles().parallel() contention

2023-02-01 Thread Alan Bateman
On Wed, 1 Feb 2023 15:51:33 GMT, kabutz wrote: > ThreadLocalRandom.current().doubles().parallel() had a bad regression, > because it called the superclass methods of the ThreadLocalRandomProxy's > nextDouble() method instead of delegating to the ThreadLocalRandom.current(). > > Affects all

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-01 Thread Jatin Bhateja
On Thu, 2 Feb 2023 03:42:34 GMT, Xiaohong Gong wrote: >> Your patch re-organized the code to take care of following cases :- >> 1. offset < 0 : Still falling over to old code. >> 2. offset >= limit : Special case optimized >> 3. (limit - offset) >=

RFR: 8301655: Problemlist jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java on Linux

2023-02-01 Thread Jaikiran Pai
Can I please get a review of this change which problem lists `TestLocOffsetFromZip64EF`? This test uses the `zip` command to generate a zip file. The `zip` binary shipped in recent versions of Linux (like Oracle Linux 9) are missing some features due to what appears to be a regression in that

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-01 Thread Xiaohong Gong
On Wed, 1 Feb 2023 14:20:05 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java >> line 236: >> >>> 234: } else if (offset >= limit) { >>> 235: return vectorSpecies().maskAll(false); >>> 236: } else if (limit -

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-01 Thread Xiaohong Gong
On Thu, 2 Feb 2023 01:59:09 GMT, Xiaohong Gong wrote: >> Your patch re-organized the code to take care of following cases :- >> 1. offset < 0 : Still falling over to old code. >> 2. offset >= limit : Special case optimized >> 3. (limit - offset) >=

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-01 Thread Xiaohong Gong
On Wed, 1 Feb 2023 14:20:05 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java >> line 236: >> >>> 234: } else if (offset >= limit) { >>> 235: return vectorSpecies().maskAll(false); >>> 236: } else if (limit -

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-01 Thread Xiaohong Gong
On Wed, 1 Feb 2023 13:22:07 GMT, Jatin Bhateja wrote: >> The Vector API `"indexInRange(int offset, int limit)"` is used >> to compute a vector mask whose lanes are set to true if the >> index of the lane is inside the range specified by the `"offset"` >> and `"limit"` arguments, otherwise the

Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]

2023-02-01 Thread Claes Redestad
On Wed, 1 Feb 2023 20:59:24 GMT, Scott Gibbons wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2202: >> >>> 2200: } >>> 2201: >>> 2202: address StubGenerator::base64_AVX2_decode_URL_tables_addr() { >> >> Shouldn't this be `decode_lut_tables`? As it's used for URL and non-URL >>

Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6]

2023-02-01 Thread Scott Gibbons
On Fri, 27 Jan 2023 21:45:37 GMT, Claes Redestad wrote: >> Scott Gibbons 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 13 additional >>

Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]

2023-02-01 Thread Scott Gibbons
On Wed, 1 Feb 2023 20:53:54 GMT, Claes Redestad wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Handle AVX2 URL; address review comments > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2202: > >> 2200: }

Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]

2023-02-01 Thread Claes Redestad
On Wed, 1 Feb 2023 18:28:25 GMT, Scott Gibbons wrote: >> Added code for Base64 acceleration (encode and decode) which will accelerate >> ~4x for AVX2 platforms. >> >> Encode performance: >> **Old:** >> >> Benchmark (maxNumBytes) Mode Cnt Score Error >> Units

Re: RFR: 8301637: ThreadLocalRandom.current().doubles().parallel() contention

2023-02-01 Thread Joe Darcy
On Wed, 1 Feb 2023 20:29:27 GMT, kabutz wrote: > Could this fix be back-ported to JDK 17? It's been an issue from then until > now. Assuming the fix goes into mainline, there are procedures for backporting to the update releases; e.g. https://wiki.openjdk.org/display/JDKUpdates/JDK+17u

Integrated: JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java from ProblemList-Xcomp.txt

2023-02-01 Thread Mandy Chung
On Wed, 1 Feb 2023 19:09:48 GMT, Mandy Chung wrote: > This test failure is no longer reproducible. It was added to the problem > list from JDK-8286368 as a clean up after JEP 425 Virtual Threads > integration. This PR removes it from the problem list. This pull request has now been

Re: RFR: 8301637: ThreadLocalRandom.current().doubles().parallel() contention

2023-02-01 Thread kabutz
On Wed, 1 Feb 2023 15:51:33 GMT, kabutz wrote: > ThreadLocalRandom.current().doubles().parallel() had a bad regression, > because it called the superclass methods of the ThreadLocalRandomProxy's > nextDouble() method instead of delegating to the ThreadLocalRandom.current(). > > Affects all

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v4]

2023-02-01 Thread cheenar
On Wed, 1 Feb 2023 20:16:56 GMT, cheenar wrote: >> Per Minborg has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Simplify benchmark >> - Add benchmark > > test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141: > >>

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v4]

2023-02-01 Thread cheenar
On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg wrote: >> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for >> values in the range [-18h, 18h] for each second that is on an even quarter >> of an hour (i.e. at most 2*18*4+1 = 145 values). >> >> Instead of using a

RFR: JDK-8301637: Fixed bug that regressed TLR.doubles()

2023-02-01 Thread kabutz
ThreadLocalRandom.current().doubles().parallel() had a bad regression, because it called the superclass methods of the ThreadLocalRandomProxy's nextDouble() method instead of delegating to the ThreadLocalRandom.current(). Affects all versions of ThreadLocalRandom since Java 17. -

Re: RFR: JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java from ProblemList-Xcomp.txt

2023-02-01 Thread Alan Bateman
On Wed, 1 Feb 2023 19:09:48 GMT, Mandy Chung wrote: > This test failure is no longer reproducible. It was added to the problem > list from JDK-8286368 as a clean up after JEP 425 Virtual Threads > integration. This PR removes it from the problem list. Marked as reviewed by alanb

RFR: JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java from ProblemList-Xcomp.txt

2023-02-01 Thread Mandy Chung
This test failure is no longer reproducible. It was added to the problem list from JDK-8286368 as a clean up after JEP 425 Virtual Threads integration. This PR removes it from the problem list. - Commit messages: - JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java from

Re: RFR: JDK-8301392: Port fdlibm log1p to Java [v4]

2023-02-01 Thread Joe Darcy
> Another day, another PR to port FDLBIM to Java, this time for the log1p > method. > > Other than using the two-argument form of the __HI method in Java > transliteration version rather than C macro, there are no appreciable > differences between the original C source in > >

Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v8]

2023-02-01 Thread Scott Gibbons
> Added code for Base64 acceleration (encode and decode) which will accelerate > ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3

Re: RFR: JDK-8301392: Port fdlibm log1p to Java [v3]

2023-02-01 Thread Joe Darcy
On Wed, 1 Feb 2023 07:16:25 GMT, Joe Darcy wrote: >> Another day, another PR to port FDLBIM to Java, this time for the log1p >> method. >> >> Other than using the two-argument form of the __HI method in Java >> transliteration version rather than C macro, there are no appreciable >>

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v4]

2023-02-01 Thread Sergey Tsypanov
On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg wrote: >> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for >> values in the range [-18h, 18h] for each second that is on an even quarter >> of an hour (i.e. at most 2*18*4+1 = 145 values). >> >> Instead of using a

Re: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]

2023-02-01 Thread Scott Gibbons
> Added code for Base64 acceleration (encode and decode) which will accelerate > ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error > Units > Base64Encode.testBase64Encode 1024 thrpt3

Re: RFR: 8300235: Use VarHandle access in Image(Input | Output)StreamImpl classes [v2]

2023-02-01 Thread Per Minborg
> This PR suggests improving performance by using the newly introduced class > `jdk.internal.util.ByteArray` to improve packing/unpacking operations. > > The PR also proposes adding a `ByteArrayLittleEndian` class for support for > little endian packing/unpacking. Per Minborg has updated the

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-01 Thread Jatin Bhateja
On Wed, 1 Feb 2023 12:30:36 GMT, Jatin Bhateja wrote: >> The Vector API `"indexInRange(int offset, int limit)"` is used >> to compute a vector mask whose lanes are set to true if the >> index of the lane is inside the range specified by the `"offset"` >> and `"limit"` arguments, otherwise the

Re: RFR: 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

2023-02-01 Thread Jatin Bhateja
On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong wrote: > The Vector API `"indexInRange(int offset, int limit)"` is used > to compute a vector mask whose lanes are set to true if the > index of the lane is inside the range specified by the `"offset"` > and `"limit"` arguments, otherwise the lanes

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v4]

2023-02-01 Thread Per Minborg
On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg wrote: >> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for >> values in the range [-18h, 18h] for each second that is on an even quarter >> of an hour (i.e. at most 2*18*4+1 = 145 values). >> >> Instead of using a

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v4]

2023-02-01 Thread Per Minborg
> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values > in the range [-18h, 18h] for each second that is on an even quarter of an > hour (i.e. at most 2*18*4+1 = 145 values). > > Instead of using a `ConcurrentHashMap` for caching instanced, we could > instead use an

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v3]

2023-02-01 Thread Per Minborg
> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values > in the range [-18h, 18h] for each second that is on an even quarter of an > hour (i.e. at most 2*18*4+1 = 145 values). > > Instead of using a `ConcurrentHashMap` for caching instanced, we could > instead use an

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v2]

2023-02-01 Thread Per Minborg
On Wed, 1 Feb 2023 07:58:02 GMT, Andrey Turbanov wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rework using a regular array and acquire/release semantics > > src/java.base/share/classes/java/time/ZoneOffset.java

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v2]

2023-02-01 Thread Per Minborg
> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values > in the range [-18h, 18h] for each second that is on an even quarter of an > hour (i.e. at most 2*18*4+1 = 145 values). > > Instead of using a `ConcurrentHashMap` for caching instanced, we could > instead use an

Re: RFR: JDK-8300098 : java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java fails with internal timeout when executed with TieredCompilation1/3

2023-02-01 Thread Jaikiran Pai
On Tue, 31 Jan 2023 10:45:07 GMT, Viktor Klang wrote: > The proposed fix by @DougLea ensures that the state transition into waiting > is retried in the cases where a previous waiter isn't making progress and a > new waiter goes into waiting. Hello Viktor, I don't have enough knowledge of this

Re: RFR: 8301367: Add exception handler method to the BaseLdapServer

2023-02-01 Thread Jaikiran Pai
On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov wrote: > The proposed change adds a new exception handler method to the > `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. > It will allow LDAP tests to customize the handling of server-side exceptions. > > The

Re: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey [v3]

2023-02-01 Thread Sergey Tsypanov
> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire > outdated. This simple clean-up modernizes them. Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: Restore logic - Changes: - all:

Re: RFR: 8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter [v7]

2023-02-01 Thread Raffaello Giulietti
On Tue, 31 Jan 2023 22:19:25 GMT, Joe Darcy wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8300869: Make use of the Double.toString(double) algorithm in >> java.util.Formatter > >

Re: RFR: 8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter [v8]

2023-02-01 Thread Raffaello Giulietti
> Align `double` and `float` decimal conversions in `java.util.Formatter` with > the algorithm used in `Double.toString(double)`. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8300869: Make use of the

Re: RFR: 8301569: list mode of jmod and jimage cannot be used normally in turkish locale

2023-02-01 Thread Glavo
On Wed, 1 Feb 2023 07:20:17 GMT, Alan Bateman wrote: > This is the lookup of the main.usage.list resource (`jimage list --help`) > rather than the `list` option but good to fix this anyway. Sorry, I found the problem with text search, but didn't look at them carefully. - PR:

Re: RFR: 8301569: list mode of jmod and jimage cannot be used normally in turkish locale

2023-02-01 Thread Glavo
On Wed, 1 Feb 2023 07:20:13 GMT, Alan Bateman wrote: > The equivalent in jlink and jimage are using Locale.ENGLISH, I guess we > should try to keep them consistent. This class is using `Locale.ROOT` to convert modifiers to lowercase, and there is no reference to `Locale.ENGLISH`.

Re: RFR: 8301578: Perform output outside synchronization in Module.class [v3]

2023-02-01 Thread Per Minborg
> This PR proposed to reduce contention in synchronized methods mainly by doing > I/O operations outside synch blocks. Per Minborg has updated the pull request incrementally with three additional commits since the last revision: - Revert benchmark change - Fix typo - Use another type of

Re: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x

2023-02-01 Thread Alan Bateman
On Wed, 1 Feb 2023 08:33:16 GMT, Amit Kumar wrote: > level:1, strategy: 0, dowrap: false > is finished: false Thanks for checking that. So "is finished: false" is telling us that not all of the input was compressed. So I think the right thing is to do the deflate in a loop

Re: RFR: 8301578: Perform output outside synchronization in Module.class [v2]

2023-02-01 Thread Per Minborg
> This PR proposed to reduce contention in synchronized methods mainly by doing > I/O operations outside synch blocks. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Update after comments - Remove warning - Changes:

Re: RFR: 8301578: Perform output outside synchronization in Module.class

2023-02-01 Thread Per Minborg
On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg wrote: > This PR proposed to reduce contention in synchronized methods mainly by doing > I/O operations outside synch blocks. Let me take a step back here and explain the reason why I think this PR is worth looking at. Firstly, I think the

Re: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x

2023-02-01 Thread Amit Kumar
On Mon, 30 Jan 2023 08:03:38 GMT, Amit Kumar wrote: > DeInflate.java test fails on s390x platform because size for out1 array which > is responsible for storing the compressed data is insufficient. And being > unable to write whole compressed data on array, on s390 whole data can't be >

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset

2023-02-01 Thread Andrey Turbanov
On Tue, 31 Jan 2023 15:57:43 GMT, Per Minborg wrote: > `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values > in the range [-18h, 18h] for each second that is on an even quarter of an > hour (i.e. at most 2*18*4+1 = 145 values). > > Instead of using a