Re: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class

2025-05-08 Thread Alan Bateman
On Fri, 9 May 2025 02:45:16 GMT, David Holmes wrote: > The underlying issue is nested-parking as Alan notes. From re-reading > 8074773, pre-loading in any class loaded by the boot loader, has no affect on > the bug. The issue was the action taken by the AppLoader that involved > creating an en

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are >> blocked on the expected locks before invoking findMonitorDeadlockedThreads. >> In the failing cases, one of the threads is seen as blocked while wait

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 19:49:05 GMT, Patricio Chilano Mateo wrote: >> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line >> 99: >> >>> 97: System.out.println("Waiting for thread1 and thread2 to deadlock >>> ..."); >>> 98: awaitBlocked(thread1, reached1); >

Re: RFR: 8356486: ReverseOrderListView should override reversed() to return `base`

2025-05-08 Thread Per Minborg
On Thu, 8 May 2025 16:13:19 GMT, Stuart Marks wrote: >> test/jdk/java/util/Collection/MOAT.java line 507: >> >>> 505: private static void testImmutableSeqColl(final >>> SequencedCollection c, T t) { >>> 506: SequencedCollection r = c.reversed(); >>> 507: if (r instanceof Li

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 19:51:12 GMT, Chen Liang wrote: > May I provide a quick patch to use an alternative mechanism to test preview > class file versions for that class instead of changing that in this PR? That would be good as it shouldn't depend on ScopedValue being a preview API class. --

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes [v3]

2025-05-08 Thread Ioi Lam
> This is a general fix for all the "points to a static field that may hold a > different value" failures related to `java/lang/invoke/MethodHandleImpl`. > E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), > [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330). > > AOT-cac

Re: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class

2025-05-08 Thread David Holmes
On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote: > Hopefully David will remember more of this when he gets back. Sadly I have to page in all the details again like everyone else. The underlying issue is nested-parking as Alan notes. From re-reading 8074773, pre-loading in any class loaded

Re: RFR: 8355746: Start of release updates for JDK 26 [v2]

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 13:18:07 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains seven commits: > > - Update release date > - Update --release 25 symbol information f

Re: RFR: 8352480: Don't follow symlinks in additional content for app images [v4]

2025-05-08 Thread Alexey Semenyuk
On Fri, 9 May 2025 01:39:07 GMT, Alexander Matveev wrote: >> - Symbolic links will not be followed for `--app-content` on all platforms. >> - Added test to cover this case. >> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, >> since "cp -r" on macOS is not documented

Re: RFR: 8352480: Don't follow symlinks in additional content for app images [v3]

2025-05-08 Thread Alexey Semenyuk
On Fri, 9 May 2025 00:10:34 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/share/AppContentTest.java line 116: >> >>> 114: private static Path getAppContentPath(JPackageCommand cmd, Path >>> name) { >>> 115: Path contentDir = cmd.appLayout().contentDirectory(); >>> 116:

Re: RFR: 8352480: Don't follow symlinks in additional content for app images [v4]

2025-05-08 Thread Alexander Matveev
> - Symbolic links will not be followed for `--app-content` on all platforms. > - Added test to cover this case. > - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, > since "cp -r" on macOS is not documented option and when used `cp` will > follow symbolic links which br

Re: RFR: 8352480: Don't follow symlinks in additional content for app images [v3]

2025-05-08 Thread Alexander Matveev
On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev wrote: >> - Symbolic links will not be followed for `--app-content` on all platforms. >> - Added test to cover this case. >> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, >> since "cp -r" on macOS is not documented

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Leonid Mesnik
On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth wrote: >> This change tries to add timeout to individual testcases so that I am able >> to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests >> and test

Re: RFR: 8351443: Improve robustness of StringBuilder [v7]

2025-05-08 Thread Roger Riggs
> Refactor AbstractStringBuilder to maintain consistency among count, coder, > and value buffers while the buffer capacity is being expanded and/or inflated > from Latin1 to UTF16 representations. > The refactoring pattern is to read and write AbstractStringBuilder fields > once using locals fo

Integrated: 8333568: Test that jpackage doesn't modify R/O files/directories

2025-05-08 Thread Alexey Semenyuk
On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote: > Add a check that jpackage doesn't modify files/directories supplied with > "--app-image", "--resource-dir", "--runtime-image", "--app-content", and > "--mac-dmg-content" options to every jpackage test. This pull request has now been int

Re: RFR: 8352480: Don't follow symlinks in additional content for app images [v3]

2025-05-08 Thread Alexander Matveev
On Wed, 7 May 2025 12:26:54 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8352480: [macos] Don't follow symlinks in additional content for app >> images [v5] > > test/jdk/tools/jpackage

Re: RFR: 8356555: Incorrect use of {@link} in BigDecimal

2025-05-08 Thread Nizar Benalla
On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. I think this looks good. - Marked as reviewed by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826639744

Re: RFR: 8348351: Improve lazy initialization of the available currencies set [v2]

2025-05-08 Thread Naoto Sato
On Thu, 8 May 2025 23:30:06 GMT, Justin Lu wrote: >> Please review this PR which stems from discussion in the PR of JDK-8347949. >> >> The set of lazily loaded Currencies is a good fit for stable values. >> `available` can now be made final as it is a SV supplier. >> >> (This change also inclu

Re: RFR: 8348351: Improve lazy initialization of the available currencies set [v2]

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 23:26:57 GMT, Justin Lu wrote: >> Please review this PR which stems from discussion in the PR of JDK-8347949. >> >> The set of lazily loaded Currencies is a good fit for stable values. >> `available` can now be made final as it is a SV supplier. >> >> (This change also inclu

Re: RFR: 8348351: Improve lazy initialization of the available currencies set [v2]

2025-05-08 Thread Justin Lu
On Thu, 8 May 2025 23:08:27 GMT, Chen Liang wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Chen's review - method name clarification > > src/java.base/share/classes/java/util/Currency.java line 471: > >> 469: >> 47

Re: RFR: 8348351: Improve lazy initialization of the available currencies set [v2]

2025-05-08 Thread Justin Lu
> Please review this PR which stems from discussion in the PR of JDK-8347949. > > The set of lazily loaded Currencies is a good fit for stable values. > `available` can now be made final as it is a SV supplier. > > (This change also includes an unrelated minor edit to comments in > `Currency::g

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Leonid Mesnik
On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth wrote: >> doc/testing.md line 385: >> >>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a >>> 384: certain amount of time will apply this factor. If we run in >>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunT

Re: RFR: 8348351: Improve lazy initialization of the available currencies set

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 22:55:34 GMT, Justin Lu wrote: > Please review this PR which stems from discussion in the PR of JDK-8347949. > > The set of lazily loaded Currencies is a good fit for stable values. > `available` can now be made final as it is a SV supplier. > > (This change also includes an

RFR: 8348351: Improve lazy initialization of the available currencies set

2025-05-08 Thread Justin Lu
Please review this PR which stems from discussion in the PR of JDK-8347949. The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier. (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies`

Integrated: 8356562: SigningAppImageTwoStepsTest test fails

2025-05-08 Thread Alexey Semenyuk
On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote: > Fix JPackageCommand.assertAppImageFile() method to make it pass the relative > path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). This pull request has now been integrated. Changeset: 8a8893ec Author:Alexey Semen

Re: RFR: 8333568: Test that jpackage doesn't modify R/O files/directories

2025-05-08 Thread Alexander Matveev
On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote: > Add a check that jpackage doesn't modify files/directories supplied with > "--app-image", "--resource-dir", "--runtime-image", "--app-content", and > "--mac-dmg-content" options to every jpackage test. Looks good. - Marked

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are >> blocked on the expected locks before invoking findMonitorDeadlockedThreads. >> In the failing cases, one of the threads is seen as blocked while wait

Integrated: 8355573: Remove kludge_c++11.h from jpackage code

2025-05-08 Thread Julian Waters
On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having > access to C++ utilities like std::unique_ptr. Since we are already on C++14 > (And hopefully will get C++17 soon) this workaround can be removed from > jpackage

Re: RFR: 8355573: Remove kludge_c++11.h from jpackage code

2025-05-08 Thread Julian Waters
On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote: > kludge_c++11.h was introduced to work around older C++ versions not having > access to C++ utilities like std::unique_ptr. Since we are already on C++14 > (And hopefully will get C++17 soon) this workaround can be removed from > jpackage

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are >> blocked on the expected locks before invoking findMonitorDeadlockedThreads. >> In the failing cases, one of the threads is seen as blocked while wait

Re: RFR: 8356562: SigningAppImageTwoStepsTest test fails

2025-05-08 Thread Alexander Matveev
On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote: > Fix JPackageCommand.assertAppImageFile() method to make it pass the relative > path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). Looks good. - Marked as reviewed by almatvee (Reviewer). PR Review: http

Re: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550

2025-05-08 Thread Joe Wang
On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time > zone data was downgraded by the TZUpdater tool in which some time zones are > missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, > while `Tim

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Daniel Fuchs
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry

2025-05-08 Thread Eirik Bjørsnøs
On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses the issue noted in > https://bugs.openjdk.org/browse/JDK-8354799? > > `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero > size was missing a CRC check for tha

Re: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]

2025-05-08 Thread Raffaello Giulietti
On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Suggested changes > > Please update the 2nd copyright year in `BigInteger`. > > Otherwise looks good. > As soon

Re: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v7]

2025-05-08 Thread Julian Waters
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in >> the Windows specific codebase. Some of these seem to be bugs. I've taken the >> effort to mark out all the relevant globals and locals that trigger the >> u

Re: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550

2025-05-08 Thread Justin Lu
On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time > zone data was downgraded by the TZUpdater tool in which some time zones are > missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, > while `Tim

Re: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550

2025-05-08 Thread Brian Burkhalter
On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote: > Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time > zone data was downgraded by the TZUpdater tool in which some time zones are > missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, > while `Tim

Re: RFR: 8356555: Incorrect use of {@link} in BigDecimal

2025-05-08 Thread Brian Burkhalter
On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. Looks fine. - Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826409763

Re: RFR: 8356555: Incorrect use of {@link} in BigDecimal

2025-05-08 Thread Iris Clark
On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote: > Fix javadoc tags. Marked as reviewed by iris (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826397554

Re: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes [v2]

2025-05-08 Thread Vladimir Ivanov
On Mon, 5 May 2025 23:50:31 GMT, Ioi Lam wrote: >> This is a general fix for all the "points to a static field that may hold a >> different value" failures related to `java/lang/invoke/MethodHandleImpl`. >> E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), >> [JDK-8353330](http

RFR: 8333568: Test that jpackage doesn't modify R/O files/directories

2025-05-08 Thread Alexey Semenyuk
Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test. - Commit messages: - Verify jpackage doesn't modify external directories passed to j

Re: RFR: 8333568: Test that jpackage doesn't modify R/O files/directories

2025-05-08 Thread Alexey Semenyuk
On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk wrote: > Add a check that jpackage doesn't modify files/directories supplied with > "--app-image", "--resource-dir", "--runtime-image", "--app-content", and > "--mac-dmg-content" options to every jpackage test. @sashamatveev PTAL -

RFR: 8356555: Incorrect use of {@link} in BigDecimal

2025-05-08 Thread Joe Darcy
Fix javadoc tags. - Commit messages: - JDK-8356555: Incorrect use of {@link} in BigDecimal Changes: https://git.openjdk.org/jdk/pull/25131/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356555 Stats: 2 lines in

RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550

2025-05-08 Thread Naoto Sato
Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Phil Race
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread Kevin Walls
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are >> blocked on the expected locks before invoking findMonitorDeadlockedThreads. >> In the failing cases, one of the threads is seen as blocked while wait

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a >> null argument. > > Andrew Haley has updated the pull request incrementally with one additional > commit since the last revi

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread Patricio Chilano Mateo
On Thu, 8 May 2025 19:17:19 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Rename awaitBlocked to awaitTrueAndBlocked > > test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadloc

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread Patricio Chilano Mateo
> Please review this small test fix. We need to make sure the two threads are > blocked on the expected locks before invoking findMonitorDeadlockedThreads. > In the failing cases, one of the threads is seen as blocked while waiting for > a class to be initialized by the other thread (I've added

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v3]

2025-05-08 Thread Benjamin Peterson
On Thu, 8 May 2025 19:13:46 GMT, Alan Bateman wrote: >> Conditional on what? > > The appending of the "." is specific to the case where there isn't a .dll > suffix. `LoadLibrary` appears to happily load files with a `.dll` extension even if a trailing `.` is appended. So, special casing doesn'

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v3]

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 19:05:56 GMT, Benjamin Peterson wrote: >> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line >> 124: >> >>> 122: return null; >>> 123: } >>> 124: name = file.getCanonicalPath() + >>> ClassLoaderHelper

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. We need to make sure the two threads are > blocked on the expected locks before invoking findMonitorDeadlockedThreads. > In the failing cases, one of the threads is seen as blocked while waiting

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v3]

2025-05-08 Thread Benjamin Peterson
On Thu, 8 May 2025 19:00:26 GMT, Alan Bateman wrote: >> Benjamin Peterson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fix spelling > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124: > >> 122:

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v3]

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is >> called on the target library file before it is passed to the system library >> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve >

Re: RFR: 8301971: Make JDK source code UTF-8 [v6]

2025-05-08 Thread Naoto Sato
On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This >> has recently become an acute problem, since our mixing of iso-8859-1 and >> utf-8 in properties files confused the version of `sed` that is shipped with

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v3]

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 17:18:12 GMT, Andrew Haley wrote: >> @theRealAph Can you include the update to javax/security/auth/Subject.java >> as part of this? > >> @theRealAph Can you include the update to javax/security/auth/Subject.java >> as part of this? > > Fixed now. @theRealAph One other test

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6]

2025-05-08 Thread Vicente Romero
On Thu, 8 May 2025 13:33:45 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, >> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and >> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation >> that an argument to a given method or c

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v3]

2025-05-08 Thread Brian Burkhalter
On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is >> called on the target library file before it is passed to the system library >> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve >

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Alan Bateman
On Thu, 8 May 2025 18:18:44 GMT, Chen Liang wrote: > I noted that `ThreadFlock` is using scoped values but throwing > `StructureViolationException` introduced by structured concurrency - is it > considered an implementation artifact and part of structured concurrency > instead? ThreadFlock su

Re: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55]

2025-05-08 Thread Raffaello Giulietti
On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in >> `pow()` is not concerned most on execution time, but rather in memory >> optimization, because the PR implementation does the "shift of the exponent" >> squarin

Re: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]

2025-05-08 Thread fabioromano1
On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti wrote: > Otherwise looks good. As soon as you feel comfortable with your changes, let > me know so that I can approve. @rgiulietti For me, now the code is ready. - PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a >> null argument. > > Andrew Haley has updated the pull request incrementally with one additional > commit since the last revi

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a >> null argument. > > Andrew Haley has updated the pull request incrementally with one additional > commit since the last revi

Re: RFR: 8352755: Misconceptions about j.text.DecimalFormat digits during parsing [v3]

2025-05-08 Thread Justin Lu
> Please review this PR which clarifies the behavior for integer and fraction > limits in NumberFormat and implementing classes. An associated CSR is filed. > > There have been a few bugs submitted which indicate a misconception that > these limits impact parsing. The actual behavior is that the

Integrated: 8356221: Clarify Console.charset() method description

2025-05-08 Thread Naoto Sato
On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote: > Simple clarification of the `Console.charset()` method description, making > explicit how the charset is applied. This pull request has now been integrated. Changeset: e4ecda2b Author:Naoto Sato URL: https://git.openjdk.org/jdk/c

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v2]

2025-05-08 Thread Brian Burkhalter
On Thu, 8 May 2025 17:43:31 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is >> called on the target library file before it is passed to the system library >> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve >

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 17:47:12 GMT, Petr Portnov | PROgrm_JARvis wrote: >> Andrew Haley has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix merge > > src/java.base/share/classes/java/lang/ScopedValue.java line 613: > >> 611: */ >> 61

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Daniel Fuchs
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v3]

2025-05-08 Thread Benjamin Peterson
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is > called on the target library file before it is passed to the system library > loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve > symlinks on Windows. This had unintended consequences for pass

Re: RFR: 8356221: Clarify Console.charset() method description

2025-05-08 Thread Naoto Sato
On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote: > Simple clarification of the `Console.charset()` method description, making > explicit how the charset is applied. Thanks for the review, Brian - PR Comment: https://git.openjdk.org/jdk/pull/25103#issuecomment-2863826743

Re: RFR: 8348828: Windows dll loading now resolves symlinks

2025-05-08 Thread Benjamin Peterson
On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman wrote: > > You might be correct. We'll see what @AlanBateman and others have to say > > about it. > > I'm still puzzled as to why the DLLs have been moved from the JDK bin > directory to some other location, and renamed so they don't have the ".dll

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Petr Portnov | PROgrm_JARvis
On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote: >> Propose to finalize scoped values. >> The only functional change is that the orElse() method no longer accepts a >> null argument. > > Andrew Haley has updated the pull request incrementally with one additional > commit since the last revi

Re: RFR: 8348828: Windows dll loading now resolves symlinks [v2]

2025-05-08 Thread Benjamin Peterson
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is > called on the target library file before it is passed to the system library > loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve > symlinks on Windows. This had unintended consequences for pass

Re: RFR: 8356562: SigningAppImageTwoStepsTest test fails

2025-05-08 Thread Alexey Semenyuk
On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk wrote: > Fix JPackageCommand.assertAppImageFile() method to make it pass the relative > path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). @sashamatveev PTAL - PR Comment: https://git.openjdk.org/jdk/pull/25126#i

RFR: 8356562: SigningAppImageTwoStepsTest test fails

2025-05-08 Thread Alexey Semenyuk
Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage(). - Commit messages: - Fix a bug in JPackageCommand.assertFileInAppImage() uncovered by running signing tests after JDK-8356219 fix. JDK

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v7]

2025-05-08 Thread Andrew Haley
> Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a > null argument. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Fix merge - Changes: - all: https://gi

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v3]

2025-05-08 Thread Andrew Haley
On Wed, 30 Apr 2025 12:48:08 GMT, Alan Bateman wrote: > @theRealAph Can you include the update to javax/security/auth/Subject.java as > part of this? Fixed now. - PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863756144

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v5]

2025-05-08 Thread Andrew Haley
> Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a > null argument. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: ScopedValue::orElse() does not accept null as an argum

Re: RFR: 8355022: Implement JEP 506: Scoped Values [v6]

2025-05-08 Thread Andrew Haley
> Propose to finalize scoped values. > The only functional change is that the orElse() method no longer accepts a > null argument. Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Fix merge - Merge from

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Leo Korinth
On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson wrote: >> This change tries to add timeout to individual testcases so that I am able >> to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests >> and

Re: RFR: 8301971: Make JDK source code UTF-8 [v6]

2025-05-08 Thread Erik Joelsson
On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This >> has recently become an acute problem, since our mixing of iso-8859-1 and >> utf-8 in properties files confused the version of `sed` that is shipped with

Re: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55]

