Re: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v2]

On Mon, 13 Jun 2022 19:55:47 GMT, Сергей Цыпанов wrote: >> If there are two threads calling `Executable.hasRealParameterData()` under >> race and the first one writes into volatile `Executable.parameters` field >> (doing _releasing store_) and the second thread reads non-null value from >>

Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]

On Thu, 16 Jun 2022 18:21:02 GMT, Alexander Matveev wrote: >> - Error will be thrown if app image is generated with another JDK version or >> has malformed .jpackage.xml. >> - Re-fixed as Alexey suggested in >>

Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v3]

> - Error will be thrown if app image is generated with another JDK version or > has malformed .jpackage.xml. > - Re-fixed as Alexey suggested in >

Re: RFR: 8286849: Use @Stable for generic repositories

On Tue, 17 May 2022 04:40:50 GMT, liach wrote: > Generic repositories, the implementation detail for generic information in > core reflection, can be updated to use the `@Stable` annotation to replace > their `volatile` access. Their existing accessor code is already safe, > reading the cache

Re: RFR: JDK-8288475: Initializing RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is installed

On Thu, 16 Jun 2022 17:43:19 GMT, Sean Mullan wrote: >> * This adds additional permissions to the jdk.random module >> (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`) >> * The annotations of the provider classes are now parsed early. >> This avoids putting the parts

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v30]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v29]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16

On Thu, 16 Jun 2022 22:21:23 GMT, Naoto Sato wrote: > This is a regression caused by the fix to > [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the > method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode > based on the comment "should not

Re: RFR: JDK-8288573: Make `java.lang.reflect.Executable::getParameterCount()' actually abstract

On Thu, 16 Jun 2022 21:21:36 GMT, Joe Darcy wrote: > Whatever the motivation for how this method was coded when added in JDK 8, > since Executable is now a sealed class with Constructor and Method the only > allowed subclasses, getParameterCount can be coded as an normal abstract > method.

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16

On Thu, 16 Jun 2022 22:21:23 GMT, Naoto Sato wrote: > This is a regression caused by the fix to > [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the > method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode > based on the comment "should not

RFR: 8288589: Files.readString ignores encoding errors for UTF-16

This is a regression caused by the fix to [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode based on the comment "should not happen". Possibly this refers to the `String(byte[], int, int,

Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]

On Thu, 16 Jun 2022 18:14:45 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 272: >> >>> 270: )); >>> 271: } >>> 272: >> >> 1. This is jpackage specific, so it should belong to JPackageCommand class. >> 2. Please use proper

Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]

On Thu, 16 Jun 2022 18:21:02 GMT, Alexander Matveev wrote: >> - Error will be thrown if app image is generated with another JDK version or >> has malformed .jpackage.xml. >> - Re-fixed as Alexey suggested in >>

Re: Integrated: 8288594: Address possibly lossy conversions in java.base FloatToDecimal

Ah, no, it's a P4 bug. Sorry for the noise On 2022-06-16 23:57, Raffaello Giulietti wrote: Although the conversion is mathematically sound and never lossy, this change should probably be backported to 19 as well. Greetings Raffaello On 2022-06-16 19:01, Adam Sotona wrote: On Thu, 16 Jun

Integrated: 8287401: jpackage tests failing on Windows due to powershell issue

On Thu, 16 Jun 2022 05:15:27 GMT, Alexey Semenyuk wrote: > Run a script extracting icons from executables as PowerShell command line > rather than a script This pull request has now been integrated. Changeset: c254c9d0 Author:Alexey Semenyuk URL:

Re: Integrated: 8288594: Address possibly lossy conversions in java.base FloatToDecimal

Although the conversion is mathematically sound and never lossy, this change should probably be backported to 19 as well. Greetings Raffaello On 2022-06-16 19:01, Adam Sotona wrote: On Thu, 16 Jun 2022 15:26:37 GMT, Adam Sotona wrote: One new case of possibly lossy conversions recently

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v25]

On Thu, 16 Jun 2022 08:21:49 GMT, ExE Boss wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/java/lang/reflect/Member.java line 92: > >> 90: * @implSpec

RFR: JDK-8288573: Make `java.lang.reflect.Executable::getParameterCount()' actually abstract

Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and

Re: RFR: 8287401: jpackage tests failing on Windows due to powershell issue

On Thu, 16 Jun 2022 05:15:27 GMT, Alexey Semenyuk wrote: > Run a script extracting icons from executables as PowerShell command line > rather than a script Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk19/pull/26

RFR: 8288628: Unnecessary Hashtable usage in ConditionalSpecialCasing

If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable. `ConditionalSpecialCasing.entryTable` is read-only Map which is modified only in `static` block. It means we can safely replace it with HashMap. - Commit messages: - [PATCH]

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v28]

On Thu, 16 Jun 2022 06:27:59 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]

On Tue, 14 Jun 2022 18:07:12 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8287971: Throw exception for missing values in .jpackage.xml [v2] > >

Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml [v2]

> - Error will be thrown if app image is generated with another JDK version or > has malformed .jpackage.xml. > - Re-fixed as Alexey suggested in >

Re: RFR: JDK-8288475: Initializing RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is installed

On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn wrote: > * This adds additional permissions to the jdk.random module > (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`) > * The annotations of the provider classes are now parsed early. > This avoids putting the parts that

Integrated: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX

On Sat, 23 Apr 2022 21:02:50 GMT, Andrey Turbanov wrote: > TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster. > Compared via JMH benchmark: 150ns -> 125ns/op > > Benchamark adapted from > http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java > > >

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v12]

> Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment

Integrated: 8288594: Address possibly lossy conversions in java.base FloatToDecimal

On Thu, 16 Jun 2022 15:26:37 GMT, Adam Sotona wrote: > One new case of possibly lossy conversions recently appeared in > jdk.internal.math.FloatToDecimal. > This patch avoids the warning by explicit cast from long to int. > > Please review. > > Thanks, > Adam This pull request has now been

Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]

On Thu, 16 Jun 2022 15:55:00 GMT, Xue-Lei Andrew Fan wrote: >> This is a follow up update per comments in [JDK-8287384 >>

Re: RFR: 8288594: Address possibly lossy conversions in java.base FloatToDecimal

On Thu, 16 Jun 2022 15:26:37 GMT, Adam Sotona wrote: > One new case of possibly lossy conversions recently appeared in > jdk.internal.math.FloatToDecimal. > This patch avoids the warning by explicit cast from long to int. > > Please review. > > Thanks, > Adam Marked as reviewed by rriggs

Integrated: 8288534: Out of bound errors for memory segment access mentions wrong values

On Wed, 15 Jun 2022 21:24:04 GMT, Maurizio Cimadamore wrote: > While playing with the API, I've realized that some of the out of bound error > messgaes come out incorrectly. > > This is because the bound check is performed as follows (to avoid overflow): > > > Objects.checkIndex(offset,

Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v9]

> This is a follow up update per comments in [JDK-8287384 > PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!O6EQBBr1eLb8OEbyuEwKMh9RY8w0cTN82qBpXMXBQJmWU4FI_-rzbvII5bv3Ipb-i52QkFD41RzdjGKH-huJd-w$ > ). The tier1 and tier2 test in open part looks good

RFR: 8288594: Address possibly lossy conversions in java.base FloatToDecimal

One new case of possibly lossy conversions recently appeared in jdk.internal.math.FloatToDecimal. This patch avoids the warning by explicit cast from long to int. Please review. Thanks, Adam - Commit messages: - 8288594: Address possibly lossy conversions in java.base

Re: RFR: 8288534: Out of bound errors for memory segment access mentions wrong values [v2]

On Thu, 16 Jun 2022 12:16:19 GMT, Maurizio Cimadamore wrote: >> While playing with the API, I've realized that some of the out of bound >> error messgaes come out incorrectly. >> >> This is because the bound check is performed as follows (to avoid overflow): >> >> >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v28]

On Thu, 16 Jun 2022 06:27:59 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v11]

> Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment

Re: Handling of USR2 signal in JVM on Linux

On Thu, Jun 16, 2022 at 8:17 AM David Holmes wrote: > On 16/06/2022 12:09 am, Thomas Stüfe wrote: > > On Wed 15. Jun 2022 at 15:06, David Holmes > > wrote: > > Nor do I. SIGUSR2 is reserved for use by the VM and we document > > that. If > > you start

Re: Handling of USR2 signal in JVM on Linux

On 16/06/2022 12:09 am, Thomas Stüfe wrote: On Wed 15. Jun 2022 at 15:06, David Holmes > wrote: On 15/06/2022 8:45 pm, Thomas Stüfe wrote: > More specifically, I propose to gracefully ignore SIGUSR2 in release > builds if the receiving thread is not

Re: RFR: 8288534: Out of bound errors for memory segment access mentions wrong values

On Wed, 15 Jun 2022 21:24:04 GMT, Maurizio Cimadamore wrote: > While playing with the API, I've realized that some of the out of bound error > messgaes come out incorrectly. > > This is because the bound check is performed as follows (to avoid overflow): > > > Objects.checkIndex(offset,

Re: RFR: 8288534: Out of bound errors for memory segment access mentions wrong values [v2]

> While playing with the API, I've realized that some of the out of bound error > messgaes come out incorrectly. > > This is because the bound check is performed as follows (to avoid overflow): > > > Objects.checkIndex(offset, this.length - length + 1); > > > So, if out-of-bounds access is

Integrated: Merge jdk19

On Thu, 16 Jun 2022 07:00:53 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 3d12c022 Author:Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/3d12c0225b31bb359bec70aac6befd879cd0c934 Stats: 254 lines

Re: RFR: 8288425: Footprint regression due MH creation when initializing StringConcatFactory

On Wed, 15 Jun 2022 22:43:55 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line >> 729: >> >>> 727: MethodHandle base = PREPEND_BASE; >>> 728: if (base == null) { >>> 729: base = PREPEND_BASE =

Re: RFR: 8288534: Out of bound errors for memory segment access mentions wrong values

On Wed, 15 Jun 2022 22:00:22 GMT, Paul Sandoz wrote: > I would expect passing an non-constant exception mapper should work. The C2 > intrinsic never accesses the exception mapper argument, and a range check > failure results in a deoptimzation back to the interpreter from which the >

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v25]

On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs

Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" test

RFR: JDK-8288475: Initializing RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is installed

* This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`) * The annotations of the provider classes are now parsed early. This avoids putting the parts that can trigger the parsing into an

RFR: Merge jdk19

Forwardport JDK 19 -> JDK 20 - Commit messages: - Merge - 8288533: Missing @param tags in com.sun.source classes - 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 - 8288414: Long::compress/expand samples are not correct - 8288289: Preview APIs in

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v28]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v27]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains