Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28]

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code review easier the changes

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9]

On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: >> >>> 271: ? frame_sp + fsize - frame::sender_sp_offset >>> 272: // we need to re-read fp because it may be an oop and we might >>> have f

Re: RFR: 8343237: Improve the copying of the available set of Currencies

On Fri, 1 Nov 2024 23:17:01 GMT, Justin Lu wrote: > Please review this PR which is a small cleanup in > `Currency.getAvailableCurrencies()`. We can use the `HashSet` constructor > over `clone()` to make the defensive copy of the set of available currencies. > This gets rid of the unsightly unc

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8]

On Fri, 1 Nov 2024 22:24:28 GMT, Jiangli Zhou wrote: > > I finally noticed that you are testing a precompiled HelloWorld class, and > > I have been running with a source file argument to have java compile it on > > the fly. > > When I try using a pre-compiled HelloWorld, the linux port works fo

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v3]

On Sat, 2 Nov 2024 00:27:52 GMT, Mandy Chung wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reuse the check implementation > > src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 191: > >> 189

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v3]

On Sat, 2 Nov 2024 00:16:41 GMT, Chen Liang wrote: >> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) >> #20665, the validation methods `validateBinaryClassName` and >> `validateInternalClassName` only checks if a separator char is the initial >> or final char, or i

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v4]

> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) > #20665, the validation methods `validateBinaryClassName` and > `validateInternalClassName` only checks if a separator char is the initial or > final char, or if it immediately follows another chars. This omitted the

RFR: 8317542: Specjvm::xml have scalability issue for high vCPU numbers

The synchronization block may be substituted by the 'volatile' variable smaller synchronization block. It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score. Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2. Un

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]

On Fri, 1 Nov 2024 23:57:20 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line >> 258: >> >>> 256: if (name.isEmpty()) >>> 257: return name; >>> 258: return validateBinaryClassName(name); >> >> Perhaps have a utility

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v3]

> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) > #20665, the validation methods `validateBinaryClassName` and > `validateInternalClassName` only checks if a separator char is the initial or > final char, or if it immediately follows another chars. This omitted the

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]

On Fri, 1 Nov 2024 21:32:23 GMT, Mandy Chung wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Comments to clarify, also align skipOverFieldSignature > > src/java.base/share/classes/jdk/internal/constant/ConstantUtils.

RFR: 8343237: Improve the copying of the available set of Currencies

Please review this PR which is a small cleanup in `Currency.getAvailableCurrencies()`. We can use the `HashSet` constructor over `clone()` to make the defensive copy of the set of available currencies. This gets rid of the unsightly unchecked cast and SuppressWarnings annotation. -

Re: RFR: 8341399: Add since checker tests to the langtools modules [v4]

> Can I get a review for this patch that adds `@since` checker tests to the > following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. > The initial test for `java.base` has been integrated in > [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). > > The jtreg comment

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]

On Fri, 1 Nov 2024 19:24:05 GMT, Chen Liang wrote: >> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) >> #20665, the validation methods `validateBinaryClassName` and >> `validateInternalClassName` only checks if a separator char is the initial >> or final char, or i

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8]

On Fri, 1 Nov 2024 16:09:20 GMT, Magnus Ihse Bursie wrote: > I finally noticed that you are testing a precompiled HelloWorld class, and I > have been running with a source file argument to have java compile it on the > fly. > > When I try using a pre-compiled HelloWorld, the linux port works f

Re: RFR: 8340311: JPackage app-image exe launches multiple exe's in JDK 22+ [v4]

On Fri, 1 Nov 2024 22:17:21 GMT, Alexey Semenyuk wrote: >> Support `win.norestart` application property in jpackage .cfg file. If found >> in the .cfg file and set to `true`, it forces the Windows app launcher not >> to restart the launcher process. >> >> Collateral changes to the tests: >> -

Re: RFR: 8340311: JPackage app-image exe launches multiple exe's in JDK 22+ [v4]

> Support `win.norestart` application property in jpackage .cfg file. If found > in the .cfg file and set to `true`, it forces the Windows app launcher not to > restart the launcher process. > > Collateral changes to the tests: > - Added `WindowsHelper.killProcess()` to kill process by PID; >

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>>