2025-05-08 Thread fabioromano1
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in > `pow()` is not concerned most on execution time, but rather in memory > optimization, because the PR implementation does the "shift of the exponent" > squaring the result rather than the base, so the base is not squar

Re: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 16:19:41 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/ClassValue.java >> >> Co-authored-by: Shaojin Wen > > src/java.base/sha

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Stefan Karlsson
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Leo Korinth
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]

2025-05-08 Thread Jaikiran Pai
On Fri, 2 May 2025 15:17:25 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from >> `ClassValue::computeValue()` end up in infinite loops while fixing the stale >> value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix,

Re: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]

2025-05-08 Thread fabioromano1
On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Suggested changes > > Please update the 2nd copyright year in `BigInteger`. > > Otherwise looks good. > As soon

Re: RFR: 8356486: ReverseOrderListView::reversed should return `base`

2025-05-08 Thread Stuart Marks
On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote: > This PR proposed to let `ReverseOrderListView::reversed` return `base` so > that nested reversed views are avoided. src/java.base/share/classes/java/util/ReverseOrderListView.java line 398: > 396: } > 397: > 398: @Override I don't

Re: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]

2025-05-08 Thread Jaikiran Pai
On Fri, 2 May 2025 15:17:25 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from >> `ClassValue::computeValue()` end up in infinite loops while fixing the stale >> value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix,

Re: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]

2025-05-08 Thread Jaikiran Pai
On Fri, 2 May 2025 15:17:25 GMT, Chen Liang wrote: >> The recent patch #23866 makes calling `ClassValue::remove()` from >> `ClassValue::computeValue()` end up in infinite loops while fixing the stale >> value risk from the method. >> >> The proposed fix is to preserve the stale value risk fix,

Re: RFR: 8356080: Address post-integration comments for Stable Values

2025-05-08 Thread Stuart Marks
On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote: > This PR proposes to address comments in the initial PR for Stable Values, > which were deferred until after integration. > > Unfortunately, this PR shows the total commit history for stable values. src/java.base/share/classes/java/util/Immu

Re: RFR: 8356486: ReverseOrderListView::reversed should return `base`

2025-05-08 Thread Stuart Marks
On Thu, 8 May 2025 14:44:26 GMT, Chen Liang wrote: >> This PR proposed to let `ReverseOrderListView::reversed` return `base` so >> that nested reversed views are avoided. > > test/jdk/java/util/Collection/MOAT.java line 507: > >> 505: private static void testImmutableSeqColl(final >> Sequ

Re: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]

2025-05-08 Thread Chen Liang
On Thu, 8 May 2025 16:01:51 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/ClassValue.java >> >> Co-authored-by: Shaojin Wen > > src/java.base/sha

Re: RFR: 8356486: ReverseOrderListView::reversed should return `base`

2025-05-08 Thread Stuart Marks
On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote: > This PR proposed to let `ReverseOrderListView::reversed` return `base` so > that nested reversed views are avoided. I think there are already tests to ensure that list.reversed().reversed() returns the original list. See also https://github

RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock

2025-05-08 Thread Patricio Chilano Mateo
Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stac

Re: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]

2025-05-08 Thread Raffaello Giulietti
On Thu, 8 May 2025 15:33:17 GMT, fabioromano1 wrote: >> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in >> `pow()` is not concerned most on execution time, but rather in memory >> optimization, because the PR implementation does the "shift of the exponent" >> squarin

Re: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]

2025-05-08 Thread fabioromano1
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in > `pow()` is not concerned most on execution time, but rather in memory > optimization, because the PR implementation does the "shift of the exponent" > squaring the result rather than the base, so the base is not squar

Re: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations [v10]

2025-05-08 Thread David Beaumont
On Thu, 8 May 2025 13:16:25 GMT, Per Minborg wrote: >> This sketch shows how "Stable Updaters" can be used to create stable >> computations of `@Stable` fields. Only one updater is needed per class, >> similar to `AtomicIntegerFieldUpdater`. > > Per Minborg has updated the pull request incremen

  1   2   >