Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v11]

2025-01-29 Thread Shaojin Wen
On Wed, 29 Jan 2025 18:47:25 GMT, Johannes Graham wrote: >> Shaojin Wen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> copyright > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 181: > >> 179: retur

Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v12]

2025-01-29 Thread Shaojin Wen
> 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 for numbers with length >= 3. > 2. It uses charAt(0) for t

Re: RFR: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode

2025-01-29 Thread Joe Wang
On Wed, 29 Jan 2025 20:42:30 GMT, Naoto Sato wrote: > Force opening "tzmappings" file in text mode. Confirmed the fix with customer > provided test case. Also replaced the file open function with the safer one. Marked as reviewed by joehw (Reviewer). - PR Review: https://git.openj

Re: RFR: 8344168: Change Unsafe base offset from int to long [v7]

2025-01-29 Thread Shaojin Wen
> The type of the Unsafe base offset constant is int, which may cause overflow > when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) > fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are > still unfixed. > > @liach proposed the idea of ​​changing th

Re: RFR: 8315585: Optimization for decimal to string [v2]

2025-01-29 Thread Shaojin Wen
> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString > and BigDecimal::toPlainString performance and reduce duplicate code Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - copyright

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11]

2025-01-29 Thread Kim Barrett
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` >> implementation. That implementation carries a doubly-linked list, and so >> makes DBB suffer from the same issue fixed for generic >> `java.lang.ref.Cleaner` users w

Re: RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33

2025-01-29 Thread Magnus Ihse Bursie
On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote: > Two groups of broken links appeared in the latest JDK docs, broken links to > man pages and broken ietf links. > > - The windows tools markdown files were not being converted to HTML because > they were placed under `windows/man` rather

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11]

2025-01-29 Thread Brent Christian
On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` >> implementation. That implementation carries a doubly-linked list, and so >> makes DBB suffer from the same issue fixed for generic >> `java.lang.ref.Cleaner` users w

Re: RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33

2025-01-29 Thread Chen Liang
On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote: > Two groups of broken links appeared in the latest JDK docs, broken links to > man pages and broken ietf links. > > - The windows tools markdown files were not being converted to HTML because > they were placed under `windows/man` rather

RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33

2025-01-29 Thread Nizar Benalla
Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links. - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their loca

Re: RFR: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode

2025-01-29 Thread Justin Lu
On Wed, 29 Jan 2025 20:42:30 GMT, Naoto Sato wrote: > Force opening "tzmappings" file in text mode. Confirmed the fix with customer > provided test case. Also replaced the file open function with the safer one. Fix looks correct to force "text mode". Switch to `fopen_s` also looks good. --

RFR: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode

2025-01-29 Thread Naoto Sato
Force opening "tzmappings" file in text mode. Confirmed the fix with customer provided test case. Also replaced the file open function with the safer one. - Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/23356/files Webrev: https://webrevs.openjdk.org

Re: RFR: 8347949: Currency method to stream available Currencies [v8]

2025-01-29 Thread Chen Liang
On Wed, 29 Jan 2025 18:35:31 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ >> which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request with a new target base

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping [v2]

2025-01-29 Thread Chen Liang
On Wed, 29 Jan 2025 19:20:34 GMT, Jorn Vernee wrote: >> Currently, to free the memory allocated in a confined arena, we keep track >> of a list of 'cleanup actions', stored in linked list format in a so-called >> `ResourceList`, attached to the scope of the arena. When the scope is >> closed,

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9]

2025-01-29 Thread Aleksey Shipilev
On Wed, 29 Jan 2025 19:42:49 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/java/lang/ref/Reference.java line 282: >> >>> 280: * This method returns a strong reference to the referent. This >>> may cause >>> 281: * the garbage collector to treat it as strongly reachable u

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11]

2025-01-29 Thread Aleksey Shipilev
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` > implementation. That implementation carries a doubly-linked list, and so > makes DBB suffer from the same issue fixed for generic > `java.lang.ref.Cleaner` users with > [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v10]

2025-01-29 Thread Aleksey Shipilev
On Wed, 29 Jan 2025 19:28:31 GMT, Kim Barrett wrote: >> Aleksey Shipilev 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 14 additional >> commit

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v10]

2025-01-29 Thread Kim Barrett
On Sat, 25 Jan 2025 07:14:51 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` >> implementation. That implementation carries a doubly-linked list, and so >> makes DBB suffer from the same issue fixed for generic >> `java.lang.ref.Cleaner` users w

Re: RFR: 8347949: Currency method to stream available Currencies [v8]

2025-01-29 Thread Naoto Sato
On Wed, 29 Jan 2025 18:35:31 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ >> which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request with a new target base

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping [v2]

2025-01-29 Thread Jorn Vernee
> Currently, to free the memory allocated in a confined arena, we keep track of > a list of 'cleanup actions', stored in linked list format in a so-called > `ResourceList`, attached to the scope of the arena. When the scope is closed, > we loop over all the entries in this resource list, and run

Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v11]

2025-01-29 Thread Johannes Graham
On Wed, 29 Jan 2025 16:30:46 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

Re: RFR: 8347949: Currency method to stream available Currencies [v8]

2025-01-29 Thread Justin Lu
> Please review this PR and CSR which adds a method to _java.util.Currency_ > which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains n

Re: RFR: 8344168: Change Unsafe base offset from int to long [v6]

2025-01-29 Thread Shaojin Wen
> The type of the Unsafe base offset constant is int, which may cause overflow > when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) > fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are > still unfixed. > > @liach proposed the idea of ​​changing th

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v10]

2025-01-29 Thread Naoto Sato
On Wed, 29 Jan 2025 17:53:04 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace >> ConcurrentMap to avoid object allocation caused by boxing from int to >> Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additio

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v10]

2025-01-29 Thread Shaojin Wen
> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace > ConcurrentMap to avoid object allocation caused by boxing from int to Integer > during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @naotoj ---

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9]

2025-01-29 Thread Brent Christian
On Wed, 29 Jan 2025 10:58:07 GMT, Aleksey Shipilev wrote: > > > Would you mind holding off until Tuesday to give time to get that done? > > > > > > Sure, there is no rush with this PR. I'll wait. > > How is it going, @AlanBateman? Any progress on closed tests? Nearly done - in review now. --

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v9]

2025-01-29 Thread Naoto Sato
On Wed, 29 Jan 2025 15:17:21 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace >> ConcurrentMap to avoid object allocation caused by boxing from int to >> Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additio

Re: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v15]

2025-01-29 Thread Sandhya Viswanathan
On Wed, 29 Jan 2025 06:26:41 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by >> [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection

Integrated: 8348898: Remove unused OctalDigits to clean up code

2025-01-29 Thread Shaojin Wen
On Tue, 28 Jan 2025 17:17:07 GMT, Shaojin Wen wrote: > This PR removes OctalDigits as it is no longer used after the removal of > StringTemplate. This pull request has now been integrated. Changeset: cbc89a7a Author:Shaojin Wen URL: https://git.openjdk.org/jdk/commit/cbc89a7ac6a45a

Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v11]

2025-01-29 Thread Shaojin Wen
> 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 for numbers with length >= 3. > 2. It uses charAt(0) for t

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8]

2025-01-29 Thread Chen Liang
On Wed, 29 Jan 2025 10:38:39 GMT, altrisi wrote: > That'd lower the constant memory overhead added by this change, as the CHM > started smaller. We use a size of 256 so C2 can apply array bound check elimination as it knows the resulting value from `& 0xFF` is ensured to be in the range of `[0

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v9]

2025-01-29 Thread Chen Liang
On Wed, 29 Jan 2025 15:17:21 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace >> ConcurrentMap to avoid object allocation caused by boxing from int to >> Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additio

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v9]

2025-01-29 Thread Shaojin Wen
> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace > ConcurrentMap to avoid object allocation caused by boxing from int to Integer > during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: copyright --

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping

2025-01-29 Thread Chen Liang
On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote: > Currently, to free the memory allocated in a confined arena, we keep track of > a list of 'cleanup actions', stored in linked list format in a so-called > `ResourceList`, attached to the scope of the arena. When the scope is closed, > we l

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8]

2025-01-29 Thread Chen Liang
On Wed, 29 Jan 2025 06:42:02 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace >> ConcurrentMap to avoid object allocation caused by boxing from int to >> Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additio

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping

2025-01-29 Thread Chen Liang
On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote: > Currently, to free the memory allocated in a confined arena, we keep track of > a list of 'cleanup actions', stored in linked list format in a so-called > `ResourceList`, attached to the scope of the arena. When the scope is closed, > we l

Integrated: 8348870: Eliminate array bound checks in DecimalDigits

2025-01-29 Thread Shaojin Wen
On Tue, 28 Jan 2025 14:49:45 GMT, Shaojin Wen wrote: > Expand DIGITS length to 128 and eliminate array bounds checking by using & > 0x7F when accessing DIGITS This pull request has now been integrated. Changeset: f98d9a33 Author:Shaojin Wen URL: https://git.openjdk.org/jdk/commit/f

Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v10]

2025-01-29 Thread Shaojin Wen
On Wed, 29 Jan 2025 01:55:10 GMT, Johannes Graham wrote: > A nice enhancement would be to allow > `String.parseInt(CharSequence,int,int,int)` to also use this code when the > CharSequence actually was a String. Could benefit, for example, > `java.util.Formatter` Your suggestion is very good,

RFR: 8348668: Prevent first resource cleanup in confined arena from escaping

2025-01-29 Thread Jorn Vernee
Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8]

2025-01-29 Thread Shaojin Wen
On Wed, 29 Jan 2025 10:38:39 GMT, altrisi wrote: > quarters The size of AtomicReferenceArray is 256, and using `& 0xff` can eliminate array bounds checking. - PR Comment: https://git.openjdk.org/jdk/pull/23337#issuecomment-2621393609

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping

2025-01-29 Thread Jorn Vernee
On Tue, 28 Jan 2025 03:31:58 GMT, Chen Liang wrote: >> Why do you think it should? We never assign the newly allocated resource >> cleanup to `fst`. > > So was the culprit `cleanup.next = fst;`? Yes, in combination with the while loop which runs all the cleanups, which adds a phi node that mer

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping

2025-01-29 Thread Chen Liang
On Tue, 28 Jan 2025 03:20:22 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line >> 112: >> >>> 110: if (fst != ResourceCleanup.CLOSED_LIST) { >>> 111: ResourceCleanup prev = fst; >>> 112: fst = Resour

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping

2025-01-29 Thread Jorn Vernee
On Tue, 28 Jan 2025 00:08:27 GMT, Chen Liang wrote: >> Currently, to free the memory allocated in a confined arena, we keep track >> of a list of 'cleanup actions', stored in linked list format in a so-called >> `ResourceList`, attached to the scope of the arena. When the scope is >> closed, w

Re: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping

2025-01-29 Thread Chen Liang
On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote: > Currently, to free the memory allocated in a confined arena, we keep track of > a list of 'cleanup actions', stored in linked list format in a so-called > `ResourceList`, attached to the scope of the arena. When the scope is closed, > we l

Re: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9]

2025-01-29 Thread Aleksey Shipilev
On Mon, 27 Jan 2025 09:08:56 GMT, Aleksey Shipilev wrote: > > Would you mind holding off until Tuesday to give time to get that done? > > Sure, there is no rush with this PR. I'll wait. How is it going, @AlanBateman? Any progress on closed tests? - PR Comment: https://git.openjdk.

Re: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8]

2025-01-29 Thread altrisi
On Wed, 29 Jan 2025 06:42:02 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace >> ConcurrentMap to avoid object allocation caused by boxing from int to >> Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additio