Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three
> additional commits since the last revision:
>
> - Fix another typo
> - Fix typo
> - Add more comments
src/hotspot/share/prims/nativeLookup.cpp line 275:
> 273:
> 274: // Otherwise call static method findNative in ClassLoader
> 275:
Suggestion:
src/hotspot/share/prims/nativeLookup.cpp line 419:
> 417: if (entry != nullptr) return entry;
> 418:
> 419:
Suggestion:
src/hotspot/share/prims/nativeLookup.cpp line 426:
> 424: return nullptr;
> 425: }
> 426: }
Suggestion:
}
src/java.base/share/classes/java/lang/Module.java line 331:
> 329: String modflag = isNamed() ? getName() : "ALL-UNNAMED";
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: System.err.printf("""
This message should probably be different when linking native methods, since
otherwise it’ll be:
WARNING: A restricted method in foo has been called
WARNING: bar has been called by Baz in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for callers in this
module
WARNING: Restricted methods will be blocked in a future release unless native
access is enabled
when it should really be something like:
WARNING: A JNI native method in foo has been linked
WARNING: bar has been linked in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for native methods
in this module
WARNING: Native methods will be blocked in a future release unless native
access is enabled
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248442
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248501
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248577
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599253428
Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v2]
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote: >> WIP >> >> This changeset contains hsdis for Windows/gcc Port. It supports both the >> binutils and capstone backends, though the LLVM backend is left out due to >> compatibility issues encountered during the build. Currently, which gcc >> distributions are supported is still to be clarified, as several, ranging >> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, >> the build system hack in place at the moment to compile the binutils backend >> on Windows is still left in place, for now. > > Julian Waters has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - Add check for compiler in configure > - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis Hmm, it seems Magnus isn't available at the moment. @erikj79 might you be able to answer my questions regarding hsdis? - PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2109049333
Re: RFR: 8329816: Add SLEEF version 3.6
On Mon, 13 May 2024 17:33:20 GMT, Mikael Vidstedt wrote: > Looks like that change is not yet in a released version of SLEEF, and in > particular not in 3.6. > > We do need updated approvals when we pick up new versions. Since we've gone > through the process once it's typically easier/faster to do so. It will be > technically easier/faster as well, now that I know how to do it and have > encoded it in the createSleef.sh script. Thanks, I see. As the version 3.6 will introduce some performance regression compared to non-intrinsic version, so to bring the fix into jdk, we need either do a manual change (like https://github.com/openjdk/jdk/pull/18605/commits/cd70f5a970514938d05f7a2426b15f78245236d3), or wait the next version after 3.6 (which should include changes in https://github.com/shibatch/sleef/pull/537), I think we prefer the latter (i.e. depends on next version after 3.6) That means https://github.com/openjdk/jdk/pull/18605 (JDK-8312425) requires sleef version next to 3.6 (could be 3.6.1 or 3.7). I'm OK to push this pr first, if it's also convenient for you, as we will need to push the change between 3.6.1/3.7 and 3.6 again when 3.6.1/3.7 is released. - PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2108788721
Re: RFR: 8329816: Add SLEEF version 3.6
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to > optimize vector math operations by leveraging the SLEEF library. For legal > reasons the actual contribution of the SLEEF files needs to be handled > separately. This enhancement adds the relevant files, enabling the rest of > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward. Marked as reviewed by mli (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19185#pullrequestreview-2053815054
Re: RFR: 8329816: Add SLEEF version 3.6
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to > optimize vector math operations by leveraging the SLEEF library. For legal > reasons the actual contribution of the SLEEF files needs to be handled > separately. This enhancement adds the relevant files, enabling the rest of > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward. Marked as reviewed by erikj (Reviewer). src/jdk.incubator.vector/linux/legal/sleef.md line 32: > 30: SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE > 31: FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR > OTHERWISE, > 32: ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > OTHER DEALINGS IN THE SOFTWARE. Is this missing line break a mistake or intended? - PR Review: https://git.openjdk.org/jdk/pull/19185#pullrequestreview-2053422578 PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1598883436
Re: RFR: 8329816: Add SLEEF version 3.6
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to > optimize vector math operations by leveraging the SLEEF library. For legal > reasons the actual contribution of the SLEEF files needs to be handled > separately. This enhancement adds the relevant files, enabling the rest of > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward. Looks like that change is not yet in a released version of SLEEF, and in particular not in 3.6. We do need updated approvals when we pick up new versions. Since we've gone through the process once it's typically easier/faster to do so. It will be technically easier/faster as well, now that I know how to do it and have encoded it in the createSleef.sh script. - PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2108363977
Integrated: 8332085: Remove 10 year old transition check in GenerateCurrencyData tool
On Fri, 10 May 2024 21:30:21 GMT, Naoto Sato wrote: > The build tool that generates the currency data had a check that throws an > exception (causes a build failure) if the transition date is more than 10 > years away (past/future). This caused a build failure in 8u-RI repository. > Since the risk of build failure seems to exceed the potential benefit (make > the data clean), removing the check is appropriate. This pull request has now been integrated. Changeset: 5ded8da6 Author:Naoto Sato URL: https://git.openjdk.org/jdk/commit/5ded8da676d62158d0011086d7f80ff2c9096e13 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8332085: Remove 10 year old transition check in GenerateCurrencyData tool Reviewed-by: erikj, iris Backport-of: 4f3b76ff496e7423e5c43ca62cef019e4f4292ec - PR: https://git.openjdk.org/jdk/pull/19183
Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v9]
On Fri, 10 May 2024 00:19:32 GMT, Volodymyr Paprotski wrote: >> Performance. Before: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt ScoreError Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256 >> thrpt3 6443.934 ± 6.491 ops/s >> SignatureBench.ECDSA.signSHA256withECDSA 16384 256 >> thrpt3 6152.979 ± 4.954 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA1024 256 >> thrpt3 1895.410 ± 36.979 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 >> thrpt3 1878.955 ± 45.487 ops/s >> Benchmark(algorithm) >> (keyLength) (kpgAlgorithm) (provider) Mode Cnt ScoreError Units >> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret ECDH >> 256 EC thrpt3 1357.810 ± 26.584 ops/s >> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret ECDH >> 256 EC thrpt3 1352.119 ± 23.547 ops/s >> Benchmark (isMontBench) Mode Cnt Score >> Error Units >> PolynomialP256Bench.benchMultiply false thrpt3 1746.126 ± >> 10.970 ops/s >> >> Performance, no intrinsic: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt Score Error Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256 >> thrpt3 6529.839 ± 42.420 ops/s >> SignatureBench.ECDSA.signSHA256withECDSA 16384 256 >> thrpt3 6199.747 ± 133.566 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA1024 256 >> thrpt3 1973.676 ± 54.071 ops/s >> SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 >> thrpt3 1932.127 ± 35.920 ops/s >> Benchmark(algorithm) >> (keyLength) (kpgAlgorithm) (provider) Mode Cnt ScoreError Units >> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret ECDH >> 256 EC thrpt3 1355.788 ± 29.858 ops/s >> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret ECDH >> 256 EC thrpt3 1346.523 ± 28.722 ops/s >> Benchmark (isMontBench) Mode Cnt Score >> Error Units >> PolynomialP256Bench.benchMultiply true thrpt3 1919.57... > > Volodymyr Paprotski has updated the pull request incrementally with one > additional commit since the last revision: > > whitespace The changes look good and have passed testing - Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18583#pullrequestreview-2053158639
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three
> additional commits since the last revision:
>
> - Fix another typo
> - Fix typo
> - Add more comments
src/hotspot/share/runtime/arguments.cpp line 2271:
> 2269: } else if (match_option(option, "--illegal-native-access=", ))
> {
> 2270: if (!create_module_property("jdk.module.illegal.native.access",
> tail, InternalProperty)) {
> 2271: return JNI_ENOMEM;
I think it would be helpful to get guidance on if this is the right way to add
this system property, only because this one not a "module property". The
configuration (WriteableProperty + InternalProperty) look right.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598673962
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with three > additional commits since the last revision: > > - Fix another typo > - Fix typo > - Add more comments Changes to jdk.net and jdk.sctp look ok. - PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107695217
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with three > additional commits since the last revision: > > - Fix another typo > - Fix typo > - Add more comments security changes (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`, and `jdk.security.auth`) look good. - PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107621474
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with three > additional commits since the last revision: > > - Fix another typo > - Fix typo > - Add more comments Build changes look good. - PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107563120
Re: RFR: 8332096: hotspot-ide-project fails with this-escape
On Fri, 10 May 2024 23:54:11 GMT, Alex Menkov wrote: > The change fixes `make hotspot-ide-project` which fails with > > \open\make\ide\visualstudio\hotspot\src\classes\build\tools\projectcreator\FileTreeCreator.java:54: > warning: [this-escape] possible 'this' escape before subclass is fully > initialized > attributes.push(new DirAttributes()); > ^ > error: warnings found and -Werror specified Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19186#pullrequestreview-2052671844
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting > the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now > considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted > methods, even for FFM API calls. In Java 22, the single > `--enable-native-access` was used both to specify a set of modules for which > native access should be allowed *and* to specify whether illegal native > access (that is, native access occurring from a module not specified by > `--enable-native-access`) should be treated as an error or a warning. More > specifically, an error is only issued if the `--enable-native-access flag` is > used at least once. > > Here, a new flag is introduced, namely > `illegal-native-access=allow/warn/deny`, which is used to specify what should > happen when access to a restricted method and/or functionality is found > outside the set of modules specified with `--enable-native-access`. The > default policy is `warn`, but users can select `allow` to suppress the > warnings, or `deny` to cause `IllegalCallerException` to be thrown. This > aligns the treatment of restricted methods with other mechanisms, such as > `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for > `java.lang.foreign`, to reflect the changes in the command line flags > described above. Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Fix another typo - Fix typo - Add more comments - Changes: - all: https://git.openjdk.org/jdk/pull/19213/files - new: https://git.openjdk.org/jdk/pull/19213/files/c4938dc7..bad10942 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19213=02 - incr: https://webrevs.openjdk.org/?repo=jdk=19213=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v2]
On Mon, 13 May 2024 11:38:40 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Avoid call to VM::isModuleSystemInited
> Use initial error stream
src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 124:
> 122: if (module != null) {
> 123: // not in init phase
> 124: Holder.JLA.ensureNativeAccess(module, owner, methodName,
> currentClass);
In an earlier iteration I had a call to `VM::isModuleSystemInited`, but I
discovered that caused a performance regression, since that method involves a
volatile access. Perhaps we should rethink that part of the init code to use
stable fields, but it's probably better done separately.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598328283
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v2]
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting > the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now > considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted > methods, even for FFM API calls. In Java 22, the single > `--enable-native-access` was used both to specify a set of modules for which > native access should be allowed *and* to specify whether illegal native > access (that is, native access occurring from a module not specified by > `--enable-native-access`) should be treated as an error or a warning. More > specifically, an error is only issued if the `--enable-native-access flag` is > used at least once. > > Here, a new flag is introduced, namely > `illegal-native-access=allow/warn/deny`, which is used to specify what should > happen when access to a restricted method and/or functionality is found > outside the set of modules specified with `--enable-native-access`. The > default policy is `warn`, but users can select `allow` to suppress the > warnings, or `deny` to cause `IllegalCallerException` to be thrown. This > aligns the treatment of restricted methods with other mechanisms, such as > `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for > `java.lang.foreign`, to reflect the changes in the command line flags > described above. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Avoid call to VM::isModuleSystemInited Use initial error stream - Changes: - all: https://git.openjdk.org/jdk/pull/19213/files - new: https://git.openjdk.org/jdk/pull/19213/files/d9fe9a71..c4938dc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19213=01 - incr: https://webrevs.openjdk.org/?repo=jdk=19213=00-01 Stats: 11 lines in 2 files changed: 3 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213
RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI
This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: * `System::load` and `System::loadLibrary` are now restricted methods * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. - Commit messages: - Initial push Changes: https://git.openjdk.org/jdk/pull/19213/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19213=00 Issue: https://bugs.openjdk.org/browse/JDK-8331671 Stats: 466 lines in 99 files changed: 301 ins; 53 del; 112 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI
On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore
wrote:
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now
> considered a restricted operation
>
> This PR slightly changes the way in which the JDK deals with restricted
> methods, even for FFM API calls. In Java 22, the single
> `--enable-native-access` was used both to specify a set of modules for which
> native access should be allowed *and* to specify whether illegal native
> access (that is, native access occurring from a module not specified by
> `--enable-native-access`) should be treated as an error or a warning. More
> specifically, an error is only issued if the `--enable-native-access flag` is
> used at least once.
>
> Here, a new flag is introduced, namely
> `illegal-native-access=allow/warn/deny`, which is used to specify what should
> happen when access to a restricted method and/or functionality is found
> outside the set of modules specified with `--enable-native-access`. The
> default policy is `warn`, but users can select `allow` to suppress the
> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
> aligns the treatment of restricted methods with other mechanisms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Javadoc:
https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/javadoc/api/index.html
Specdiff:
https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/specdiff_out/overview-summary.html
make/conf/module-loader-map.conf line 105:
> 103: java.smartcardio \
> 104: jdk.accessibility \
> 105: jdk.attach \
The list of allowed modules has been rewritten from scratch, by looking at the
set of modules containing at least one `native` method declaration.
src/hotspot/share/prims/nativeLookup.cpp line 277:
> 275:
> 276: Klass* klass = vmClasses::ClassLoader_klass();
> 277: Handle jni_class(THREAD, method->method_holder()->java_mirror());
This is the biggest change in this PR. That is, we need to pass enough
arguments to `ClassLoader::findNative` so that the method can start a
restricted check accordingly.
src/java.base/share/classes/java/lang/Module.java line 311:
> 309: Module target = moduleForNativeAccess();
> 310: ModuleBootstrap.IllegalNativeAccess illegalNativeAccess =
> ModuleBootstrap.illegalNativeAccess();
> 311: if (illegalNativeAccess !=
> ModuleBootstrap.IllegalNativeAccess.ALLOW &&
There are some changes in this code:
* this code is no-op if `--illegal-native-access` is set to `allow`
* we also attach the location of the problematic class to the warning message,
using `CodeSource`
* we use the "initial error stream" to emit the warning, similarly to what is
done for other runtime warnings
src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 115:
> 113: @ForceInline
> 114: public static void ensureNativeAccess(Class currentClass,
> Class owner, String methodName) {
> 115: if (VM.isModuleSystemInited()) {
If we call this code too early, we can see cases where `module` is `null`.
src/java.desktop/macosx/classes/com/apple/eio/FileManager.java line 61:
> 59: }
> 60:
> 61: @SuppressWarnings({"removal", "restricted"})
There are several of these changes. One option might have been to just disable
restricted warnings when building. But on a deeper look, I realized that in all
these places we already disabled deprecation warnings for the use of security
manager, so I also added a new suppression instead.
test/jdk/java/foreign/enablenativeaccess/panama_jni_load_module/module-info.java
line 24:
> 22: */
> 23:
> 24: module panama_jni_load_module {
This module setup is a bit convoluted, but I wanted to make sure that we got
separate warnings for `System.loadLibrary` and binding of the `native` method,
and that warning on the _use_ of the native method was not generated
(typically, all three operations occur in the same module).
-
PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107272261
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598269825
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598271285
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598274987
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598276455
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598277853
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598279827
Re: RFR: 8329816: Add SLEEF version 3.6
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
> separately. This enhancement adds the relevant files, enabling the rest of
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
Thanks for working on this.
Just one question, currently in `sleefinline_{advsimd,sve}.h` there is `#define
SLEEF_ALWAYS_INLINE inline`, but what expected is something like `#define
SLEEF_ALWAYS_INLINE inline __attribute__((always_inline))` (please check
https://github.com/shibatch/sleef/pull/537 for details). In the future, when we
change it, do we need to go through the legal process again? I guess we don't
need it, but just double check it.
-
PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2106818228