Re: RFR: 8340311: JPackage app-image exe launches multiple exe's in JDK 22+ [v2]

On Thu, 31 Oct 2024 22:32:33 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Better log message >> - Rework findAppLauncherPID() into findAndKillAppLauncherProcess() that >> will kil

Re: RFR: 8340311: JPackage app-image exe launches multiple exe's in JDK 22+ [v3]

> Support `win.norestart` application property in jpackage .cfg file. If found > in the .cfg file and set to `true`, it forces the Windows app launcher not to > restart the launcher process. > > Collateral changes to the tests: > - Added `WindowsHelper.killProcess()` to kill process by PID; >

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28]

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code review easier the changes

Re: RFR: 8333582: Update CLDR to Version 46.0 [v2]

On Fri, 1 Nov 2024 20:10:02 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addresses review comments > > test/jdk/sun/text/resources/LocaleDataTest.java line 44: > >> 42: * 8209775 8221432 82271

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

On Tue, 29 Oct 2024 12:56:25 GMT, Sean Mullan wrote: >> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30: >> >>> 28: * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom >>> 29: * @compile -XDignore.symbol.file Marshal.java >>> 30: * @run main/othervm/java.security.poli

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28]

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code review easier the changes

Re: RFR: 8333582: Update CLDR to Version 46.0 [v2]

On Thu, 31 Oct 2024 20:06:24 GMT, Naoto Sato wrote: >> Upgrading the CLDR to version 46.0. A corresponding CSR has also been >> drafted. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Addresses review comments Looks good t

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12]

On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It >>> sounds like there is code that is using rsp instead of last_Java_sp to >>> compute the frame boundary. Isn't that a bug that should be fixed? >>> >> It's not a bug, it

Re: RFD: "equal" vs "equivalent" in Float.NaN, Double.NaN

On Fri, Nov 1, 2024 at 8:42 PM Joseph D. Darcy wrote: > A few releases back, a discussion of "quality, equivalence, and comparison > of floating-point values" was added to java.lang.Double: > > > https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Double.html#equivalenceRelatio

Re: RFD: "equal" vs "equivalent" in Float.NaN, Double.NaN

On 11/1/2024 12:11 PM, Eirik Bjørsnøs wrote: Hi, Just an observation from a floating point layman: I noticed that Float and Double uses "It is equal to the value.." when describing various constant values like MIN_VALUE, MAX_VALUE etc. A few releases back, a discussion of "quality, equival

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

On Mon, 28 Oct 2024 14:35:57 GMT, Sean Mullan wrote: >> That and possibly rename the test because now it does not have anything to >> do with the SecurityException. Now we only check that providing an empty >> file causes the InvalidMidiDataException so EmptySoundBankTest or something >> to th

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28]

> This is the implementation of JEP 491: Synchronize Virtual Threads without > Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for > further details. > > In order to make the code review easier the changes have been split into the > following initial 4 commits: > > - Change

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

On Thu, 24 Oct 2024 20:57:50 GMT, Sean Mullan wrote: >> @honkar-jdk I'm inclined to leave it as because it's not the only method >> which doesn't have a blank line between `@param` and `@throw` in this file. >> >> If it's worth taking care of, we may submit another bug to address it later. > >

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

On Mon, 28 Oct 2024 18:07:26 GMT, Harshitha Onkar wrote: >> I'd not looked at this test before but when I do the thing I noticed is that >> createPrivateValue is no longer used. >> But I don't see a problem with keeping the rest of the test. > > Test updated in sandbox - > https://github.com/op

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]

> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) > #20665, the validation methods `validateBinaryClassName` and > `validateInternalClassName` only checks if a separator char is the initial or > final char, or if it immediately follows another chars. This omitted the

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25]

On Fri, 1 Nov 2024 01:53:01 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - add comment to ThreadService::find_deadlocks_at_safepoint >> - Remove assignments in preempt_kind enum > >

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

On Mon, 28 Oct 2024 14:08:46 GMT, Sean Mullan wrote: >> src/java.desktop/share/classes/java/awt/Font.java line 1612: >> >>> 1610: * obtained. The {@code String} value of this property is then >>> 1611: * interpreted as a {@code Font} object according to the >>> 1612: * specificat

