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

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

On Fri, 17 Jun 2022 06:47:59 GMT, Jaikiran Pai 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 th

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

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. (Th

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

On Fri, 17 Jun 2022 06:14:32 GMT, liach wrote: >> src/java.base/share/classes/java/lang/reflect/Executable.java line 453: >> >>> 451: >>> 452: private transient boolean hasRealParameterData; >>> 453: private transient volatile Parameter[] parameters; >> >> These can probably be annotat

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

On Fri, 17 Jun 2022 05:34:25 GMT, ExE Boss wrote: >> Сергей Цыпанов has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8288327: Add clarifying comments > > src/java.base/share/classes/java/lang/reflect/Executable.java line 453: > >> 451:

Re: Handling of USR2 signal in JVM on Linux

> > > > > > > > I see your point. I dislike crashes, especially ones they can be > > > reliably triggered from outside. You never can be sure about the > > > security implications either. > > > > > > If you dislike ignoring the signal, and since the default action for > > > SIGUSR1+2 is process ter

Integrated: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec

On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman wrote: > JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change > GetVersion to return this version. > > test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that > JNI_VERSION_19 is returned. The native library i

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 >> the

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 >> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2

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 > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!O9EYpCECe4owBSx5Afed1_edIOYL5-MqdziwEb_3iNi3T8oFSoldnyr3Gbz

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 tha

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 happen"

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. (Th

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 happen"

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, Chars

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 XML

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 >> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2

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 20

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: https://git.openjdk.org/jdk19/commi

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 ap

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 Construct

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] Unnec

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 >> dis

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] > > src/jdk.jpackage/share/classes/jdk/jpacka

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 > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9098__;!!ACWV5N9M2RV99hQ!NgVdVIfGfiCL40KAsDby-Ir9nDaz-bobTPkIIqXNrWDeLTm0q-Z69dZ98EP

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 > > > @Warmup(iterati

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 compatibl

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 in

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 >> PR](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8907__;!!ACWV5N9M2RV99hQ!Je_bf2xNMQS8uv-Y4eVoH4-gQWybzceT5Pe4a5e2fcDHN_WXR-mzH7Mk6ojON_7YmuaXBCbKpPS38vT5n

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 (Rev

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, this

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 FloatToDecim

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): >> >> >> Objects.checkIndex(offse

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 >> dis

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 compatibl

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 th

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, this

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 de

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 = MethodHandles.dropArgu

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 > exception

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 >> dis

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 ObjectStreamClassCaching.testCach

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 `AccessController.doPrivileged()

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 jdk.jdi,