RFD: "equal" vs "equivalent" in Float.NaN, Double.NaN

Hi, Just an observation from a floating point layman: I noticed that Float and Double uses "It is equal to the value.." when describing various constant values like MIN_VALUE, MAX_VALUE etc. However, Float.NaN and Double.NaN instead uses "equivalent to": /** > * A constant holding a Not-a-Numb

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>>

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v27]

> This is the implementation of JEP 491: Synchronize Virtual Threads without > Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for > further details. > > In order to make the code review easier the changes have been split into the > following initial 4 commits: > > - Change

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v7]

On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman wrote: >> Thanks for the explanation but that needs to be documented somewhere. > > The comment in afterYield has been expanded in the loom repo, we may be able > to bring that update in. Brought the comment from the loom repo. - PR R

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names

On Fri, 1 Nov 2024 17:36:01 GMT, Mandy Chung wrote: > With your proposed change, all validations are done by > `validateBinaryClassName`? Yes. Now all validations are done by that and `validateInternalClassName`, which uses the `/` separator instead of the `.` separator char. Meanwhile, the

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v22]

On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line >> 57: >> >>> 55: static { >>> 56: try { >>> 57: >>> MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); >> >> Why is th

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25]

On Fri, 1 Nov 2024 15:21:50 GMT, Axel Boldt-Christmas wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - add comment to ThreadService::find_deadlocks_at_safepoint >> - Remove assignments in preempt_kind

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v26]

> This is the implementation of JEP 491: Synchronize Virtual Threads without > Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for > further details. > > In order to make the code review easier the changes have been split into the > following initial 4 commits: > > - Change

Re: RFR: 8343453: Modernize FloatingDecimal tests [v2]

> Simplify tests. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Remove test jdk/jdk/internal/math/ToString.java as well. - Changes: - all: https://git.openjdk.org/jdk/pull/21840/files - new: https://git.open

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>>

RFR: 8343071: Broken anchors to restricted method page and some redundant ids

Can I get a review for this patch that brings the last changes to fix broken anchors in the source code. The links updated in this patch can be grouped into 3 sections, they were minor so I grouped them into one PR. 1- Move some references from the old `foreign/package-summary.html#restricted`

Re: RFR: 8343453: Modernize FloatingDecimal tests

On Fri, 1 Nov 2024 18:01:18 GMT, Raffaello Giulietti wrote: > Simplify tests. See the JBS issue for details. - PR Comment: https://git.openjdk.org/jdk/pull/21840#issuecomment-2452338486

RFR: 8343453: Modernize FloatingDecimal tests

Simplify tests. - Commit messages: - Merge branch 'master' into 8343453 - 8343453: Modernize FloatingDecimal tests Changes: https://git.openjdk.org/jdk/pull/21840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21840&range=00 Issue: https://bugs.openjdk.org/browse/JDK-83

Re: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without JMODs [v42]

On Fri, 1 Nov 2024 01:26:44 GMT, Mandy Chung wrote: > I expect that the jmodless tests will first build an image (say `image1`) > using jlink `--generate-linkable-runtime` option and then verify > `image1/bin/jlink` that links from the run-time image. I don't see > `--generate-linkable-runtime

Re: RFR: 8341399: Add since checker tests to the langtools modules [v3]

> Can I get a review for this patch that adds `@since` checker tests to the > following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. > The initial test for `java.base` has been integrated in > [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). > > The jtreg comment

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>>

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15]

On Fri, 1 Nov 2024 15:52:50 GMT, Magnus Ihse Bursie wrote: > > Bug in macroAssembler_x86.cpp - should be _WINDOWS > > So what does that mean? That the code is currently broken and is incorrectly > included on Windows? If so, it should be fixed in a separate PR. Or is it > just a stylistic issu

Re: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without JMODs [v42]

On Thu, 31 Oct 2024 22:25:04 GMT, Mandy Chung wrote: > Many tests failed in compiling test library > `test/jdk/tools/lib/tests/JImageValidator.java` as it depends on the > ClassFile API and preview needs to be enabled. It looks like my environment issue. They all pass for me now. --

Re: RFR: 8336707: Contention of ForkJoinPool grows when stealing works [v14]

> This addresses tendencies in previous update to increase fencing, scanning, > and signalling that can increase contention, and slow down performance > especially on ARM platforms. It also uses more ARM-friendly constructions to > reduce overhead (leading to several changes that all of the same

Re: RFR: 8341399: Add since checker tests to the langtools modules [v2]

On Fri, 1 Nov 2024 15:51:10 GMT, Nizar Benalla wrote: >> Can I get a review for this patch that adds `@since` checker tests to the >> following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. >> The initial test for `java.base` has been integrated in >> [JDK-8331051](https://b

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names

On Fri, 1 Nov 2024 17:28:28 GMT, Chen Liang wrote: > Before 8338544, the binary/internal name validation was partial. It missed a > few validations performed by `skipOverFieldSignature`: no empty strings, > leading or trailing or consecutive separator chars. In 8338544, the empty > string vali

Re: RFR: 8341399: Add since checker tests to the langtools modules [v2]

On Fri, 1 Nov 2024 15:51:10 GMT, Nizar Benalla wrote: >> Can I get a review for this patch that adds `@since` checker tests to the >> following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. >> The initial test for `java.base` has been integrated in >> [JDK-8331051](https://b

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names

On Fri, 1 Nov 2024 13:58:01 GMT, Chen Liang wrote: > An oversight in the patch for > [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665 caused > `ClassDesc` to incorrectly accept empty strings as binary names, so erroneous > calls `ClassDesc.of("")` and `ClassDesc.ofInternalName

Re: RFR: 8343250: ArrayBlockingQueue serialization not thread safe

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote: > The ArrayBlockingQueue has had a readObject() method since Java 7, which > checks invariants of the deserialized object. However, it does not have a > writeObject() method. This means that the ArrayBlockingQueue could be > modified whilst it is

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9]

On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` >> launcher. It should behave like the normal, dynamically linked `java` >> launcher, except that all JDK native libraries should be statically, not >> dynamica

Re: RFR: 8343437: ClassDesc.of incorrectly permitting empty names

On Fri, 1 Nov 2024 13:58:01 GMT, Chen Liang wrote: > An oversight in the patch for > [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665 caused > `ClassDesc` to incorrectly accept empty strings as binary names. This patch > fixes that problem, and unifies the checks for package

Integrated: 8343236: Use @apiNote and @implSpec in j.util.Currency

On Wed, 30 Oct 2024 20:34:04 GMT, Justin Lu wrote: > Please review this PR which aims to improve the _j.util.Currency_ > specification by using `@apiNote` and `@implSpec`. > > A corresponding CSR has been filed. This pull request has now been integrated. Changeset: ea110c35 Author:Justin

Re: RFR: 8343236: Use @apiNote and @implSpec in j.util.Currency [v2]

On Thu, 31 Oct 2024 19:40:06 GMT, Justin Lu wrote: >> Please review this PR which aims to improve the _j.util.Currency_ >> specification by using `@apiNote` and `@implSpec`. >> >> A corresponding CSR has been filed. > > Justin Lu has updated the pull request incrementally with one additional >

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher [v7]

On Wed, 23 Oct 2024 08:23:34 GMT, Johan Vos wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Don't hardcode server variant > > I tried to build/run this on Linux as well (since I'm using parts of this PR > in

Re: RFR: 8341903: Implementation of Scoped Values (Fourth Preview) [v7]

On Fri, 1 Nov 2024 16:23:03 GMT, Andrew Haley wrote: >> The fourth preview of scoped values. > > Andrew Haley 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 reques

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9]

> As a prerequisite for Hermetic Java, we need a statically linked `java` > launcher. It should behave like the normal, dynamically linked `java` > launcher, except that all JDK native libraries should be statically, not > dynamically, linked. > > This patch is the first step towards this goal.

Re: RFR: 8342936: Enhance java.io.IO with parameter-less println() and readln() [v3]

On Tue, 29 Oct 2024 08:13:22 GMT, Jan Lahoda wrote: >> This PR is simply adding parameter-less `java.io.IO.{println(),readln()}`, >> with the (hopefully) obvious semantics, plus the corresponding wiring to >> make those work. This may become part of JEP 495: >> https://openjdk.org/jeps/495 > >

Re: RFR: 8335991: Implement Simple Source Files and Instance Main Methods (Fourth Preview)

On Wed, 30 Oct 2024 13:01:29 GMT, Jan Lahoda wrote: > This is a partial implementation of JEP 495 - adjustments of the JEP metadata > in `PreviewFeature`. There are no language changes associated with this JEP. > Changes to the `java.io.IO` class are covered by > https://github.com/openjdk/jdk

Re: RFR: 8341903: Implementation of Scoped Values (Fourth Preview) [v7]

> The fourth preview of scoped values. Andrew Haley 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 10 additional commits since the last revision: -

Re: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive

On Thu, 31 Oct 2024 07:15:16 GMT, Taizo Kurashige wrote: > To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use > Cygwin’s `df` to get the size for comparison if the test target drive is a > CD-ROM drive. > > As described in JDK-8343342, GetDiskSpaceInformationW can't g

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8]

On Tue, 29 Oct 2024 20:43:16 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` >> launcher. It should behave like the normal, dynamically linked `java` >> launcher, except that all JDK native libraries should be statically, not >> dynamic

Re: RFR: 8343250: ArrayBlockingQueue serialization not thread safe

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote: > The ArrayBlockingQueue has had a readObject() method since Java 7, which > checks invariants of the deserialized object. However, it does not have a > writeObject() method. This means that the ArrayBlockingQueue could be > modified whilst it is

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8]

On Tue, 29 Oct 2024 20:43:16 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` >> launcher. It should behave like the normal, dynamically linked `java` >> launcher, except that all JDK native libraries should be statically, not >> dynamic

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15]

On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov wrote: > `grep -i win32 -r src/hotspot/share/` shows several places missed in these > changes I'm actually not sure which places you refer to here. Can you be more specific? (Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 > Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. >> This port was [deprecated for removal in JDK >> 21](https://openjd

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15]

On Wed, 30 Oct 2024 19:37:47 GMT, Vladimir Kozlov wrote: > Bug in macroAssembler_x86.cpp - should be _WINDOWS So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both

Re: RFR: 8341399: Add since checker tests to the langtools modules [v2]

> Can I get a review for this patch that adds `@since` checker tests to the > following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. > The initial test for `java.base` has been integrated in > [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). > > The jtreg comment

Re: RFR: 8341399: Add since checker tests to the langtools modules [v2]

On Fri, 1 Nov 2024 15:36:59 GMT, Nizar Benalla wrote: >> test/jdk/tools/sincechecker/jdk_compiler/CheckSince_jdkCompiler.java line 27: >> >>> 25: * @test >>> 26: * @bug 8341399 >>> 27: * @summary Test for `@since` for java.base module >> >> You forgot to change the summaries but remembered t

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15]

On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Error in os_windows.cpp for unknown cpu > > `grep -i win32 -r src/hotspot/share/` shows several places missed

Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v16]

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 > Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. >> This port was [deprecated for removal in JDK >> 21](https://openjd

Re: RFR: 8341399: Add since checker tests to the langtools modules

On Fri, 1 Nov 2024 15:28:13 GMT, Chen Liang wrote: >> Can I get a review for this patch that adds `@since` checker tests to the >> following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. >> The initial test for `java.base` has been integrated in >> [JDK-8331051](https://bugs

Re: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205

On Fri, 1 Nov 2024 15:03:51 GMT, Adam Sotona wrote: > JDK-8339205 introduced multiple regressions in StackMapGenerator and added a > lot of new untested code. > > This patch reverts StackMapGenerator to the state before JDK-8339205 and adds > one regression test. > > Please review. > > Thank

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25]

On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code review easier the change

Re: RFR: 8341399: Add since checker tests to the langtools modules

On Wed, 16 Oct 2024 16:23:41 GMT, Nizar Benalla wrote: > Can I get a review for this patch that adds `@since` checker tests to the > following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. > The initial test for `java.base` has been integrated in > [JDK-8331051](https://bugs

Re: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205

On Fri, 1 Nov 2024 15:03:51 GMT, Adam Sotona wrote: > JDK-8339205 introduced multiple regressions in StackMapGenerator and added a > lot of new untested code. > > This patch reverts StackMapGenerator to the state before JDK-8339205 and adds > one regression test. > > Please review. > > Thank

Re: Using a standard bug report template and a definition of done

Hi Tom, Your interest seems to be more in the libraries area, so redirecting this conversation to core-lib-...@openjdk.java.net. There is quite a complete OpenJDK Developers Guide that describes the process and guidance. The OpenJDK Developers' Guide

RFR: 8343436: Regression in StackMapGenerator after JDK-8339205

JDK-8339205 introduced multiple regressions in StackMapGenerator and added a lot of new untested code. This patch reverts StackMapGenerator to the state before JDK-8339205 and adds one regression test. Please review. Thanks, Adam - Commit messages: - 8343436: Regression in Stack

Re: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205

On Fri, 1 Nov 2024 13:50:39 GMT, Adam Sotona wrote: > This patch fixes regression in StackMapGenerator caused by JDK-8339205 + > added test. > > Please review. > > Thanks, > Adam Now I noticed 8339205 added large untested surface full of bugs. I'm closing this PR and will open a new with reve

Re: RFR: 8343250: ArrayBlockingQueue serialization not thread safe

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote: > The ArrayBlockingQueue has had a readObject() method since Java 7, which > checks invariants of the deserialized object. However, it does not have a > writeObject() method. This means that the ArrayBlockingQueue could be > modified whilst it is

Re: RFR: 8343293: Remove the check for /jre/lib/libjava.dylib from the launcher's java_md_macosx.m [v2]

On Fri, 1 Nov 2024 14:36:39 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Roger's suggestion - introduce log message to match unix/windows > > src/java.base/macosx/native/libjli/java_md_macosx.m

Re: RFR: 8343293: Remove the check for /jre/lib/libjava.dylib from the launcher's java_md_macosx.m [v2]

> Can I please get a review of this change which cleans up a leftover code from > the launcher's java_md_macosx.m file? > > In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the > launcher code to remove checks for `/jre/lib/` when determining the > JDK installation root. Tho

Withdrawn: 8343436: Regression in StackMapGenerator after JDK-8339205

On Fri, 1 Nov 2024 13:50:39 GMT, Adam Sotona wrote: > This patch fixes regression in StackMapGenerator caused by JDK-8339205 + > added test. > > Please review. > > Thanks, > Adam This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/2

Re: RFR: 8343250: ArrayBlockingQueue serialization not thread safe

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote: > The ArrayBlockingQueue has had a readObject() method since Java 7, which > checks invariants of the deserialized object. However, it does not have a > writeObject() method. This means that the ArrayBlockingQueue could be > modified whilst it is

Re: RFR: 8343293: Remove the check for /jre/lib/libjava.dylib from the launcher's java_md_macosx.m

On Wed, 30 Oct 2024 14:27:03 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which cleans up a leftover code from > the launcher's java_md_macosx.m file? > > In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the > launcher code to remove checks for `/jre/

RFR: 8343436: Regression in StackMapGenerator after JDK-8339205

This patch fixes regression in StackMapGenerator caused by JDK-8339205 + added test. Please review. Thanks, Adam - Commit messages: - 8343436: Regression in StackMapGenerator after JDK-8339205 Changes: https://git.openjdk.org/jdk/pull/21828/files Webrev: https://webrevs.openjdk

Re: RFR: 8342979: Start of release updates for JDK 25 [v4]

> Prepare for JDK 25. Pavel Rappo 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 five additional commits since the last revision: - Update --release

Re: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205

On Fri, 1 Nov 2024 13:50:39 GMT, Adam Sotona wrote: > This patch fixes regression in StackMapGenerator caused by JDK-8339205 + > added test. > > Please review. > > Thanks, > Adam Seems we need to fix all the dup methods too. `checkStack` takes a usable max index instead of an exclusive end i

RFR: 8343437: ClassDesc.of incorrectly permitting empty names

An oversight in the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665 caused `ClassDesc` to incorrectly accept empty strings as binary names. This patch fixes that problem, and unifies the checks for package and class nominal descriptors. - Commit messag

  1   2   >