From weijun at openjdk.org  Sat Oct  1 15:02:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 1 Oct 2022 15:02:04 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <azol0p7osOA4BoEFm_2HZT1U9GmKrrF4_vMq3o35hVE=.7e936b3f-a0fa-41e8-bf82-66f977688fd8@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?
>
> This is correct.
> AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Thanks @prrace. And yes, git link is better.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From coffeys at openjdk.org  Mon Oct  3 10:30:54 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 3 Oct 2022 10:30:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Check for 0 security events

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/aed938d2..f8faecf4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=01-02

  Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Mon Oct  3 10:30:54 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 3 Oct 2022 10:30:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <j4k9R1AoIxafqLpYbXI7jAvBWX2S6BRsXGgLMyuH5_s=.f513dae6-42ac-4c83-b077-981c74779f4e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
 <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
 <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>
 <j4k9R1AoIxafqLpYbXI7jAvBWX2S6BRsXGgLMyuH5_s=.f513dae6-42ac-4c83-b077-981c74779f4e@github.com>
Message-ID: <k5OoMvRFJmm4EycfauwZe4YWDZFRGAiwqnH9i9miiQE=.cfbc2498-3e8f-432f-9a6a-4457c1188e94@github.com>

On Fri, 30 Sep 2022 19:32:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Thanks @egahlin  - maybe we can leave it at beginChunk setting then.
>> 
>> I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). 
>> 
>> This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. 
>> 
>> `ProtectionDomain ` is a very early class to initialize [1] (initPhase2)
>> 
>> Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps  [2] - the JMX thread starts after about 3 seconds of runtime.
>> 
>> Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test.
>> 
>> If JFR is on, then Security class is already being loaded, even without this patch [3]
>> 
>> [1]
>> 
>> 	at java.base/java.security.ProtectionDomain.<clinit>(ProtectionDomain.java:64)
>> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:316)
>> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:431)
>> 	at java.base/java.security.SecureClassLoader.<init>(SecureClassLoader.java:113)
>> 	at java.base/jdk.internal.loader.BuiltinClassLoader.<init>(BuiltinClassLoader.java:194)
>> 	at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.<init>(ClassLoaders.java:135)
>> 	at java.base/jdk.internal.loader.ClassLoaders.<clinit>(ClassLoaders.java:79)
>> 	at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120)
>> 	at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266)
>> 	at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
>> 	at java.base/java.lang.System.initPhase2(System.java:2214)
>> 
>> 
>> [2]
>> 
>> 	at java.base/java.security.Security.<clinit>(Security.java:73)
>> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93)
>> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90)
>> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
>> 	at java.base/sun.net.InetAddressCachePolicy.<clinit>(InetAddressCachePolicy.java:89)
>> 	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005)
>> 	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658)
>> 	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524)
>> 	at java.base/java.net.InetAddress.getByName(InetAddress.java:1413)
>> 	at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531)
>> 	at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317)
>> 
>> 
>> [3]
>> 
>> 
>> 	at java.base/java.security.Security.<clinit>(Security.java:73)
>> 	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
>> 	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
>> 	at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
>> 	at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
>> 	at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
>> 	at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
>> 	at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
>> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
>> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
>> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
>> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
>> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
>> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
>> 	at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
>> 	at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)
>
> When support for the SM is removed, the dependency on `AccessController.doPrivileged` will be removed and there may no longer be a JFR dependency on loading the `Security` class. So, it is ok for now, but a solution that doesn't depend on this might be better in the long run.

fair point. Worse case scenario is that we don't record security properties on start up. Not the case for now though. I've added some extra code to check for this in the test.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From djelinski at openjdk.org  Mon Oct  3 15:09:04 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 3 Oct 2022 15:09:04 GMT
Subject: RFR: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
Message-ID: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>

This PR reduces the execution time of ProxyAuthTest.

Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
After this change the test does not open a server socket when it is not necessary.

The test continues to pass.

-------------

Commit messages:
 - Speed up https ProxyAuthTest

Changes: https://git.openjdk.org/jdk/pull/10539/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10539&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8186765
  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10539.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10539/head:pull/10539

PR: https://git.openjdk.org/jdk/pull/10539

From dfuchs at openjdk.org  Mon Oct  3 15:49:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Oct 2022 15:49:21 GMT
Subject: RFR: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
In-Reply-To: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
References: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
Message-ID: <6dCGxxX8i1Ou5-dhUhDV2HjL8NPoI-5SY-qXVxnn2Og=.06394b27-fa3b-4055-9f5c-33111cdbef27@github.com>

On Mon, 3 Oct 2022 14:35:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR reduces the execution time of ProxyAuthTest.
> 
> Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
> After this change the test does not open a server socket when it is not necessary.
> 
> The test continues to pass.

IIUC the test attempts to connect through a proxy to a server. The proxy needs Basic authentication. There is a system property that will allow/restrict which authentication scheme can be used with a proxy, and the test is run with various settings of that property. If the property doesn't allow the Basic authentication scheme, then the connection through the proxy will not succeed, and the proxy will never forward the request to the server. 
So in the case where we expect that the client stack will reject the request (since the proxy wants Basic) there's no need to start the server - it will never receive any connection anyway.

This LGTM - but it might be good to have someone from security-dev chime in - I'm not too familiar with this SSLSocketTemplate class.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10539

From darcy at openjdk.org  Mon Oct  3 17:20:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:20:53 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
Message-ID: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>

On Fri, 30 Sep 2022 20:25:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Filed a few follow-up bugs:

JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella)
JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 17:25:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:25:30 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v6]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <_UYUckHSBcJizYd7JBVbr6evdOrHu9h2MopGUlzrLR8=.b5c6d747-800b-462b-a19a-73a0f5096e3e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update doc directory files.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/fbaf3d4c..6bf7bf61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04-05

  Stats: 38 lines in 4 files changed: 0 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 17:29:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:29:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update make directory.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/6bf7bf61..224ed7a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05-06

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 17:38:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:38:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
 <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
Message-ID: <w8oqOHIlJyGizESmriPdGYTsVqpLZya2cPRL-2FjHWE=.8730e026-5e1c-4b3f-9543-a8f3eb4a8c3c@github.com>

On Mon, 3 Oct 2022 17:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?
> 
> Filed a few follow-up bugs:
> 
> JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella) JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

And also filed

JDK-8294728: Update openjdk.java.net => openjdk.org in hotspot unit test docs

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From xuelei at openjdk.org  Mon Oct  3 19:39:01 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 3 Oct 2022 19:39:01 GMT
Subject: RFR: 8294734: Redundant override in AES implementation
Message-ID: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>

Hi,

May I have this simple code clean-up patch reviewed?

In the AES cipher implementation, the override of engineDoFinal() method in the following code is not necessary as it only calls super.  The throws descriptions are missed in the method description.  I may be better to remove this override implementation, rather than fix the method description.


    /**
     * Finalize crypto operation with ByteBuffers
     *
     * @param input the input ByteBuffer
     * @param output the output ByteBuffer
     *
     * @return output length
     * @throws ShortBufferException
     * @throws IllegalBlockSizeException
     * @throws BadPaddingException
     */
    protected int engineDoFinal(ByteBuffer input, ByteBuffer output)
        throws ShortBufferException, IllegalBlockSizeException,
        BadPaddingException {
        return super.engineDoFinal(input, output);
    }

``` 

Code clean-up, not new regression test added.

Thanks,
Xuelei

-------------

Commit messages:
 - 8294734: Redundant override in AES implementation

Changes: https://git.openjdk.org/jdk/pull/10545/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10545&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294734
  Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10545.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10545/head:pull/10545

PR: https://git.openjdk.org/jdk/pull/10545

From prr at openjdk.org  Mon Oct  3 20:08:19 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Oct 2022 20:08:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
Message-ID: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>

On Mon, 3 Oct 2022 17:29:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make directory.

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:

> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 35:  *
> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.

The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
At this point I'd prefer that this be updated to point to JDK 17, as in
https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
So it is a defined, known, compatible version.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 20:37:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:11 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy 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 11 additional commits since the last revision:

 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7a8d31f3...4055f1a6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/224ed7a0..4055f1a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06-07

  Stats: 5510 lines in 75 files changed: 3554 ins; 1669 del; 287 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 20:37:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
 <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
Message-ID: <hGRiPhKIV8XCNGN7oJ010i5zPMJJlaYU7XzaP-c0vjM=.dee8d1ca-3312-4540-9f43-879aeffe7431@github.com>

On Mon, 3 Oct 2022 20:04:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make directory.
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:
> 
>> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 35:  *
>> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.
> 
> The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
> At this point I'd prefer that this be updated to point to JDK 17, as in
> https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
> So it is a defined, known, compatible version.

Updated to refer to JDK 17 specifically.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From jpai at openjdk.org  Tue Oct  4 06:22:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Oct 2022 06:22:11 GMT
Subject: RFR: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
In-Reply-To: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
References: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
Message-ID: <5qd74b3Wnxir1ngFs6tWKK1cVgsy1ZsE3wrW7YZcKQk=.1708fe77-412f-4dd3-900d-09db102a51f3@github.com>

On Mon, 3 Oct 2022 14:35:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR reduces the execution time of ProxyAuthTest.
> 
> Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
> After this change the test does not open a server socket when it is not necessary.
> 
> The test continues to pass.

Marked as reviewed by jpai (Reviewer).

Thank you Daniel for that explanation. Having looked at the test, it wasn't clear to me what exactly was being done/tested there.

@djelinski, the change looks fine to me. Although we now default to a well known port to which perhaps something already might be listening on a host, based on what Daniel noted, the request will never make it to that target - so this change will not introduce any intermittent failures from what I can see.

The copyright year on that test file will need an update.

-------------

PR: https://git.openjdk.org/jdk/pull/10539

From djelinski at openjdk.org  Tue Oct  4 07:04:42 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 4 Oct 2022 07:04:42 GMT
Subject: RFR: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java [v2]
In-Reply-To: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
References: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
Message-ID: <mjHSjV1TQ33g-xoRzlUSYep3EBAWrMfR4lShG5Xp-Ck=.1951ff16-9a7c-4ab0-b446-be9929effe88@github.com>

> This PR reduces the execution time of ProxyAuthTest.
> 
> Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
> After this change the test does not open a server socket when it is not necessary.
> 
> The test continues to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10539/files
  - new: https://git.openjdk.org/jdk/pull/10539/files/a814b593..6caee832

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10539&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10539&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10539.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10539/head:pull/10539

PR: https://git.openjdk.org/jdk/pull/10539

From djelinski at openjdk.org  Tue Oct  4 07:10:12 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 4 Oct 2022 07:10:12 GMT
Subject: RFR: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java [v2]
In-Reply-To: <mjHSjV1TQ33g-xoRzlUSYep3EBAWrMfR4lShG5Xp-Ck=.1951ff16-9a7c-4ab0-b446-be9929effe88@github.com>
References: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
 <mjHSjV1TQ33g-xoRzlUSYep3EBAWrMfR4lShG5Xp-Ck=.1951ff16-9a7c-4ab0-b446-be9929effe88@github.com>
Message-ID: <2zP553MP32NhYkozqp6Z8tL_HODdkv9ovnsjDvQJH8E=.f06a4279-487e-46a6-ba24-5ccd2e05c9d8@github.com>

On Tue, 4 Oct 2022 07:04:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR reduces the execution time of ProxyAuthTest.
>> 
>> Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
>> After this change the test does not open a server socket when it is not necessary.
>> 
>> The test continues to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Thanks, copyright updated.
Also I'm going to remove JDK-8280104 here; the timeout was not the only issue there.

-------------

PR: https://git.openjdk.org/jdk/pull/10539

From jpai at openjdk.org  Tue Oct  4 07:16:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Oct 2022 07:16:09 GMT
Subject: RFR: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java [v2]
In-Reply-To: <mjHSjV1TQ33g-xoRzlUSYep3EBAWrMfR4lShG5Xp-Ck=.1951ff16-9a7c-4ab0-b446-be9929effe88@github.com>
References: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
 <mjHSjV1TQ33g-xoRzlUSYep3EBAWrMfR4lShG5Xp-Ck=.1951ff16-9a7c-4ab0-b446-be9929effe88@github.com>
Message-ID: <9ZzGMuh7YiKVuhrR_0nbT4A6hIy9hbvxfIad-zUSEHI=.284775e8-c19e-4fc5-8123-5ba0ffebb1bf@github.com>

On Tue, 4 Oct 2022 07:04:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR reduces the execution time of ProxyAuthTest.
>> 
>> Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
>> After this change the test does not open a server socket when it is not necessary.
>> 
>> The test continues to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10539

From dfuchs at openjdk.org  Tue Oct  4 14:06:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Oct 2022 14:06:24 GMT
Subject: RFR: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java [v2]
In-Reply-To: <mjHSjV1TQ33g-xoRzlUSYep3EBAWrMfR4lShG5Xp-Ck=.1951ff16-9a7c-4ab0-b446-be9929effe88@github.com>
References: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
 <mjHSjV1TQ33g-xoRzlUSYep3EBAWrMfR4lShG5Xp-Ck=.1951ff16-9a7c-4ab0-b446-be9929effe88@github.com>
Message-ID: <iwOro3IQa8ssUb_d69JhxxeuSEsGBu3nhCqBlilsZwc=.b90da89a-0c7f-468f-9335-4573b977fd8e@github.com>

On Tue, 4 Oct 2022 07:04:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR reduces the execution time of ProxyAuthTest.
>> 
>> Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
>> After this change the test does not open a server socket when it is not necessary.
>> 
>> The test continues to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10539

From weijun at openjdk.org  Tue Oct  4 15:22:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Oct 2022 15:22:12 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
Message-ID: <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>

On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 42:

> 40:      * before bug fix for JDK-8291974.
> 41:      */
> 42:     static String before = "rO0ABXNyAC9qYXZheC5zZWN1cml0eS5hdXRoLlByaXZhdGVDcmVkZW50aWFsUGVybWlzc2lvbklV3Hd7UH9MAgADWgAHdGVzdGluZ0wAD2NyZWRlbnRpYWxDbGFzc3QAEkxqYXZhL2xhbmcvU3RyaW5nO0wACnByaW5jaXBhbHN0AA9MamF2YS91dGlsL1NldDt4cgAYamF2YS5zZWN1cml0eS5QZXJtaXNzaW9uscbhPyhXUX4CAAFMAARuYW1lcQB+AAF4cHQAGWNyZWQxIHBjMSAicG4xIiBwYzIgInBuMiIAdAAFY3JlZDFw";

The line is a little too long. You can break it into multiple lines and use `Base64.getMimeDecoder()` to decode it.

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From valeriep at openjdk.org  Tue Oct  4 17:10:35 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 4 Oct 2022 17:10:35 GMT
Subject: RFR: 8294734: Redundant override in AES implementation
In-Reply-To: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>
References: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>
Message-ID: <Zsg0s9OutR2QE4Ke-Go3Xo7qOhuTrqIbTOW0gUuPqLs=.6dee5119-6d70-4ef4-aa36-0c3191440fcf@github.com>

On Mon, 3 Oct 2022 19:18:20 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this simple code clean-up patch reviewed?
> 
> In the AES cipher implementation, the override of engineDoFinal() method in the following code is not necessary as it only calls super.  The throws descriptions are missed in the method description.  I may be better to remove this override implementation, rather than fix the method description.
> 
> 
>     /**
>      * Finalize crypto operation with ByteBuffers
>      *
>      * @param input the input ByteBuffer
>      * @param output the output ByteBuffer
>      *
>      * @return output length
>      * @throws ShortBufferException
>      * @throws IllegalBlockSizeException
>      * @throws BadPaddingException
>      */
>     protected int engineDoFinal(ByteBuffer input, ByteBuffer output)
>         throws ShortBufferException, IllegalBlockSizeException,
>         BadPaddingException {
>         return super.engineDoFinal(input, output);
>     }
> 
> ``` 
> 
> Code clean-up, not new regression test added.
> 
> Thanks,
> Xuelei

Thanks for the clean up.

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10545

From xuelei at openjdk.org  Tue Oct  4 18:16:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 4 Oct 2022 18:16:28 GMT
Subject: RFR: 8294734: Redundant override in AES implementation
In-Reply-To: <Zsg0s9OutR2QE4Ke-Go3Xo7qOhuTrqIbTOW0gUuPqLs=.6dee5119-6d70-4ef4-aa36-0c3191440fcf@github.com>
References: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>
 <Zsg0s9OutR2QE4Ke-Go3Xo7qOhuTrqIbTOW0gUuPqLs=.6dee5119-6d70-4ef4-aa36-0c3191440fcf@github.com>
Message-ID: <Sfg1XrhEb2DXYdCxaDoPM-OB3c0dqzep_lcUPTxcOVo=.cb8bbcf7-d9f7-4bd0-bdeb-b2b047a033ae@github.com>

On Tue, 4 Oct 2022 17:06:53 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Thanks for the clean up.

Thank you for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/10545

From cjplummer at openjdk.org  Tue Oct  4 18:23:32 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Oct 2022 18:23:32 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
 <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
Message-ID: <CR61AGqmsFAARRtaenUEX9DJvp3BC5TknkAuUGNXr8w=.ba3ebdbf-056c-46b7-8762-3e6aff4f1edd@github.com>

On Wed, 28 Sep 2022 15:32:11 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> The title was edited by someone other than me, as you can see from the PR history.

The PR title needs to match the CR synopsis, so update the CR first, and then update the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From prr at openjdk.org  Tue Oct  4 18:42:44 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:42:44 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <sHOtl2OQ9-SEwkAbYNVq8gBaJMrW-my-5CBX2s1avkI=.8c95a200-f440-4e98-907f-2060e620c5b6@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/571e4932...4055f1a6

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From mpowers at openjdk.org  Tue Oct  4 19:08:22 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 4 Oct 2022 19:08:22 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>
Message-ID: <5Rna_JIQNqgziPyK8A4GlfKQU6ZNdp_8P2rFKzNQW7Y=.ae17720a-3b6a-49b1-8ffe-83f96a90322a@github.com>

On Tue, 4 Oct 2022 15:18:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added test
>
> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 42:
> 
>> 40:      * before bug fix for JDK-8291974.
>> 41:      */
>> 42:     static String before = "rO0ABXNyAC9qYXZheC5zZWN1cml0eS5hdXRoLlByaXZhdGVDcmVkZW50aWFsUGVybWlzc2lvbklV3Hd7UH9MAgADWgAHdGVzdGluZ0wAD2NyZWRlbnRpYWxDbGFzc3QAEkxqYXZhL2xhbmcvU3RyaW5nO0wACnByaW5jaXBhbHN0AA9MamF2YS91dGlsL1NldDt4cgAYamF2YS5zZWN1cml0eS5QZXJtaXNzaW9uscbhPyhXUX4CAAFMAARuYW1lcQB+AAF4cHQAGWNyZWQxIHBjMSAicG4xIiBwYzIgInBuMiIAdAAFY3JlZDFw";
> 
> The line is a little too long. You can break it into multiple lines and use `Base64.getMimeDecoder()` to decode it.

Or use string concatenation, e.g. "xxx" + "yyy".

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From mullan at openjdk.org  Tue Oct  4 19:30:34 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Oct 2022 19:30:34 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <5Rna_JIQNqgziPyK8A4GlfKQU6ZNdp_8P2rFKzNQW7Y=.ae17720a-3b6a-49b1-8ffe-83f96a90322a@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>
 <5Rna_JIQNqgziPyK8A4GlfKQU6ZNdp_8P2rFKzNQW7Y=.ae17720a-3b6a-49b1-8ffe-83f96a90322a@github.com>
Message-ID: <eNX23m1xSSFcwkVuFfZnjSOVYCkuH_Tq7x3-E4ccosQ=.4821679c-a3e7-483b-b3ab-fee231c3704e@github.com>

On Tue, 4 Oct 2022 19:06:18 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 42:
>> 
>>> 40:      * before bug fix for JDK-8291974.
>>> 41:      */
>>> 42:     static String before = "rO0ABXNyAC9qYXZheC5zZWN1cml0eS5hdXRoLlByaXZhdGVDcmVkZW50aWFsUGVybWlzc2lvbklV3Hd7UH9MAgADWgAHdGVzdGluZ0wAD2NyZWRlbnRpYWxDbGFzc3QAEkxqYXZhL2xhbmcvU3RyaW5nO0wACnByaW5jaXBhbHN0AA9MamF2YS91dGlsL1NldDt4cgAYamF2YS5zZWN1cml0eS5QZXJtaXNzaW9uscbhPyhXUX4CAAFMAARuYW1lcQB+AAF4cHQAGWNyZWQxIHBjMSAicG4xIiBwYzIgInBuMiIAdAAFY3JlZDFw";
>> 
>> The line is a little too long. You can break it into multiple lines and use `Base64.getMimeDecoder()` to decode it.
>
> Or use string concatenation, e.g. "xxx" + "yyy".

This looks like a good candidate for Text Blocks: https://openjdk.org/jeps/378

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From wetmore at openjdk.org  Tue Oct  4 19:34:34 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 4 Oct 2022 19:34:34 GMT
Subject: RFR: 8294734: Redundant override in AES implementation
In-Reply-To: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>
References: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>
Message-ID: <xbD3V21VAGdyezI-um96x4idz2noEqpqp2q-xD7L1KU=.0dc1ebdc-cc83-45ef-98d7-beeaeb6cab3e@github.com>

On Mon, 3 Oct 2022 19:18:20 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this simple code clean-up patch reviewed?
> 
> In the AES cipher implementation, the override of engineDoFinal() method in the following code is not necessary as it only calls super.  The throws descriptions are missed in the method description.  It may be better to remove this override implementation, rather than fix the method description.
> 
> 
>     /**
>      * Finalize crypto operation with ByteBuffers
>      *
>      * @param input the input ByteBuffer
>      * @param output the output ByteBuffer
>      *
>      * @return output length
>      * @throws ShortBufferException
>      * @throws IllegalBlockSizeException
>      * @throws BadPaddingException
>      */
>     protected int engineDoFinal(ByteBuffer input, ByteBuffer output)
>         throws ShortBufferException, IllegalBlockSizeException,
>         BadPaddingException {
>         return super.engineDoFinal(input, output);
>     }
> 
> ``` 
> 
> Code clean-up, not new regression test added.
> 
> Thanks,
> Xuelei

LGTM.  

I'm definitely guilty of not taking the time to beautify the method/exception description from the superclass.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10545

From xuelei at openjdk.org  Tue Oct  4 21:08:18 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 4 Oct 2022 21:08:18 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation
Message-ID: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>

Hi,

May I have this patch reviewed?

This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 

For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 37 multiplication.

For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 107 multiplication.

Here is the benchmark numbers before the patch applied:

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s


And the following are the benchmarking after the patch applied.

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1458.862 ?  4.615  ops/s
Signatures.sign              512  thrpt   15  1450.755 ? 12.954  ops/s
Signatures.sign             2048  thrpt   15  1460.395 ?  4.371  ops/s
Signatures.sign            16384  thrpt   15  1436.843 ?  4.420  ops/s



It looks like the performance improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.

Thanks,
Xuelei

-------------

Commit messages:
 - replace tab with whitrespaces
 - add field order impl
 - 8294731: Improve multiplicative inverse for EC implementation

Changes: https://git.openjdk.org/jdk/pull/10544/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294731
  Stats: 207 lines in 2 files changed: 205 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10544.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10544/head:pull/10544

PR: https://git.openjdk.org/jdk/pull/10544

From mpowers at openjdk.org  Tue Oct  4 22:01:16 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 4 Oct 2022 22:01:16 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <eNX23m1xSSFcwkVuFfZnjSOVYCkuH_Tq7x3-E4ccosQ=.4821679c-a3e7-483b-b3ab-fee231c3704e@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>
 <5Rna_JIQNqgziPyK8A4GlfKQU6ZNdp_8P2rFKzNQW7Y=.ae17720a-3b6a-49b1-8ffe-83f96a90322a@github.com>
 <eNX23m1xSSFcwkVuFfZnjSOVYCkuH_Tq7x3-E4ccosQ=.4821679c-a3e7-483b-b3ab-fee231c3704e@github.com>
Message-ID: <V5FXNmokIDGK41Qb5Ppdd6DtMJcHsfMOTNA73EqyrT8=.27a8801f-2098-422a-a2b9-6d93ac34a7c6@github.com>

On Tue, 4 Oct 2022 19:28:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Or use string concatenation, e.g. "xxx" + "yyy".
>
> This looks like a good candidate for Text Blocks: https://openjdk.org/jeps/378

String a = """
            xxx
            yyy
        """;


is not the same as


        String a =
            "xxx" +
            "yyy"
        ;

`a` contains an embedded newline; `b` does not.

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From duke at openjdk.org  Tue Oct  4 22:17:12 2022
From: duke at openjdk.org (Florent Guillaume)
Date: Tue, 4 Oct 2022 22:17:12 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <V5FXNmokIDGK41Qb5Ppdd6DtMJcHsfMOTNA73EqyrT8=.27a8801f-2098-422a-a2b9-6d93ac34a7c6@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>
 <5Rna_JIQNqgziPyK8A4GlfKQU6ZNdp_8P2rFKzNQW7Y=.ae17720a-3b6a-49b1-8ffe-83f96a90322a@github.com>
 <eNX23m1xSSFcwkVuFfZnjSOVYCkuH_Tq7x3-E4ccosQ=.4821679c-a3e7-483b-b3ab-fee231c3704e@github.com>
 <V5FXNmokIDGK41Qb5Ppdd6DtMJcHsfMOTNA73EqyrT8=.27a8801f-2098-422a-a2b9-6d93ac34a7c6@github.com>
Message-ID: <U1BX5YekgnUQJ-FzZcaE0CZkXonV0cHjhb19HbdZThU=.442f3589-5c2d-4ef6-932b-5196a4aac082@github.com>

On Tue, 4 Oct 2022 21:59:14 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> This looks like a good candidate for Text Blocks: https://openjdk.org/jeps/378
>
> String a = """
>             xxx
>             yyy
>         """;
> 
> 
> is not the same as
> 
> 
>         String a =
>             "xxx" +
>             "yyy"
>         ;
> 
> `a` contains an embedded newline; `b` does not.

@mcpowers the idea would be to use

    String a = """
            xxx\
            yyy\
        """;

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From weijun at openjdk.org  Tue Oct  4 23:24:17 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Oct 2022 23:24:17 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <U1BX5YekgnUQJ-FzZcaE0CZkXonV0cHjhb19HbdZThU=.442f3589-5c2d-4ef6-932b-5196a4aac082@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>
 <5Rna_JIQNqgziPyK8A4GlfKQU6ZNdp_8P2rFKzNQW7Y=.ae17720a-3b6a-49b1-8ffe-83f96a90322a@github.com>
 <eNX23m1xSSFcwkVuFfZnjSOVYCkuH_Tq7x3-E4ccosQ=.4821679c-a3e7-483b-b3ab-fee231c3704e@github.com>
 <V5FXNmokIDGK41Qb5Ppdd6DtMJcHsfMOTNA73EqyrT8=.27a8801f-2098-422a-a2b9-6d93ac34a7c6@github.com>
 <U1BX5YekgnUQJ-FzZcaE0CZkXonV0cHjhb19HbdZThU=.442f3589-5c2d-4ef6-932b-5196a4aac082@github.com>
Message-ID: <eIlQbUOe3RgiomaDvgrzFo9ysAHqjrr9frnW0htsiEo=.8cb8cbfa-7c51-41d5-b992-24d51161270a@github.com>

On Tue, 4 Oct 2022 22:13:35 GMT, Florent Guillaume <duke at openjdk.org> wrote:

>> String a = """
>>             xxx
>>             yyy
>>         """;
>> 
>> 
>> is not the same as
>> 
>> 
>>         String a =
>>             "xxx" +
>>             "yyy"
>>         ;
>> 
>> `a` contains an embedded newline; `b` does not.
>
> @mcpowers the idea would be to use
> 
>     String a = """
>             xxx\
>             yyy\
>         """;

Either is OK. That's why I proposed `getMimeDecoder` that will skip the newline characters.

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From mpowers at openjdk.org  Tue Oct  4 23:40:13 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 4 Oct 2022 23:40:13 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v2]
In-Reply-To: <eIlQbUOe3RgiomaDvgrzFo9ysAHqjrr9frnW0htsiEo=.8cb8cbfa-7c51-41d5-b992-24d51161270a@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <Sxp1P6N1SGUr_8Vfiuo5HdM_f2LtKipeTfTKrAZZWBg=.d7e516d3-45d1-4901-9189-0f0bd4691ccf@github.com>
 <0qBL3fZJl0X5ZyqxXX83Gfw3g8XZwPWEUN2OTgqbuVg=.472dcb8a-e7fc-4a92-afa6-b66c7085be59@github.com>
 <5Rna_JIQNqgziPyK8A4GlfKQU6ZNdp_8P2rFKzNQW7Y=.ae17720a-3b6a-49b1-8ffe-83f96a90322a@github.com>
 <eNX23m1xSSFcwkVuFfZnjSOVYCkuH_Tq7x3-E4ccosQ=.4821679c-a3e7-483b-b3ab-fee231c3704e@github.com>
 <V5FXNmokIDGK41Qb5Ppdd6DtMJcHsfMOTNA73EqyrT8=.27a8801f-2098-422a-a2b9-6d93ac34a7c6@github.com>
 <U1BX5YekgnUQJ-FzZcaE0CZkXonV0cHjhb19HbdZThU=.442f3589-5c2d-4ef6-932b-5196a4aac082@github.com>
 <eIlQbUOe3RgiomaDvgrzFo9ysAHqjrr9frnW0htsiEo=.8cb8cbfa-7c51-41d5-b992-24d51161270a@github.com>
Message-ID: <BMhZoy2QGZYc6iHUqTHNV3MBzqDy8gvLeY_tUusmQDw=.ef47a3cb-0150-4d94-85d1-5ac19c4dcdf9@github.com>

On Tue, 4 Oct 2022 23:20:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> @mcpowers the idea would be to use
>> 
>>     String a = """
>>             xxx\
>>             yyy\
>>         """;
>
> Either is OK. That's why I proposed `getMimeDecoder` that will skip the newline characters.

I'll go with Text Blocks and Florent's suggestion, but thanks for mentioning `getMimeDecoder`. I'm sure I'll find a use for it in the future.

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From mpowers at openjdk.org  Tue Oct  4 23:45:24 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 4 Oct 2022 23:45:24 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v3]
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <I2BsL98FtFc_Xo9AvKgcNgVJZ5rEi9iaqOfCGAob8VE=.a8f01d3f-130c-469f-adba-e006bd5f7360@github.com>

> https://bugs.openjdk.org/browse/JDK-8291974

Mark Powers has updated the pull request incrementally with two additional commits since the last revision:

 - Text Blocks
 - long line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10206/files
  - new: https://git.openjdk.org/jdk/pull/10206/files/a8e304d1..304134d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10206&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10206&range=01-02

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10206.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10206/head:pull/10206

PR: https://git.openjdk.org/jdk/pull/10206

From djelinski at openjdk.org  Wed Oct  5 06:50:30 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Oct 2022 06:50:30 GMT
Subject: Integrated: 8186765: Speed up test
 sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
In-Reply-To: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
References: <xYgzU2_jN1xunu6zZ0WuJBlsosIiy53HkCu-zQUCPCA=.38337509-3428-4d26-8041-d07041c29287@github.com>
Message-ID: <_f_DBPyZlP_ORxiTSR2eUdr3PMozcEDEinb8RTd3gpg=.0592044d-7096-49c7-a093-ddb480767035@github.com>

On Mon, 3 Oct 2022 14:35:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR reduces the execution time of ProxyAuthTest.
> 
> Before this change the test always required at least 3 minutes to complete (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
> After this change the test does not open a server socket when it is not necessary.
> 
> The test continues to pass.

This pull request has now been integrated.

Changeset: 43dbf589
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43dbf5899b455acf7c665d221564c4d4dff7dea4
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8186765: Speed up test sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10539

From ihse at openjdk.org  Wed Oct  5 07:43:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Oct 2022 07:43:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <VwPBSkgS79Le2mS0S-MK5Zsm49GZ3eIHj-M-yyHovZg=.219c7fcd-da16-4b54-b50f-6b203107fde2@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/72d7bf5d...4055f1a6

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From djelinski at openjdk.org  Wed Oct  5 13:03:51 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Oct 2022 13:03:51 GMT
Subject: RFR: 8294848: Unnecessary SSLCipher dispose implementations
Message-ID: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>

This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.

Invocations of [readCipher.dispose](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L118) and [disposeWriteCipher](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L191) come with a comment:

> Dispose of any intermediate state in the underlying cipher. For PKCS11 ciphers, this will release any attached sessions, and thus make finalization faster.
> Since MAC's doFinal() is called for every SSL/TLS packet, it's not necessary to do the same with MAC's.

Typical non-empty implementation of dispose is a call to cipher.doFinal, which internally releases PKCS11 native resources.

AEAD ciphers are similar to MAC - `doFinal()` is also called for every packet. They don't need another explicit `doFinal` call.

Tier1-3 tests clean. No new tests - this is clean up only.

-------------

Commit messages:
 - Remove unneeded doFinal calls

Changes: https://git.openjdk.org/jdk/pull/10574/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294848
  Stats: 88 lines in 1 file changed: 0 ins; 88 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10574.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10574/head:pull/10574

PR: https://git.openjdk.org/jdk/pull/10574

From aivanov at openjdk.org  Wed Oct  5 13:27:29 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 13:27:29 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Changes requested by aivanov (Reviewer).

src/hotspot/share/opto/memnode.cpp line 2365:

> 2363:   if (x != this)  return x;
> 2364: 
> 2365:   // Take apart the address into an oop and offset.

?and _an_ offset??

src/java.xml/share/classes/org/w3c/dom/Document.java line 293:

> 291:      * <code>systemId</code>, and <code>notationName</code> attributes are
> 292:      * copied. If a <code>deep</code> import is requested, the descendants
> 293:      * of the source <code>Entity</code> are recursively imported and

This class may come from a 3rd party library. Anyone from `java.xml` can confirm it?

test/hotspot/jtreg/vmTestbase/nsk/share/locks/DeadlockMaker.java line 31:

> 29: /*
> 30:  * Class used to create deadlocked threads. It is possible create 2 or more deadlocked thread, also
> 31:  * is possible to specify resource of which type should lock each deadlocked thread

Suggestion:

 * it is possible to specify resource of which type should lock each deadlocked thread

It doesn't sound right without _?it?_.

test/jdk/com/sun/jdi/connect/spi/GeneratedConnectors.java line 28:

> 26:  * @summary Unit test for "Pluggable Connectors and Transports" feature.
> 27:  *
> 28:  * When a transport service is deployed the virtual machine

Suggestion:

 * When a transport service is deployed, the virtual machine

Let's add a comma for clarity.

test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 445:

> 443: 
> 444:     /**
> 445:      * Check the status database for revocation information on one or more

Suggestion:

     * Check the status database for revocation information of one or more

test/jdk/sun/jvmstat/testlibrary/utils.sh line 181:

> 179:         if [ $? -eq 0 ]
> 180:         then
> 181:             # it's still lingering, now it is hard

Suggestion:

            # it's still lingering, now hit it hard

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From aivanov at openjdk.org  Wed Oct  5 14:17:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 14:17:13 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <VFoXow0glQ610il1bDU1a3KC6dP3S7cxr63T2tRJRZE=.46f798ba-af7c-4aea-9ca8-ce706658b5cc@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

I agree with everyone who said the PR should be broken to smaller pieces so that it touches code / tests in one or two packages, modules. It would be easier to review, you would need to get an approval from reviewers in a one or two specific areas. At this time, this PR touches files in 11 areas according the number of labels which correspond to a specific mailing list where discussions for the area are held.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From alanb at openjdk.org  Wed Oct  5 15:27:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 15:27:05 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread") from
 tests
Message-ID: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>

This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10577/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10577&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293810
  Stats: 52 lines in 6 files changed: 0 ins; 51 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10577.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10577/head:pull/10577

PR: https://git.openjdk.org/jdk/pull/10577

From aefimov at openjdk.org  Wed Oct  5 15:32:45 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 5 Oct 2022 15:32:45 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory
 filters to JNDI implementation
Message-ID: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>

### Summary of the change
This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 

These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.

The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.

Links:

- [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
- [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)

### List of code changes

- Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
- `java.security` and `module-info.java` files have been updated with a documentation for the new properties
- To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.

#### NamingManagerHelper changes
Changes performed to construct the `NamingManagerHelper` class:
- `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
- `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.


### Test changes
New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
- LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
- RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 

### Testing
tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
No failures observed for the modified regression tests.

-------------

Commit messages:
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

Changes: https://git.openjdk.org/jdk/pull/10578/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290368
  Stats: 1446 lines in 22 files changed: 1099 ins; 303 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From dfuchs at openjdk.org  Wed Oct  5 15:51:04 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Oct 2022 15:51:04 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <3kAWQXlRXyCRqCR-ocy_VaXCQls5ozpMLjGj0-Z4kH0=.674a358d-a544-449c-8d9d-b0a60a2f5a40@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

Changes to java.net and javax.management look fine to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10577

From mullan at openjdk.org  Wed Oct  5 16:35:19 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Oct 2022 16:35:19 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <jiHt2B8xjKmpyAYrlhu-PNEEjHyN0fZK03etrAJfkDY=.66486cb1-1776-4295-aa3c-b7aa9426b011@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10577

From darcy at openjdk.org  Wed Oct  5 16:39:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:39:32 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v9]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <T3sWlUnikg_EsuKqJ5PFiXj8IDAbk0fYG-WR3iLLvTw=.19912185-605f-4201-8022-0ffb7e00342d@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy 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 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8294618
 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8aa24fec...eba2bd4b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/4055f1a6..eba2bd4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07-08

  Stats: 1452 lines in 87 files changed: 912 ins; 312 del; 228 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Wed Oct  5 16:52:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:52:27 GMT
Subject: Integrated: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <vtc6z3XjCCr9yLV3usCQemL0opkJB2S_3H8IZGWwD_A=.7c03befe-b74b-48e0-ad2d-3594d6ebc1b5@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

This pull request has now been integrated.

Changeset: 536c9a51
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/536c9a512ea90d97a1ae5310453410d55db98bdd
Stats:     128 lines in 45 files changed: 0 ins; 0 del; 128 mod

8294618: Update openjdk.java.net => openjdk.org

Reviewed-by: mikael, iris, joehw, prr, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From xuelei at openjdk.org  Wed Oct  5 17:01:20 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 5 Oct 2022 17:01:20 GMT
Subject: RFR: 8294848: Unnecessary SSLCipher dispose implementations
In-Reply-To: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
References: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
Message-ID: <76jjKLIjjJ-3w7irGsqjK5Gb3txlwP2MpdaPP42P7Mg=.b8177e6b-a3e5-4052-bb00-b1bc073a1ad6@github.com>

On Wed, 5 Oct 2022 11:24:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.
> 
> Invocations of [readCipher.dispose](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L118) and [disposeWriteCipher](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L191) come with a comment:
> 
>> Dispose of any intermediate state in the underlying cipher. For PKCS11 ciphers, this will release any attached sessions, and thus make finalization faster.
>> Since MAC's doFinal() is called for every SSL/TLS packet, it's not necessary to do the same with MAC's.
> 
> Typical non-empty implementation of dispose is a call to cipher.doFinal, which internally releases PKCS11 native resources.
> 
> AEAD ciphers are similar to MAC - `doFinal()` is also called for every packet. They don't need another explicit `doFinal` call.
> 
> Tier1-3 tests clean. No new tests - this is clean up only.

Looks good to me.

Good catch!

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10574

From xuelei at openjdk.org  Wed Oct  5 17:21:57 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 5 Oct 2022 17:21:57 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine
Message-ID: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>

Hi,

May I have the code clean up reviewed?
 
There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 

Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.

This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.

Except that, I also cleaned up some code warnings from the IDE I used.

Thanks,
Xuelei

-------------

Commit messages:
 - update rcon
 - 8294821: Class load improvement for AES crypto engine

Changes: https://git.openjdk.org/jdk/pull/10568/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10568&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294821
  Stats: 1164 lines in 1 file changed: 952 ins; 203 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10568/head:pull/10568

PR: https://git.openjdk.org/jdk/pull/10568

From xuelei at openjdk.org  Wed Oct  5 17:30:24 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 5 Oct 2022 17:30:24 GMT
Subject: Integrated: 8294734: Redundant override in AES implementation
In-Reply-To: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>
References: <irazESxNsiO-u_rFpSP8Qe0U4dsCTkd_TEMzbgy2nWI=.172569f1-6813-4808-b6cd-d8ce8125fe3a@github.com>
Message-ID: <YqKqq5VDd9b_RVhAaCZIdcREpnomW7yrMfL-XAcs9fc=.cc1dcb0b-3c2a-4853-97eb-4242f211a6d9@github.com>

On Mon, 3 Oct 2022 19:18:20 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this simple code clean-up patch reviewed?
> 
> In the AES cipher implementation, the override of engineDoFinal() method in the following code is not necessary as it only calls super.  The throws descriptions are missed in the method description.  It may be better to remove this override implementation, rather than fix the method description.
> 
> 
>     /**
>      * Finalize crypto operation with ByteBuffers
>      *
>      * @param input the input ByteBuffer
>      * @param output the output ByteBuffer
>      *
>      * @return output length
>      * @throws ShortBufferException
>      * @throws IllegalBlockSizeException
>      * @throws BadPaddingException
>      */
>     protected int engineDoFinal(ByteBuffer input, ByteBuffer output)
>         throws ShortBufferException, IllegalBlockSizeException,
>         BadPaddingException {
>         return super.engineDoFinal(input, output);
>     }
> 
> ``` 
> 
> Code clean-up, not new regression test added.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: f2c57186
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2c57186a40bea4d5ad1c3ba010b59e552db624d
Stats:     18 lines in 1 file changed: 0 ins; 18 del; 0 mod

8294734: Redundant override in AES implementation

Reviewed-by: valeriep, wetmore

-------------

PR: https://git.openjdk.org/jdk/pull/10545

From xuelei at openjdk.org  Wed Oct  5 17:37:25 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 5 Oct 2022 17:37:25 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
Message-ID: <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>

> Hi,
> 
> May I have this patch reviewed?
> 
> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
> 
> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 37 multiplication.
> 
> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 94 multiplication.
> 
> Here is the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
> 
> 
> And the following are the benchmarking after the patch applied.
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1459.527 ? 10.160  ops/s
> Signatures.sign              512  thrpt   15  1450.707 ? 15.554  ops/s
> Signatures.sign             2048  thrpt   15  1453.490 ?  5.362  ops/s
> Signatures.sign            16384  thrpt   15  1437.364 ?  8.291  ops/s
> 
> 
> It looks like the performance improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
> 
> Enhancement for other curves will be considered in separate pull requests.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  more performance improvement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10544/files
  - new: https://git.openjdk.org/jdk/pull/10544/files/1da02c5e..b9bf0269

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10544&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10544&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10544.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10544/head:pull/10544

PR: https://git.openjdk.org/jdk/pull/10544

From dfuchs at openjdk.org  Wed Oct  5 17:48:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Oct 2022 17:48:20 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine
In-Reply-To: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
Message-ID: <jJ-O6p4H0aAhmVCvu4sKD2Mj5cqedYWP_LAXdc8cKMg=.47cb6e23-c5c8-4869-961e-14af2e938a8a@github.com>

On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the code clean up reviewed?
>  
> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
> 
> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
> 
> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
> 
> Except that, I also cleaned up some code warnings from the IDE I used.
> 
> Thanks,
> Xuelei

I wonder if it would be worthwhile to have a static method that could be called in an assert (or in a test using --patch-module) to verify that the various statically initialized arrays are the same than those that would have been computed by the old code?

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From xuelei at openjdk.org  Wed Oct  5 18:05:22 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 5 Oct 2022 18:05:22 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine
In-Reply-To: <jJ-O6p4H0aAhmVCvu4sKD2Mj5cqedYWP_LAXdc8cKMg=.47cb6e23-c5c8-4869-961e-14af2e938a8a@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <jJ-O6p4H0aAhmVCvu4sKD2Mj5cqedYWP_LAXdc8cKMg=.47cb6e23-c5c8-4869-961e-14af2e938a8a@github.com>
Message-ID: <__Y5OzD8cGZNoSK03Wo4vZ68YWboXsduJUfOItxHjvM=.a507c846-df99-48ee-bf2e-17566862af84@github.com>

On Wed, 5 Oct 2022 17:44:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I wonder if it would be worthwhile to have a static method that could be called in an assert (or in a test using --patch-module) to verify that the various statically initialized arrays are the same than those that would have been computed by the old code?

I did think about the same idea, by putting the code into test codebase or generate the tables with makefile configuration.   Actually, I had the table generation code in my local workspace.  However, I give it up at last because such kind of code is just used one time and may not worthy the resources to maintain it or the power to run it while building/testing.  None of the tables could be wrong, otherwise the algorithm will not work.  The regression test and inter-op testing may be sufficient to approve that the tables are good.

But please let me know, if you have a strong preference to have it, I will try to integrate the table generation code.

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From mchung at openjdk.org  Wed Oct  5 18:42:25 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Oct 2022 18:42:25 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <83iSGxB9O0_LEGHtSUf0AsrmJohOpOfVgI8ZpCs-NxQ=.1bc56ba2-eecd-492a-8d58-d2fed72a4f76@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10577

From valeriep at openjdk.org  Wed Oct  5 22:13:42 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Oct 2022 22:13:42 GMT
Subject: RFR: 8294848: Unnecessary SSLCipher dispose implementations
In-Reply-To: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
References: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
Message-ID: <IIG2P2GzeCb3woHEIZbKmO0h5gpuv3uLKqLc9_JAh8U=.55a9d1c3-c448-4397-bd52-a38034f16a5a@github.com>

On Wed, 5 Oct 2022 11:24:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.
> 
> Invocations of [readCipher.dispose](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L118) and [disposeWriteCipher](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L191) come with a comment:
> 
>> Dispose of any intermediate state in the underlying cipher. For PKCS11 ciphers, this will release any attached sessions, and thus make finalization faster.
>> Since MAC's doFinal() is called for every SSL/TLS packet, it's not necessary to do the same with MAC's.
> 
> Typical non-empty implementation of dispose is a call to cipher.doFinal, which internally releases PKCS11 native resources.
> 
> AEAD ciphers are similar to MAC - `doFinal()` is also called for every packet. They don't need another explicit `doFinal` call.
> 
> Tier1-3 tests clean. No new tests - this is clean up only.

Marked as reviewed by valeriep (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10574

From dfuchs at openjdk.org  Thu Oct  6 10:36:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Oct 2022 10:36:24 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine
In-Reply-To: <__Y5OzD8cGZNoSK03Wo4vZ68YWboXsduJUfOItxHjvM=.a507c846-df99-48ee-bf2e-17566862af84@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <jJ-O6p4H0aAhmVCvu4sKD2Mj5cqedYWP_LAXdc8cKMg=.47cb6e23-c5c8-4869-961e-14af2e938a8a@github.com>
 <__Y5OzD8cGZNoSK03Wo4vZ68YWboXsduJUfOItxHjvM=.a507c846-df99-48ee-bf2e-17566862af84@github.com>
Message-ID: <BMz47lUZgxas7MzP62aWC0ZGP51R_iM_8L4BQobSaJs=.61506151-f89a-400d-b857-892e5ee1847c@github.com>

On Wed, 5 Oct 2022 18:03:09 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> But please let me know, if you have a strong preference to have it, I will try to integrate the table generation code.

Your explanation sounds reasonable to me. I will leave it to security-libs reviewers and maintainers to make the call.

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From dfuchs at openjdk.org  Thu Oct  6 11:22:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Oct 2022 11:22:20 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <O8EDWJ0ksKUKoE72THDCaNbw0MNpkTHPgoonYpRFA2k=.8f1638af-b667-4805-a5f9-a9781f7c69ad@github.com>

On Wed, 5 Oct 2022 15:23:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Marked as reviewed by dfuchs (Reviewer).

I am glad to see this RFE. It looks like a big change but most of it is actually reorganisation of internal code, so thanks for explaining its making off :-) It helps a lot for the review.  I have looked at the code and I believe it looks good. I don't see any alternative to the reorganisation that could make the changes smaller - so I'm OK with the proposed solution. Thanks for documenting the new properties in their respective module info, as well as in the security properties file.

I had only a cursory look at the tests but they seem comprehensive. Good work.

I am approving on the condition to make sure that all JNDI tests (as well as tier1, tier2, tier3) are run before integrating.

Also please get an approval from a security-libs maintainer for the changes to the security properties file before integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From chegar at openjdk.org  Thu Oct  6 11:46:18 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Thu, 6 Oct 2022 11:46:18 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <Hfnu4n_J8gncUt_HBO8L8uPVRIRc18Jp3CX_VU1Jmko=.b2d9ee11-3034-40e0-bcdd-1a950f1683e3@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

LGTM

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10577

From mpowers at openjdk.org  Thu Oct  6 16:13:18 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 6 Oct 2022 16:13:18 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
Message-ID: <iTcwECu6GpkWk-DsmBEPPck05vvvAZjDSWTab967844=.b421d673-5b85-41d8-81ef-546065e34397@github.com>

On Wed, 5 Oct 2022 17:37:25 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 37 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 94 multiplication.
>> 
>> Here is the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1459.527 ? 10.160  ops/s
>> Signatures.sign              512  thrpt   15  1450.707 ? 15.554  ops/s
>> Signatures.sign             2048  thrpt   15  1453.490 ?  5.362  ops/s
>> Signatures.sign            16384  thrpt   15  1437.364 ?  8.291  ops/s
>> 
>> 
>> It looks like the performance improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more performance improvement

It seems to me the scalar multiplication enhancement should be done first, or maybe integrated with this fix.
Do you have a bug number for the scalar multiplication enhancement?

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From rriggs at openjdk.org  Thu Oct  6 16:30:22 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Oct 2022 16:30:22 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>

On Wed, 5 Oct 2022 15:23:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Nice work, but a few comments.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 91:

> 89:     }
> 90: 
> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {

This construct in which the supplied lambda fills in the serialClass is pretty obscure. 
Perhaps the variable name can be "serialClass" to match the only non-default method in ObjectInputFilter would give a better hint.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 92:

> 90: 
> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {
> 92:         Status result = switch(scheme) {

The handling of the selection of the filter could be more direct.
You can change the argument to checkInput to be ObjectInputFilter and pass the desired filter; LDAP_FILTER, RMI_FITLER, or GLOBAL_FILTER.
And make the check of the GLOBAL_FILTER conditional on it not having already been evaluated.
Then it will be the case that there must always be a specific filter.

The callers are all local to the class and would change to pass the desired filter.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 173:

> 171:                                            DEFAULT_GLOBAL_SP_VALUE));
> 172: 
> 173:     // A system-wide LDAP specific object factories filter constructed from the system

Where does the IllegalArgumentException from ObjectInputFilter.create get handled or reported?
If the property value is illformed, the error should be enough to diagnose and correct the property.

test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java line 46:

> 44:  * @build LDAPServer LDAPTestUtils TestFactory
> 45:  *
> 46:  * @run main/othervm LdapFactoriesFilterTest false

Are any of these filter property cases, malformed and would produce an error from ObjectInputFilter.create?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From mullan at openjdk.org  Thu Oct  6 17:25:25 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Oct 2022 17:25:25 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <LBmZPtn1wTQZx2KBRmnRMugEcvp0VOEAr1-Feg4Meqc=.f0c6e19d-d9af-4f9f-8390-7eb4b788acfc@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

Marked as reviewed by mullan (Reviewer).

src/java.base/share/classes/jdk/internal/access/JavaSecurityAccess.java line 32:

> 30: import java.security.PrivilegedAction;
> 31: import java.security.ProtectionDomain;
> 32: import java.util.Properties;

Update copyright on this file.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From xuelei at openjdk.org  Thu Oct  6 18:37:08 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 6 Oct 2022 18:37:08 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <iTcwECu6GpkWk-DsmBEPPck05vvvAZjDSWTab967844=.b421d673-5b85-41d8-81ef-546065e34397@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <iTcwECu6GpkWk-DsmBEPPck05vvvAZjDSWTab967844=.b421d673-5b85-41d8-81ef-546065e34397@github.com>
Message-ID: <IaNa2DGvxDuBFbWr1d2SR3kREdwNDV_vjwzXSrE1Fv4=.84d4385b-18ce-4712-a298-f11373cf17f4@github.com>

On Thu, 6 Oct 2022 16:11:17 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> It seems to me the scalar multiplication enhancement should be done first, or maybe integrated with this fix. Do you have a bug number for the scalar multiplication enhancement?

I did not file the scalar multiplication enhancement in JBS yet.  There are a few places that could be improved for the EC performance.  However, the update is big if having them all in one PR.  In order to simplify the code review and implementation, I would like to break it down into small enhancements.  I filed an [umbrella RFE](https://bugs.openjdk.org/browse/JDK-8294188) for the performance improvement in EC.  The goal to make the common EC crypto operations (key generation/exchange/signature) 3+ times faster, and make the TLS connections 20%+ faster .  

I may have to wait for a few more weeks so that I can come up with the scalar multiplication pull request.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From djelinski at openjdk.org  Thu Oct  6 19:11:52 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 6 Oct 2022 19:11:52 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 TLS server
Message-ID: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>

C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.

Verified that:
- SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
- The same server continues to function correctly
- Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
- new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass

-------------

Commit messages:
 - Update copyright dates
 - Fix file attributes
 - Fix key handling, add tests
 - Fix memory leak in key derivation

Changes: https://git.openjdk.org/jdk/pull/10594/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10594&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294906
  Stats: 113 lines in 5 files changed: 102 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10594.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10594/head:pull/10594

PR: https://git.openjdk.org/jdk/pull/10594

From djelinski at openjdk.org  Thu Oct  6 19:13:41 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 6 Oct 2022 19:13:41 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
Message-ID: <N01lcvgr-pcTuLWWcdC7vY8SfbZv-joC9K05aeFSKJA=.70402d11-b201-4a33-aaf3-f93fd8b5fe69@github.com>

On Wed, 5 Oct 2022 17:37:25 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 37 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 94 multiplication.
>> 
>> Here is the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1459.527 ? 10.160  ops/s
>> Signatures.sign              512  thrpt   15  1450.707 ? 15.554  ops/s
>> Signatures.sign             2048  thrpt   15  1453.490 ?  5.362  ops/s
>> Signatures.sign            16384  thrpt   15  1437.364 ?  8.291  ops/s
>> 
>> 
>> It looks like the performance improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more performance improvement

src/java.base/share/classes/sun/security/util/math/IntegerModuloP.java line 316:

> 314:                 // calculate imp ^ (2^16 - 1)
> 315:                 MutableIntegerModuloP t = imp.mutable();
> 316:                 for (int i = 15; i != 0; i--) {

Fun!

You can further reduce the number of multiplications:
t3 = t^2 * t
t15 = t3 ^ 4 * t3
t255 = t15^16 * t15
t65535 = t255^256 * t255
only four multiplications to get t^(2^16 - 1)

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From djelinski at openjdk.org  Thu Oct  6 19:37:28 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 6 Oct 2022 19:37:28 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
Message-ID: <tIewcVMCIM1UYorWL7uMqrLzOODoXBveOkt4uQN4Gdw=.903a5bfa-e6de-49c7-9676-a0e4d74e9f0b@github.com>

On Wed, 5 Oct 2022 17:37:25 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 37 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 94 multiplication.
>> 
>> Here is the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1459.527 ? 10.160  ops/s
>> Signatures.sign              512  thrpt   15  1450.707 ? 15.554  ops/s
>> Signatures.sign             2048  thrpt   15  1453.490 ?  5.362  ops/s
>> Signatures.sign            16384  thrpt   15  1437.364 ?  8.291  ops/s
>> 
>> 
>> It looks like the performance improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more performance improvement

could you also try using precomputed powers of t between 0-15? similar to what we do in [ECOperations.multiply](https://github.com/openjdk/jdk/blob/2ae8e3118385bdf93c50bca550334734b69bc2b6/src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java#L231) (see `pointMultiples`). This will also improve the number of multiplications.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From valeriep at openjdk.org  Thu Oct  6 22:12:28 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 6 Oct 2022 22:12:28 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 TLS server
In-Reply-To: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
Message-ID: <xyXQesfyrbN9gr4KHeKXAmuSNhcQW_rIyAxqB2I0mFQ=.1c9e78ab-cd20-4bf7-9e0c-398e64062b18@github.com>

On Thu, 6 Oct 2022 13:27:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
> 
> Verified that:
> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
> - The same server continues to function correctly
> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass

I will take a look, thanks~

-------------

PR: https://git.openjdk.org/jdk/pull/10594

From mpowers at openjdk.org  Thu Oct  6 22:47:23 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 6 Oct 2022 22:47:23 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 TLS server
In-Reply-To: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
Message-ID: <sNnEOoB4lMSw5wS_ib-8Xrialz26vyFmDioCJvmgl0c=.ecc64c56-6505-4695-b093-00c782ac7d9b@github.com>

On Thu, 6 Oct 2022 13:27:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
> 
> Verified that:
> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
> - The same server continues to function correctly
> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass

Would this fix cause problems for non-NSS providers when trying to destroy a mac key that was never allocated? Or does `C_DestroyObject` silently return if there's nothing to destroy?

-------------

PR: https://git.openjdk.org/jdk/pull/10594

From alanb at openjdk.org  Fri Oct  7 06:19:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 06:19:32 GMT
Subject: Integrated: 8293810: Remove granting of
 RuntimePermission("stopThread") from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <s5gfCl3wJO7dcqmUrPBoxSeEIAyNIJIvLUYpdTBq8Cw=.de27381b-1ff5-48ec-8ac4-5e77aedab2f4@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

This pull request has now been integrated.

Changeset: 0ad6803a
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ad6803ac2bba063d15ce8284a09da36b4cced81
Stats:     52 lines in 6 files changed: 0 ins; 51 del; 1 mod

8293810: Remove granting of RuntimePermission("stopThread") from tests

Reviewed-by: dfuchs, mullan, mchung, chegar

-------------

PR: https://git.openjdk.org/jdk/pull/10577

From djelinski at openjdk.org  Fri Oct  7 07:27:23 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Oct 2022 07:27:23 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 TLS server
In-Reply-To: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
Message-ID: <7crD1dEwoDARtlqM0XW5KtrcQVLExGNC3iS7bpeVUCI=.69224877-7f34-4913-9cbc-05c7f33eae81@github.com>

On Thu, 6 Oct 2022 13:27:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
> 
> Verified that:
> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
> - The same server continues to function correctly
> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass

I don't know if other providers allocate mac keys here or not; NSS is the only provider I could test.
NSS's `C_DestroyObject` fails when asked to destroy invalid object.

[The spec](https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/cs01/pkcs11-spec-v3.1-cs01.html#_Toc111203671) says:
> The two MACing keys ("client_write_MAC_secret" and "server_write_MAC_secret") (if present) [..]

which suggests that the keys may be absent; it does not define how we can check if keys were generated, but it does declare that zero (`CK_INVALID_HANDLE`) is never a valid object handle. I'll add a check for zero.

-------------

PR: https://git.openjdk.org/jdk/pull/10594

From djelinski at openjdk.org  Fri Oct  7 07:42:25 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Oct 2022 07:42:25 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 TLS server [v2]
In-Reply-To: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
Message-ID: <tZxcN3YPjglppTld3-iwPoqyr4Bxf_XGcLMoUJsHPk0=.fb4b824b-3ba0-4dce-863c-90fe9a34a562@github.com>

> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
> 
> Verified that:
> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
> - The same server continues to function correctly
> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Check if mac keys are present

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10594/files
  - new: https://git.openjdk.org/jdk/pull/10594/files/66f529ae..fdbe559f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10594&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10594&range=00-01

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10594.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10594/head:pull/10594

PR: https://git.openjdk.org/jdk/pull/10594

From duke at openjdk.org  Fri Oct  7 12:33:18 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 7 Oct 2022 12:33:18 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
Message-ID: <R930zxL3Hd0L16K44AtiuAXDkLK9ynpoI3sb2M32T9k=.7f8ca745-5939-4f04-a489-adc6dec7a4e7@github.com>

On Wed, 5 Oct 2022 17:37:25 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 37 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 94 multiplication.
>> 
>> Here is the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1459.527 ? 10.160  ops/s
>> Signatures.sign              512  thrpt   15  1450.707 ? 15.554  ops/s
>> Signatures.sign             2048  thrpt   15  1453.490 ?  5.362  ops/s
>> Signatures.sign            16384  thrpt   15  1437.364 ?  8.291  ops/s
>> 
>> 
>> It looks like the performance improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more performance improvement

According to our measurements, changing the body of IntegerModuloP.multiplicativeInverse() to

 return getField().getElement(asBigInteger().modPow(modulus.subtract(BigInteger.TWO), modulus));

will result in a bit better performance improvement without the added complexity of new code for every curve.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From alanb at openjdk.org  Fri Oct  7 12:53:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 12:53:30 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

src/java.se/share/data/jdwp/jdwp.spec line 101:

> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
> 100:         "in the target VM. This includes platform threads created with the Thread "
> 101:         "API and all native threads attached to the target VM with JNI code."

The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From djelinski at openjdk.org  Fri Oct  7 15:40:52 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Oct 2022 15:40:52 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <IaNa2DGvxDuBFbWr1d2SR3kREdwNDV_vjwzXSrE1Fv4=.84d4385b-18ce-4712-a298-f11373cf17f4@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <iTcwECu6GpkWk-DsmBEPPck05vvvAZjDSWTab967844=.b421d673-5b85-41d8-81ef-546065e34397@github.com>
 <IaNa2DGvxDuBFbWr1d2SR3kREdwNDV_vjwzXSrE1Fv4=.84d4385b-18ce-4712-a298-f11373cf17f4@github.com>
Message-ID: <sPQabWU8VFzNdSxjzSkIsJctU98atqT7oZI-LI4x_bQ=.d893ba16-d52c-40b5-b8b1-0f0e16bc3294@github.com>

On Thu, 6 Oct 2022 18:33:51 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> It seems to me the scalar multiplication enhancement should be done first, or maybe integrated with this fix.
>> Do you have a bug number for the scalar multiplication enhancement?
>
>> It seems to me the scalar multiplication enhancement should be done first, or maybe integrated with this fix. Do you have a bug number for the scalar multiplication enhancement?
> 
> I did not file the scalar multiplication enhancement in JBS yet.  There are a few places that could be improved for the EC performance.  However, the update is big if having them all in one PR.  In order to simplify the code review and implementation, I would like to break it down into small enhancements.  I filed an [umbrella RFE](https://bugs.openjdk.org/browse/JDK-8294188) for the performance improvement in EC.  The goal to make the common EC crypto operations (key generation/exchange/signature) 3+ times faster, and make the TLS connections 20%+ faster .  
> 
> I may have to wait for a few more weeks so that I can come up with the scalar multiplication pull request.

@XueleiFan tests are failing after the last commit; see `sun/security/ec/TestEC.java` for example.

@ferakocz biginteger math is not constant-time, which is why it can't be used here.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From duke at openjdk.org  Fri Oct  7 15:48:22 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 7 Oct 2022 15:48:22 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <sPQabWU8VFzNdSxjzSkIsJctU98atqT7oZI-LI4x_bQ=.d893ba16-d52c-40b5-b8b1-0f0e16bc3294@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <iTcwECu6GpkWk-DsmBEPPck05vvvAZjDSWTab967844=.b421d673-5b85-41d8-81ef-546065e34397@github.com>
 <IaNa2DGvxDuBFbWr1d2SR3kREdwNDV_vjwzXSrE1Fv4=.84d4385b-18ce-4712-a298-f11373cf17f4@github.com>
 <sPQabWU8VFzNdSxjzSkIsJctU98atqT7oZI-LI4x_bQ=.d893ba16-d52c-40b5-b8b1-0f0e16bc3294@github.com>
Message-ID: <BoOou9b_OKKYCI8ooQmBqR4QzFcgMUg4Ra7Uch0uEes=.dea87b65-baa4-4e1a-a18d-19612ee7111b@github.com>

On Fri, 7 Oct 2022 15:37:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> It seems to me the scalar multiplication enhancement should be done first, or maybe integrated with this fix. Do you have a bug number for the scalar multiplication enhancement?
>> 
>> I did not file the scalar multiplication enhancement in JBS yet.  There are a few places that could be improved for the EC performance.  However, the update is big if having them all in one PR.  In order to simplify the code review and implementation, I would like to break it down into small enhancements.  I filed an [umbrella RFE](https://bugs.openjdk.org/browse/JDK-8294188) for the performance improvement in EC.  The goal to make the common EC crypto operations (key generation/exchange/signature) 3+ times faster, and make the TLS connections 20%+ faster .  
>> 
>> I may have to wait for a few more weeks so that I can come up with the scalar multiplication pull request.
>
> @XueleiFan tests are failing after the last commit; see `sun/security/ec/TestEC.java` for example.
> 
> @ferakocz biginteger math is not constant-time, which is why it can't be used here.

@djelinski for this purpose, it doesn't matter if the exponentiation is not constant time, as its running time only depends on the value of the exponent, which is a known (public) value.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From weijun at openjdk.org  Fri Oct  7 16:04:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Oct 2022 16:04:04 GMT
Subject: RFR: 8294987: Streamline DerOutputStream write
Message-ID: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>

Return `this` in various output methods so you can write something like

        new DerOutputStream().putInteger(1)
                .putOctetString("12345".getBytes(StandardCharsets.UTF_8))
                .write(AlgorithmId.get("ed25519"))
                .writeImplicit((byte)0x80, new DerOutputStream().putUnalignedBitString(ba)).toByteArray();

No regression test. Trivial pure enhancement.

-------------

Commit messages:
 - code change

Changes: https://git.openjdk.org/jdk/pull/10608/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10608&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294987
  Stats: 91 lines in 1 file changed: 30 ins; 18 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10608.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10608/head:pull/10608

PR: https://git.openjdk.org/jdk/pull/10608

From djelinski at openjdk.org  Fri Oct  7 16:33:21 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Oct 2022 16:33:21 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
Message-ID: <MTeDBg6HHh1CZUAu6f6-SCfP22YvnYzSlxfulVCNRhU=.83c4898f-9ad3-4f82-9eb0-9190258de465@github.com>

On Wed, 5 Oct 2022 17:37:25 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 37 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 94 multiplication.
>> 
>> Here is the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1459.527 ? 10.160  ops/s
>> Signatures.sign              512  thrpt   15  1450.707 ? 15.554  ops/s
>> Signatures.sign             2048  thrpt   15  1453.490 ?  5.362  ops/s
>> Signatures.sign            16384  thrpt   15  1437.364 ?  8.291  ops/s
>> 
>> 
>> For comparing, here is the benchmarking numbers by using BigInteger.modInverse();
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.sign               64  thrpt   15  1395.628 ? 180.649  ops/s
>> Signatures.sign              512  thrpt   15  1510.590 ?   9.826  ops/s
>> Signatures.sign             2048  thrpt   15  1514.282 ?   3.382  ops/s
>> Signatures.sign            16384  thrpt   15  1497.325 ?   6.854  ops/s
>> 
>> and numbers for using BigInteger.modPow():
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1486.764 ? 17.908  ops/s
>> Signatures.sign              512  thrpt   15  1494.801 ? 14.072  ops/s
>> Signatures.sign             2048  thrpt   15  1500.170 ?  6.998  ops/s
>> Signatures.sign            16384  thrpt   15  1434.192 ? 49.269  ops/s
>> 
>> 
>> 
>> It looks like the performance improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more performance improvement

BigInteger exponentiation time also depends on also depends on the base; quick benchmark:
`BigInteger.ONE.modPow(mod.subtract(BigInteger.TWO), mod)` vs `BigInteger.TWO.modPow(mod.subtract(BigInteger.TWO), mod)`:

Benchmark        (messageLength)   Mode  Cnt         Score         Error  Units
Signatures.pow1               64  thrpt   15  67352286,115 ? 1281517,907  ops/s
Signatures.pow2               64  thrpt   15     62431,716 ?    1056,398  ops/s

for IntegerModuloP the result should not depend on base, and if it does, we should fix that.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From jnimeh at openjdk.org  Fri Oct  7 16:52:28 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 7 Oct 2022 16:52:28 GMT
Subject: RFR: 8294987: Streamline DerOutputStream write
In-Reply-To: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
References: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
Message-ID: <p2Z4GwTX4Ln8B0NNSjxEykcEWK2ZIFXqR2aOkl_H40Q=.8dac9fcf-0ede-429b-8366-2eeed905deb1@github.com>

On Fri, 7 Oct 2022 15:47:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Return `this` in various output methods so you can write something like
> 
>         new DerOutputStream().putInteger(1)
>                 .putOctetString("12345".getBytes(StandardCharsets.UTF_8))
>                 .write(AlgorithmId.get("ed25519"))
>                 .writeImplicit((byte)0x80, new DerOutputStream().putUnalignedBitString(ba)).toByteArray();
> 
> No regression test. Trivial pure enhancement.

Looks good to me

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10608

From xuelei at openjdk.org  Fri Oct  7 17:48:20 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 7 Oct 2022 17:48:20 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <IaNa2DGvxDuBFbWr1d2SR3kREdwNDV_vjwzXSrE1Fv4=.84d4385b-18ce-4712-a298-f11373cf17f4@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <iTcwECu6GpkWk-DsmBEPPck05vvvAZjDSWTab967844=.b421d673-5b85-41d8-81ef-546065e34397@github.com>
 <IaNa2DGvxDuBFbWr1d2SR3kREdwNDV_vjwzXSrE1Fv4=.84d4385b-18ce-4712-a298-f11373cf17f4@github.com>
Message-ID: <aHNaj6o5oVobln4dKVAFLbbHeIy-65PMOIW2yQ-Xx8o=.f16dcba2-e8a8-47fa-8b4f-66de80a9e855@github.com>

On Thu, 6 Oct 2022 18:33:51 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> It seems to me the scalar multiplication enhancement should be done first, or maybe integrated with this fix.
>> Do you have a bug number for the scalar multiplication enhancement?
>
>> It seems to me the scalar multiplication enhancement should be done first, or maybe integrated with this fix. Do you have a bug number for the scalar multiplication enhancement?
> 
> I did not file the scalar multiplication enhancement in JBS yet.  There are a few places that could be improved for the EC performance.  However, the update is big if having them all in one PR.  In order to simplify the code review and implementation, I would like to break it down into small enhancements.  I filed an [umbrella RFE](https://bugs.openjdk.org/browse/JDK-8294188) for the performance improvement in EC.  The goal to make the common EC crypto operations (key generation/exchange/signature) 3+ times faster, and make the TLS connections 20%+ faster .  
> 
> I may have to wait for a few more weeks so that I can come up with the scalar multiplication pull request.

> @XueleiFan tests are failing after the last commit; see `sun/security/ec/TestEC.java` for example.
> 
@djelinski Thank you very much for help for the testing.  The test passed in my testing, but I may made something wrong in the commit.  Anyway, I'm working on further improvement, similar to your comments.  I will make sure the test passed for the next commit.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From ascarpino at openjdk.org  Fri Oct  7 18:43:14 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 7 Oct 2022 18:43:14 GMT
Subject: RFR: 8294987: Streamline DerOutputStream write
In-Reply-To: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
References: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
Message-ID: <gS4NdDY6k-7RX6WFetYaqhcOu9TgejFCSAK8i9CoYac=.8fda2cd4-5715-4271-8a30-d6b3864be933@github.com>

On Fri, 7 Oct 2022 15:47:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Return `this` in various output methods so you can write something like
> 
>         new DerOutputStream().putInteger(1)
>                 .putOctetString("12345".getBytes(StandardCharsets.UTF_8))
>                 .write(AlgorithmId.get("ed25519"))
>                 .writeImplicit((byte)0x80, new DerOutputStream().putUnalignedBitString(ba)).toByteArray();
> 
> No regression test. Trivial pure enhancement.

There are a number of methods that call 'write()' then call 'return this;'  they could just be 'return write()', but if that's a style you prefer, that is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10608

From weijun at openjdk.org  Fri Oct  7 19:01:20 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Oct 2022 19:01:20 GMT
Subject: RFR: 8294987: Streamline DerOutputStream write
In-Reply-To: <gS4NdDY6k-7RX6WFetYaqhcOu9TgejFCSAK8i9CoYac=.8fda2cd4-5715-4271-8a30-d6b3864be933@github.com>
References: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
 <gS4NdDY6k-7RX6WFetYaqhcOu9TgejFCSAK8i9CoYac=.8fda2cd4-5715-4271-8a30-d6b3864be933@github.com>
Message-ID: <AoES4HTvO2hnVbC3W8WKALDXaclAGtz5GWPivCU0JBQ=.903dce99-4ab5-4860-a18e-73c440f8ad54@github.com>

On Fri, 7 Oct 2022 18:39:48 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> There are a number of methods that call 'write()' then call 'return this;' they could just be 'return write()', but if that's a style you prefer, that is fine.

Not my style. Will fix them.

-------------

PR: https://git.openjdk.org/jdk/pull/10608

From weijun at openjdk.org  Fri Oct  7 19:52:15 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Oct 2022 19:52:15 GMT
Subject: RFR: 8294987: Streamline DerOutputStream write [v2]
In-Reply-To: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
References: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
Message-ID: <irt_Lq4hHIiBF2TIWSXHjMksc2XaqPPyk8P_TjyRjvQ=.a3b3a731-1c6d-4cee-a7bc-527e4017921e@github.com>

> Return `this` in various output methods so you can write something like
> 
>         new DerOutputStream().putInteger(1)
>                 .putOctetString("12345".getBytes(StandardCharsets.UTF_8))
>                 .write(AlgorithmId.get("ed25519"))
>                 .writeImplicit((byte)0x80, new DerOutputStream().putUnalignedBitString(ba)).toByteArray();
> 
> No regression test. Trivial pure enhancement.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  just return

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10608/files
  - new: https://git.openjdk.org/jdk/pull/10608/files/298f5f20..eeb131d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10608&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10608&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10608.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10608/head:pull/10608

PR: https://git.openjdk.org/jdk/pull/10608

From ascarpino at openjdk.org  Fri Oct  7 20:27:24 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 7 Oct 2022 20:27:24 GMT
Subject: RFR: 8294987: Streamline DerOutputStream write [v2]
In-Reply-To: <irt_Lq4hHIiBF2TIWSXHjMksc2XaqPPyk8P_TjyRjvQ=.a3b3a731-1c6d-4cee-a7bc-527e4017921e@github.com>
References: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
 <irt_Lq4hHIiBF2TIWSXHjMksc2XaqPPyk8P_TjyRjvQ=.a3b3a731-1c6d-4cee-a7bc-527e4017921e@github.com>
Message-ID: <McvjOmE9ehKlgX7mejccD3s5mMRVlyG68gkpG0RE1DM=.3b562d7e-7826-4829-a834-be89ab74ad59@github.com>

On Fri, 7 Oct 2022 19:52:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Return `this` in various output methods so you can write something like
>> 
>>         new DerOutputStream().putInteger(1)
>>                 .putOctetString("12345".getBytes(StandardCharsets.UTF_8))
>>                 .write(AlgorithmId.get("ed25519"))
>>                 .writeImplicit((byte)0x80, new DerOutputStream().putUnalignedBitString(ba)).toByteArray();
>> 
>> No regression test. Trivial pure enhancement.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   just return

Marked as reviewed by ascarpino (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10608

From weijun at openjdk.org  Fri Oct  7 20:37:48 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Oct 2022 20:37:48 GMT
Subject: Integrated: 8294987: Streamline DerOutputStream write
In-Reply-To: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
References: <rQYDBL8J9Npfn2QtLFWz2O1yeDjO_NGSot75hTCklDg=.ad4f5db5-1d40-40b5-8403-25566f4e9150@github.com>
Message-ID: <Y1Ibgzm-fTjG_DfFLcqY0lAyCdVvPPz0lV5TUe389fQ=.513469b0-3642-4b17-b4df-d01b46348d23@github.com>

On Fri, 7 Oct 2022 15:47:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Return `this` in various output methods so you can write something like
> 
>         new DerOutputStream().putInteger(1)
>                 .putOctetString("12345".getBytes(StandardCharsets.UTF_8))
>                 .write(AlgorithmId.get("ed25519"))
>                 .writeImplicit((byte)0x80, new DerOutputStream().putUnalignedBitString(ba)).toByteArray();
> 
> No regression test. Trivial pure enhancement.

This pull request has now been integrated.

Changeset: 823b53d8
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/823b53d8957ff06b66c35e676c25992e9707afe6
Stats:     92 lines in 1 file changed: 26 ins; 19 del; 47 mod

8294987: Streamline DerOutputStream write

Reviewed-by: jnimeh, ascarpino

-------------

PR: https://git.openjdk.org/jdk/pull/10608

From wetmore at openjdk.org  Sat Oct  8 15:32:29 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 8 Oct 2022 15:32:29 GMT
Subject: RFR: 8294848: Unnecessary SSLCipher dispose implementations
In-Reply-To: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
References: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
Message-ID: <ZwtRO2_0fye7lwgRFpmkXhMA8D2p2W4BI6TEh8cZSr0=.0af23b7e-ae85-41b5-b86d-96382e54151e@github.com>

On Wed, 5 Oct 2022 11:24:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.
> 
> Invocations of [readCipher.dispose](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L118) and [disposeWriteCipher](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L191) come with a comment:
> 
>> Dispose of any intermediate state in the underlying cipher. For PKCS11 ciphers, this will release any attached sessions, and thus make finalization faster.
>> Since MAC's doFinal() is called for every SSL/TLS packet, it's not necessary to do the same with MAC's.
> 
> Typical non-empty implementation of dispose is a call to cipher.doFinal, which internally releases PKCS11 native resources.
> 
> AEAD ciphers are similar to MAC - `doFinal()` is also called for every packet. They don't need another explicit `doFinal` call.
> 
> Tier1-3 tests clean. No new tests - this is clean up only.

LGTM.

Can I suggest a noreg-hard label in addition to noreg-cleanup?

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10574

From xuelei at openjdk.org  Sat Oct  8 15:34:57 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 8 Oct 2022 15:34:57 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v3]
In-Reply-To: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
Message-ID: <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>

> Hi,
> 
> May I have this patch reviewed?
> 
> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
> 
> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 13 multiplication.
> 
> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 43 multiplication.
> 
> In EC operations, square operation is much faster than multiplication.  Decreasing multiplication numbers could speed up the multiplicative inverse significantly.
> 
> The benchmark for ECDSA Signature is checked in order to see if the performance improvement is visible.  Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
> 
> 
> And the following are the benchmarking after the patch applied.
> 
> Signatures.sign               64  thrpt   15  1484.404 ? 10.705  ops/s
> Signatures.sign              512  thrpt   15  1486.563 ?  7.514  ops/s
> Signatures.sign             2048  thrpt   15  1479.866 ? 15.028  ops/s
> Signatures.sign            16384  thrpt   15  1469.789 ?  3.844  ops/s
> 
> 
> The performance improvement of the patch is about 5% for ECDSA signature.  It looks like the improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
> 
> For comparing, here is the benchmarking numbers by using BigInteger.modInverse();
> 
> Benchmark        (messageLength)   Mode  Cnt     Score     Error  Units
> Signatures.sign               64  thrpt   15  1395.628 ? 180.649  ops/s
> Signatures.sign              512  thrpt   15  1510.590 ?   9.826  ops/s
> Signatures.sign             2048  thrpt   15  1514.282 ?   3.382  ops/s
> Signatures.sign            16384  thrpt   15  1497.325 ?   6.854  ops/s
> 
> and numbers for using BigInteger.modPow():
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1486.764 ? 17.908  ops/s
> Signatures.sign              512  thrpt   15  1494.801 ? 14.072  ops/s
> Signatures.sign             2048  thrpt   15  1500.170 ?  6.998  ops/s
> Signatures.sign            16384  thrpt   15  1434.192 ? 49.269  ops/s
> 
> 
> Enhancement for other curves will be considered in separate pull requests.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  more improvement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10544/files
  - new: https://git.openjdk.org/jdk/pull/10544/files/b9bf0269..ae1df949

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10544&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10544&range=01-02

  Stats: 93 lines in 1 file changed: 73 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10544.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10544/head:pull/10544

PR: https://git.openjdk.org/jdk/pull/10544

From xuelei at openjdk.org  Sat Oct  8 15:34:57 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 8 Oct 2022 15:34:57 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <tIewcVMCIM1UYorWL7uMqrLzOODoXBveOkt4uQN4Gdw=.903a5bfa-e6de-49c7-9676-a0e4d74e9f0b@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <tIewcVMCIM1UYorWL7uMqrLzOODoXBveOkt4uQN4Gdw=.903a5bfa-e6de-49c7-9676-a0e4d74e9f0b@github.com>
Message-ID: <VLJ1GlPrKW85w8ROwluGQ-xxi5-5aiL16s40AuemcaI=.ee31ba8f-8f29-413c-8cd6-73b3fa611876@github.com>

On Thu, 6 Oct 2022 19:35:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> could you also try using precomputed powers of t between 0-15? similar to what we do in [ECOperations.multiply](https://github.com/openjdk/jdk/blob/2ae8e3118385bdf93c50bca550334734b69bc2b6/src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java#L231) (see `pointMultiples`). This will also improve the number of multiplications.

0-15 may be too much for the P256 order field because of the bit sets in it.  I tried 0-8 and 0-4.  0-4 has a little bit better benchmark numbers.  The two is about the same for multiplication numbers, but 0-8 uses more memory.  In the last commit, 0-4 is used for caching as it is more memory friendly.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From aefimov at openjdk.org  Sun Oct  9 11:52:18 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Sun, 9 Oct 2022 11:52:18 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov 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 six additional commits since the last revision:

 - Refactor checkInput, better reporting for invalid filter patterns
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/1a5e83e0..091677e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=00-01

  Stats: 20702 lines in 557 files changed: 11293 ins; 7286 del; 2123 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Sun Oct  9 11:52:19 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Sun, 9 Oct 2022 11:52:19 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
Message-ID: <iIX4TKhkeic7UYz3cnTnQCpdadV80j4EHCbDGB6Wyww=.603d6594-cecd-4d94-a889-c0a816288849@github.com>

On Thu, 6 Oct 2022 16:10:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Efimov 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 six additional commits since the last revision:
>> 
>>  - Refactor checkInput, better reporting for invalid filter patterns
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Additional comments/formatting cleanup.
>>  - More tests clean-up. Code/doc comments cleanup.
>>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation
>
> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 91:
> 
>> 89:     }
>> 90: 
>> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {
> 
> This construct in which the supplied lambda fills in the serialClass is pretty obscure. 
> Perhaps the variable name can be "serialClass" to match the only non-default method in ObjectInputFilter would give a better hint.

Thanks - `serialClass` name reads better.

> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 92:
> 
>> 90: 
>> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {
>> 92:         Status result = switch(scheme) {
> 
> The handling of the selection of the filter could be more direct.
> You can change the argument to checkInput to be ObjectInputFilter and pass the desired filter; LDAP_FILTER, RMI_FITLER, or GLOBAL_FILTER.
> And make the check of the GLOBAL_FILTER conditional on it not having already been evaluated.
> Then it will be the case that there must always be a specific filter.
> 
> The callers are all local to the class and would change to pass the desired filter.

Thank you - refactored as suggested.

> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 173:
> 
>> 171:                                            DEFAULT_GLOBAL_SP_VALUE));
>> 172: 
>> 173:     // A system-wide LDAP specific object factories filter constructed from the system
> 
> Where does the IllegalArgumentException from ObjectInputFilter.create get handled or reported?
> If the property value is illformed, the error should be enough to diagnose and correct the property.

That is a good point - the current state of reporting for a malformed filter pattern can be improved:
First filter check with `check*Filter` throws `java.lang.ExceptionInInitializerError` with a cause set to `java.lang.IllegalArgumentException` with filter pattern error. But subsequent checks throw `java.lang.NoClassDefFoundError: Could not initialize class com.sun.naming.internal.ObjectFactoriesFilter`.

To address that one interface and two new records have been added to represent a factory filter state:
 - `ConfiguredFilter` - interface for representing a filter created with `ObjectInputFilter.create` from a pattern.
 - `ValidFilter implements ConfiguredFilter` - stores `ObjectInputFilter` constructed from a valid filter pattern.
 - `InvalidFilter implements ConfiguredFilter` - stores `IllegalArgumentException` generated by parsing of an invalid filter pattern. The stored `IAE` is used to report malformed filter pattern each time specific filter is consulted.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Sun Oct  9 11:53:55 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Sun, 9 Oct 2022 11:53:55 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
Message-ID: <fWzSIKrBYtbLZJ06p_xubuo6L6I4PkRpYuY_Ytp_6As=.e80026a6-667f-4e99-b3b6-34e09ca8b456@github.com>

On Thu, 6 Oct 2022 16:24:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Efimov 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 six additional commits since the last revision:
>> 
>>  - Refactor checkInput, better reporting for invalid filter patterns
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Additional comments/formatting cleanup.
>>  - More tests clean-up. Code/doc comments cleanup.
>>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation
>
> test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java line 46:
> 
>> 44:  * @build LDAPServer LDAPTestUtils TestFactory
>> 45:  *
>> 46:  * @run main/othervm LdapFactoriesFilterTest false
> 
> Are any of these filter property cases, malformed and would produce an error from ObjectInputFilter.create?

There were no such cases.
Now, RMI and LDAP tests have been modified to run with malformed filter patterns which produce an error from `ObjectInputFilter.create`. 
Also, new cases were added to check that illegal patterns in one of RMI or LDAP filters not preventing other one from being used.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From xuelei at openjdk.org  Mon Oct 10 05:22:09 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 05:22:09 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
Message-ID: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>

Hi,

May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.

In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.

The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.

The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.

In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.

It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.

The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s


and here are the numbers with this patch applied:

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s


>From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
``` 

The following are numbers for secp256r1 key generation, without this patch:

Benchmark                      Mode  Cnt     Score   Error  Units
KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s


With this patch:

Benchmark                      Mode  Cnt     Score    Error  Units
KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s


with improved limbs (from 10 to 9):

Benchmark                      Mode  Cnt     Score    Error  Units
KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s

If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.

Thanks,
Xuelei

-------------

Commit messages:
 - add the key pair generation bench code
 - remove tabs
 - 8295010: EC limbs addition and subtraction limit

Changes: https://git.openjdk.org/jdk/pull/10624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295010
  Stats: 256 lines in 13 files changed: 128 ins; 94 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

PR: https://git.openjdk.org/jdk/pull/10624

From djelinski at openjdk.org  Mon Oct 10 07:01:47 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Oct 2022 07:01:47 GMT
Subject: RFR: 8294848: Unnecessary SSLCipher dispose implementations
In-Reply-To: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
References: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
Message-ID: <il3e_JsHDh_uVxpu6lEiJY2_3tDFo_FxIqWam-zpD4E=.d50cd652-2fee-4897-b11d-85adf8dc78be@github.com>

On Wed, 5 Oct 2022 11:24:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.
> 
> Invocations of [readCipher.dispose](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L118) and [disposeWriteCipher](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L191) come with a comment:
> 
>> Dispose of any intermediate state in the underlying cipher. For PKCS11 ciphers, this will release any attached sessions, and thus make finalization faster.
>> Since MAC's doFinal() is called for every SSL/TLS packet, it's not necessary to do the same with MAC's.
> 
> Typical non-empty implementation of dispose is a call to cipher.doFinal, which internally releases PKCS11 native resources.
> 
> AEAD ciphers are similar to MAC - `doFinal()` is also called for every packet. They don't need another explicit `doFinal` call.
> 
> Tier1-3 tests clean. No new tests - this is clean up only.

Label added. Thanks for the reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/10574

From djelinski at openjdk.org  Mon Oct 10 07:07:03 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Oct 2022 07:07:03 GMT
Subject: Integrated: 8294848: Unnecessary SSLCipher dispose implementations
In-Reply-To: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
References: <YmdIATUfUXAUCZZTREa3sTnstGHPEa4w8LmL2hpU7Tk=.7e3946f4-c89d-4df1-b0e4-8ba3995eecb1@github.com>
Message-ID: <Xchx1-gl_F_7kyZ1VDszOnOZQelfP_J9O1oRZefA2f4=.93d3b04f-df69-4b94-8509-af811e557d31@github.com>

On Wed, 5 Oct 2022 11:24:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.
> 
> Invocations of [readCipher.dispose](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/InputRecord.java#L118) and [disposeWriteCipher](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L191) come with a comment:
> 
>> Dispose of any intermediate state in the underlying cipher. For PKCS11 ciphers, this will release any attached sessions, and thus make finalization faster.
>> Since MAC's doFinal() is called for every SSL/TLS packet, it's not necessary to do the same with MAC's.
> 
> Typical non-empty implementation of dispose is a call to cipher.doFinal, which internally releases PKCS11 native resources.
> 
> AEAD ciphers are similar to MAC - `doFinal()` is also called for every packet. They don't need another explicit `doFinal` call.
> 
> Tier1-3 tests clean. No new tests - this is clean up only.

This pull request has now been integrated.

Changeset: 8a148bc9
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a148bc960a61908359f9e6dd62c8e7791cc2690
Stats:     88 lines in 1 file changed: 0 ins; 88 del; 0 mod

8294848: Unnecessary SSLCipher dispose implementations

Reviewed-by: xuelei, valeriep, wetmore

-------------

PR: https://git.openjdk.org/jdk/pull/10574

From jpai at openjdk.org  Mon Oct 10 07:21:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 07:21:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <o7TrYfjkQIrkZNh298CrsjG1huBZFuCsEMo6tIhqXEE=.6acdcc2a-a59f-4dbe-ba23-f56c05b5de1c@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 29:

> 27: 
> 28: import jdk.jfr.*;
> 29: import jdk.jfr.internal.MirrorEvent;

Hello Sean, this `MirrorEvent` appears to be an unused import. Furthermore, as far as I know, in `core-libs` the `*` wildcard imports aren't typically used. I don't know if it's OK to use it here in the `jdk.jfr` module.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From jpai at openjdk.org  Mon Oct 10 07:25:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 07:25:52 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <qbACrjxw4wqSsVAbuSIznhXSphkW2gn1fIs-q2RD9e4=.a645aa14-4d28-4f3a-b4e5-ffdc8f261f28@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 318:

> 316:                 InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
> 317:                 e.key = (String) entry.getKey();
> 318:                 e.value = (String) entry.getValue();

To avoid any (odd/unexpected) `ClassCastException` here, perhaps this loop can be changed to something like:

for (Set<String> name : p.stringPropertyNames()) {
    InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
    e.key = name;
    e.value = p.getProperty(name);

Since this code anyway wants to deal with string key/values, this wouldn't introduce any functional change and yet at the same time prevent any unexpected/theoretical `ClassCastException`s

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From alanb at openjdk.org  Mon Oct 10 07:33:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Oct 2022 07:33:53 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/java.base/share/classes/java/security/ProtectionDomain.java line 76:

> 74:     static class JavaSecurityAccessImpl implements JavaSecurityAccess {
> 75:         /* cache a copy for recording purposes */
> 76:         static Properties initialSecurityProperties;

This doesn't look very clean. Could the Security class hold the initial security properties and provide an accessor method that JavaSecurityAccess:getIinitialProperties could use?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From jpai at openjdk.org  Mon Oct 10 08:10:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 08:10:58 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 33:

> 31: @Category({"Java Development Kit", "Security"})
> 32: @Label("Initial Security Property")
> 33: @Name("jdk.InitialSecurityProperty")

Should we name this to `jdk.InitialSecurityProperties` and the label to `Initial Security Properties`, to be more accurate?

src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 35:

> 33: @Name("jdk.InitialSecurityProperty")
> 34: @Description("Initial Security Properties")
> 35: public final class InitialSecurityPropertyEvent extends AbstractJDKEvent {

The event naming guidelines here https://docs.oracle.com/en/java/javase/17/jfapi/guidelines-naming-and-labeling-events.html recommend leaving out `Event` from the class name. So, maybe we should call this `InitialSecurityProperties`?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From duke at openjdk.org  Mon Oct 10 08:25:47 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 10 Oct 2022 08:25:47 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <MTeDBg6HHh1CZUAu6f6-SCfP22YvnYzSlxfulVCNRhU=.83c4898f-9ad3-4f82-9eb0-9190258de465@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <MTeDBg6HHh1CZUAu6f6-SCfP22YvnYzSlxfulVCNRhU=.83c4898f-9ad3-4f82-9eb0-9190258de465@github.com>
Message-ID: <otS0I5wK1DTeFCqeYsIbMFuUDeo4h0e3fKuMZXMhVi0=.1b695976-fc09-42a1-b3e2-7941eb703216@github.com>

On Fri, 7 Oct 2022 16:31:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> BigInteger exponentiation time also depends on also depends on the base; quick benchmark: `BigInteger.ONE.modPow(mod.subtract(BigInteger.TWO), mod)` vs `BigInteger.TWO.modPow(mod.subtract(BigInteger.TWO), mod)`:
> 
> ```
> Benchmark        (messageLength)   Mode  Cnt         Score         Error  Units
> Signatures.pow1               64  thrpt   15  67352286,115 ? 1281517,907  ops/s
> Signatures.pow2               64  thrpt   15     62431,716 ?    1056,398  ops/s
> ```
> 
> for IntegerModuloP the result should not depend on base, and if it does, we should fix that.

Well, if you ever encounter the special cased "ONE" during ECDSA signature, you have a bigger problem than that the exponentiation is not exactly constant time. Also, if you can get close enough to the system doing the signing to be able to measure the time of the exponentiation precisely enough to differentiate one really occurring base from another -- you only have one chance to measure, so cannot average out noise -- than again, you probably have better methods to get to the key than trying to measure time.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From aturbanov at openjdk.org  Mon Oct 10 10:17:48 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 10 Oct 2022 10:17:48 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <K6x6H3pf32exC22lIpC-dqxbW-qKzRiuKioq11y6DTw=.8c34b910-2472-4221-926b-9afa38f3bc2f@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

test/jdk/java/security/Security/ConfigFileTest.java line 132:

> 130:                         .shouldNotContain(EXPECTED_DEBUG_OUTPUT)
> 131:                         .shouldNotContain(UNEXPECTED_DEBUG_OUTPUT);
> 132:             } else{

let's add one space after `else`

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From egahlin at openjdk.org  Mon Oct 10 10:33:11 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 10 Oct 2022 10:33:11 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
Message-ID: <TOy9MQJ0WIHlFSzciiyVssrPo1qHV67m8pR5f1zgkUs=.848fd2b0-2701-4b13-b5a7-4a6e4d205454@github.com>

On Mon, 10 Oct 2022 08:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 35:
> 
>> 33: @Name("jdk.InitialSecurityProperty")
>> 34: @Description("Initial Security Properties")
>> 35: public final class InitialSecurityPropertyEvent extends AbstractJDKEvent {
> 
> The event naming guidelines here https://docs.oracle.com/en/java/javase/17/jfapi/guidelines-naming-and-labeling-events.html recommend leaving out `Event` from the class name. So, maybe we should call this `InitialSecurityProperties`?

The documentation is somewhat misleading. If the event has a name annotation, I think it's fine to call the class Event, because name will override the class name.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From dfuchs at openjdk.org  Mon Oct 10 11:21:46 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Oct 2022 11:21:46 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
Message-ID: <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>

On Sun, 9 Oct 2022 11:52:18 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov 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 six additional commits since the last revision:
> 
>  - Refactor checkInput, better reporting for invalid filter patterns
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Additional comments/formatting cleanup.
>  - More tests clean-up. Code/doc comments cleanup.
>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

Changes requested by dfuchs (Reviewer).

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 99:

> 97:             return globalResult == Status.ALLOWED;
> 98:         }
> 99: 

If I'm not mistaken there's  no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From egahlin at openjdk.org  Mon Oct 10 11:31:54 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 10 Oct 2022 11:31:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
Message-ID: <a3WRkH2oSRMn1ifrGEgOsTMHB9xT6O44qEijZdpB4OA=.37e9a8f5-cc82-48a3-98cf-f19a3ebceb0e@github.com>

On Mon, 10 Oct 2022 08:04:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 33:
> 
>> 31: @Category({"Java Development Kit", "Security"})
>> 32: @Label("Initial Security Property")
>> 33: @Name("jdk.InitialSecurityProperty")
> 
> Should we name this to `jdk.InitialSecurityProperties` and the label to `Initial Security Properties`, to be more accurate?

There is one property per event, so it uses the same naming convention as jdk.InitialSystemProperty

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aefimov at openjdk.org  Mon Oct 10 12:09:53 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 10 Oct 2022 12:09:53 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
 <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
Message-ID: <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>

On Mon, 10 Oct 2022 11:16:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> If I'm not mistaken there's no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?

Yes - there is no point, and that will reduce number of `checkInput` calls on a specific filter, if it is not the global one. That's how it will look like:

    private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
        var globalFilter = GLOBAL_FILTER.filter();
        var specificFilter = filter.filter();
        Status globalResult = globalFilter.checkInput(serialClass);

        // Check if a specific filter is the global one
        if (filter == GLOBAL_FILTER) {
            return globalResult == Status.ALLOWED;
        }
        return switch (globalResult) {
            case ALLOWED -> specificFilter.checkInput(serialClass) != Status.REJECTED;
            case REJECTED -> false;
            case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
        };
    }


The `if (filter == GLOBAL_FILTER) {` check can be also removed but without it the `checkInput` will be called twice on global filter for the case where `specific == global`, ie call from the `checkGlobalFilter`.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From djelinski at openjdk.org  Mon Oct 10 12:13:57 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Oct 2022 12:13:57 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <N5AS7hNT4XpvMjQnvFILMwf0Pt1d81x-gGveYpBWPd0=.4812c26d-f930-4852-87e5-f99af5ddf198@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

That's a pretty significant performance degradation (8%?), and as far as I could tell, it will affect all EC and XEC implementations. On the other hand, #10398 only improves performance of P256. I'm not sure that's a tradeoff we want to make.

IMO working with setReduced is not that bad; we always invoke the same set of operations in the same sequence, so if we forget to reduce a number before multiplying, every EC operation will fail. Could we introduce just enough reduce / setReduced calls to make P256 work reliably with 9 limbs? What impact would it have on P384?

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From dfuchs at openjdk.org  Mon Oct 10 13:18:47 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Oct 2022 13:18:47 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
 <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
 <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>
Message-ID: <yUWuUtt0sdbS8tN7ha-M5RT0qobBEoLjWVpjWzgvBJY=.9d6c0165-b200-4165-a9cc-78fcc592865b@github.com>

On Mon, 10 Oct 2022 12:07:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 99:
>> 
>>> 97:             return globalResult == Status.ALLOWED;
>>> 98:         }
>>> 99: 
>> 
>> If I'm not mistaken there's  no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?
>
>> If I'm not mistaken there's no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?
> 
> Yes - there is no point, and that will reduce number of `checkInput` calls on a specific filter, if it is not the global one. That's how it will look like:
> 
>     private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
>         var globalFilter = GLOBAL_FILTER.filter();
>         var specificFilter = filter.filter();
>         Status globalResult = globalFilter.checkInput(serialClass);
> 
>         // Check if a specific filter is the global one
>         if (filter == GLOBAL_FILTER) {
>             return globalResult == Status.ALLOWED;
>         }
>         return switch (globalResult) {
>             case ALLOWED -> specificFilter.checkInput(serialClass) != Status.REJECTED;
>             case REJECTED -> false;
>             case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
>         };
>     }
> 
> 
> The `if (filter == GLOBAL_FILTER) {` check can be also removed but without it the `checkInput` will be called twice on global filter for the case where `specific == global`, ie call from the `checkGlobalFilter`.

The code above LGTM. An alternative could be:


    private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
        var globalFilter = GLOBAL_FILTER.filter();
        var specificFilter = filter.filter();
        Status globalResult = globalFilter.checkInput(serialClass);

        return switch (globalResult) {
            case ALLOWED -> filter == GLOBAL || specificFilter.checkInput(serialClass) != Status.REJECTED;
            case REJECTED -> false;
            case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
        };
    }


but I believe your proposed code reads better.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Mon Oct 10 13:23:14 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 13:23:14 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <a3WRkH2oSRMn1ifrGEgOsTMHB9xT6O44qEijZdpB4OA=.37e9a8f5-cc82-48a3-98cf-f19a3ebceb0e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
 <a3WRkH2oSRMn1ifrGEgOsTMHB9xT6O44qEijZdpB4OA=.37e9a8f5-cc82-48a3-98cf-f19a3ebceb0e@github.com>
Message-ID: <JbBf_7VgjgdDMdBE2Y1KsK0WIqTjYpGb_KmEFQWSOuc=.02cee9e2-882e-4c98-a49b-5719d6901964@github.com>

On Mon, 10 Oct 2022 11:29:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 33:
>> 
>>> 31: @Category({"Java Development Kit", "Security"})
>>> 32: @Label("Initial Security Property")
>>> 33: @Name("jdk.InitialSecurityProperty")
>> 
>> Should we name this to `jdk.InitialSecurityProperties` and the label to `Initial Security Properties`, to be more accurate?
>
> There is one property per event, so it uses the same naming convention as jdk.InitialSystemProperty

You are right indeed - I overlooked the part where this PR loops over these properties and creates one event per property.

>> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 35:
>> 
>>> 33: @Name("jdk.InitialSecurityProperty")
>>> 34: @Description("Initial Security Properties")
>>> 35: public final class InitialSecurityPropertyEvent extends AbstractJDKEvent {
>> 
>> The event naming guidelines here https://docs.oracle.com/en/java/javase/17/jfapi/guidelines-naming-and-labeling-events.html recommend leaving out `Event` from the class name. So, maybe we should call this `InitialSecurityProperties`?
>
> The documentation is somewhat misleading. If the event has a name annotation, I think it's fine to call the class Event, because name will override the class name.

Thank you Erik for that detail. Looks fine to me then.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mullan at openjdk.org  Mon Oct 10 14:22:48 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Oct 2022 14:22:48 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
Message-ID: <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>

On Mon, 10 Oct 2022 07:31:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/java.base/share/classes/java/security/ProtectionDomain.java line 76:
> 
>> 74:     static class JavaSecurityAccessImpl implements JavaSecurityAccess {
>> 75:         /* cache a copy for recording purposes */
>> 76:         static Properties initialSecurityProperties;
> 
> This doesn't look very clean. Could the Security class hold the initial security properties and provide an accessor method that JavaSecurityAccess:getIinitialProperties could use?

Agree, and alternatively, it seems cleaner to add a new SharedSecrets class for `java.security.Security` and remove the dependency on PD.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aefimov at openjdk.org  Mon Oct 10 14:28:07 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 10 Oct 2022 14:28:07 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Change checkInput to be the global filter centric

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/091677e9..528489b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=01-02

  Stats: 10 lines in 1 file changed: 2 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Mon Oct 10 14:28:07 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 10 Oct 2022 14:28:07 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <yUWuUtt0sdbS8tN7ha-M5RT0qobBEoLjWVpjWzgvBJY=.9d6c0165-b200-4165-a9cc-78fcc592865b@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
 <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
 <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>
 <yUWuUtt0sdbS8tN7ha-M5RT0qobBEoLjWVpjWzgvBJY=.9d6c0165-b200-4165-a9cc-78fcc592865b@github.com>
Message-ID: <0hkdcfr9GPSGfL4O5O09w97gG5i8-EA9gDikAWxlmLs=.ffa91af6-2232-40d9-acf2-6c7f67d46228@github.com>

On Mon, 10 Oct 2022 13:14:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> If I'm not mistaken there's no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?
>> 
>> Yes - there is no point, and that will reduce number of `checkInput` calls on a specific filter, if it is not the global one. That's how it will look like:
>> 
>>     private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
>>         var globalFilter = GLOBAL_FILTER.filter();
>>         var specificFilter = filter.filter();
>>         Status globalResult = globalFilter.checkInput(serialClass);
>> 
>>         // Check if a specific filter is the global one
>>         if (filter == GLOBAL_FILTER) {
>>             return globalResult == Status.ALLOWED;
>>         }
>>         return switch (globalResult) {
>>             case ALLOWED -> specificFilter.checkInput(serialClass) != Status.REJECTED;
>>             case REJECTED -> false;
>>             case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
>>         };
>>     }
>> 
>> 
>> The `if (filter == GLOBAL_FILTER) {` check can be also removed but without it the `checkInput` will be called twice on global filter for the case where `specific == global`, ie call from the `checkGlobalFilter`.
>
> The code above LGTM. An alternative could be:
> 
> 
>     private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
>         var globalFilter = GLOBAL_FILTER.filter();
>         var specificFilter = filter.filter();
>         Status globalResult = globalFilter.checkInput(serialClass);
> 
>         return switch (globalResult) {
>             case ALLOWED -> filter == GLOBAL || specificFilter.checkInput(serialClass) != Status.REJECTED;
>             case REJECTED -> false;
>             case UNDECIDED -> filter != GLOBAL && specificFilter.checkInput(serialClass) == Status.ALLOWED;
>         };
>     }
> 
> 
> but I believe your proposed code reads better.

Thanks - pushed as 528489b

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From dfuchs at openjdk.org  Mon Oct 10 14:41:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Oct 2022 14:41:27 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <I_V0K_pQjNkHO2P2M_JoUAfo_v2muyqOvLZq-PHMeCs=.d66d4a50-07be-4911-8917-8e299758476e@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From xuelei at openjdk.org  Mon Oct 10 14:57:56 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 14:57:56 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <9okcLWyRTZycrqqn3fItFL7uuYnxaqSAuHz27hyvw0U=.a09b79b6-2fcc-48ee-901c-a8ceeab97456@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Thank you for looking into the PR.

> On the other hand, #10398 only improves performance of P256. I'm not sure that's a tradeoff we want to make.

If I get it right, all supported curves could be improved by 1 limb in implementation.

> Could we introduce just enough reduce / setReduced calls to make P256 work reliably with 9 limbs?

Yes, it is doable as well by limit the maxAdd to 1 in the implementation.  This approach needs to adjust the code accordingly, just as what we did to make maxAdd 2 works.   The performance impact is limited.  This approach has better performance (about 20%) if reducing the limbs to 9 for P256.

> IMO working with setReduced is not that bad;

Hm, I may be focus too much on the error-prone design.  Let me check what it could be by limit the maxAdd to 1 always.

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From mpowers at openjdk.org  Mon Oct 10 16:37:38 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 10 Oct 2022 16:37:38 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine
In-Reply-To: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
Message-ID: <r1m6sz4nB9lbdSuYM2M-ObL6WNYKaKTiupMGPW119VY=.8a36b175-bcba-42fb-a856-bb969a153620@github.com>

On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the code clean up reviewed?
>  
> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
> 
> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
> 
> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
> 
> Except that, I also cleaned up some code warnings from the IDE I used.
> 
> Thanks,
> Xuelei

Changing one pre-computed byte should be sufficient to blow up all AES tests.
Add a comment saying where your pre-computed values come from, e.g. Tables from FIPS 197.

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From mullan at openjdk.org  Mon Oct 10 16:55:01 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Oct 2022 16:55:01 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v3]
In-Reply-To: <I2BsL98FtFc_Xo9AvKgcNgVJZ5rEi9iaqOfCGAob8VE=.a8f01d3f-130c-469f-adba-e006bd5f7360@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <I2BsL98FtFc_Xo9AvKgcNgVJZ5rEi9iaqOfCGAob8VE=.a8f01d3f-130c-469f-adba-e006bd5f7360@github.com>
Message-ID: <zRGN-rDLApIaySKsTIeZ-fkq2SVnUNS0IZCzWdw_0uA=.ec302d9f-d506-49b9-a902-c91544098ec2@github.com>

On Tue, 4 Oct 2022 23:45:24 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Text Blocks
>  - long line

test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 29:

> 27:  * @summary     PrivateCredentialPermission should not use local variable to enable debugging
> 28:  *              implementation-dependent class
> 29:  * @run main/othervm/policy=Serial.policy Serial2

I think you can remove `main/othervm/policy=Serial.policy` (actually you can remove the whole `@run` line then).
The policy argument causes the test to run with a SecurityManager enabled, and there isn't any reason that this test needs to do that AFAICT. Also that policy file is for other tests in this directory for accessing the file system or JAAS credentials, which you are not accessing in this test.

test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 58:

> 56: 
> 57:             // Deserialize input stream and create a new object.
> 58:             ObjectInputStream ois = new ObjectInputStream(is);

Use try-with resources here so the input stream is automatically closed even if there are exceptions.

test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 61:

> 59:             PrivateCredentialPermission pcp2 =
> 60:                     (PrivateCredentialPermission)ois.readObject();
> 61:             is.close();

Not necessary as BAIS.close() is a no-op.

test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 79:

> 77:         } catch (Exception e) {
> 78:             e.printStackTrace();
> 79:             throw new SecurityException("Serial test failed");

If you include e as the cause (2nd argument) of `SecurityException` then you don't need to print the stack trace on line 78.

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From mpowers at openjdk.org  Mon Oct 10 17:20:09 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 10 Oct 2022 17:20:09 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine
In-Reply-To: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
Message-ID: <dy1TbA2c-1-f1B3gvoLK5PUxVGcMXrmwi6x1ojQ29kY=.bb34c714-bf38-43e9-8152-c35a1a621b0a@github.com>

On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the code clean up reviewed?
>  
> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
> 
> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
> 
> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
> 
> Except that, I also cleaned up some code warnings from the IDE I used.
> 
> Thanks,
> Xuelei

src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1065:

> 1063:      * @param decrypting True if 'kr' is for decryption and false otherwise.
> 1064:      */
> 1065:     private static int[] expandToSubKey(int[][] kr, boolean decrypting) {

I received the following code review comment back in April:
"Even though a static method is implicitly final and IJ is correct, the final keyword does prevent subclasses from inadvertently using the same method signature."

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From xuelei at openjdk.org  Mon Oct 10 17:24:53 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 17:24:53 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine
In-Reply-To: <dy1TbA2c-1-f1B3gvoLK5PUxVGcMXrmwi6x1ojQ29kY=.bb34c714-bf38-43e9-8152-c35a1a621b0a@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <dy1TbA2c-1-f1B3gvoLK5PUxVGcMXrmwi6x1ojQ29kY=.bb34c714-bf38-43e9-8152-c35a1a621b0a@github.com>
Message-ID: <-zYr_6sLa6fZVQgilKasAIO2uuLJo6U5OxlXGalfKIE=.9ffdc948-c52d-4eb7-b8ed-0824f7c67c7f@github.com>

On Mon, 10 Oct 2022 16:46:25 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the code clean up reviewed?
>>  
>> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
>> 
>> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
>> 
>> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
>> 
>> Except that, I also cleaned up some code warnings from the IDE I used.
>> 
>> Thanks,
>> Xuelei
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1065:
> 
>> 1063:      * @param decrypting True if 'kr' is for decryption and false otherwise.
>> 1064:      */
>> 1065:     private static int[] expandToSubKey(int[][] kr, boolean decrypting) {
> 
> I received the following code review comment back in April:
> "Even though a static method is implicitly final and IJ is correct, the final keyword does prevent subclasses from inadvertently using the same method signature."

Good point!

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From xuelei at openjdk.org  Mon Oct 10 17:43:52 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 17:43:52 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine [v2]
In-Reply-To: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
Message-ID: <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>

> Hi,
> 
> May I have the code clean up reviewed?
>  
> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
> 
> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
> 
> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
> 
> Except that, I also cleaned up some code warnings from the IDE I used.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  add back final keyword and comments about where the tables are from

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10568/files
  - new: https://git.openjdk.org/jdk/pull/10568/files/62d8f568..8105b8d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10568&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10568&range=00-01

  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10568/head:pull/10568

PR: https://git.openjdk.org/jdk/pull/10568

From djelinski at openjdk.org  Mon Oct 10 18:09:56 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Oct 2022 18:09:56 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v3]
In-Reply-To: <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
Message-ID: <DCFN5oyFXye96Vkl3MbtI-IRE2I7jj827KNBZ10TFP0=.df236cd7-76d4-4ec2-806f-ab90148d72cc@github.com>

On Sat, 8 Oct 2022 15:34:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 13 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 43 multiplication.
>> 
>> In EC operations, square operation is much faster than multiplication.  Decreasing multiplication numbers could speed up the multiplicative inverse significantly.
>> 
>> The benchmark for ECDSA Signature is checked in order to see if the performance improvement is visible.  Here are the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Signatures.sign               64  thrpt   15  1484.404 ? 10.705  ops/s
>> Signatures.sign              512  thrpt   15  1486.563 ?  7.514  ops/s
>> Signatures.sign             2048  thrpt   15  1479.866 ? 15.028  ops/s
>> Signatures.sign            16384  thrpt   15  1469.789 ?  3.844  ops/s
>> 
>> 
>> The performance improvement of the patch is about 5% for ECDSA signature.  It looks like the improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> For comparing, here is the benchmarking numbers by using BigInteger.modInverse();
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.sign               64  thrpt   15  1395.628 ? 180.649  ops/s
>> Signatures.sign              512  thrpt   15  1510.590 ?   9.826  ops/s
>> Signatures.sign             2048  thrpt   15  1514.282 ?   3.382  ops/s
>> Signatures.sign            16384  thrpt   15  1497.325 ?   6.854  ops/s
>> 
>> and numbers for using BigInteger.modPow():
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1486.764 ? 17.908  ops/s
>> Signatures.sign              512  thrpt   15  1494.801 ? 14.072  ops/s
>> Signatures.sign             2048  thrpt   15  1500.170 ?  6.998  ops/s
>> Signatures.sign            16384  thrpt   15  1434.192 ? 49.269  ops/s
>> 
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more improvement

Verified the benchmark on x86; very nice 5% improvement. Tier1-3 also passed. LGTM!

-------------

Marked as reviewed by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/10544

From valeriep at openjdk.org  Mon Oct 10 18:23:52 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 10 Oct 2022 18:23:52 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine [v2]
In-Reply-To: <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
Message-ID: <aJT8HJwosCbELXztQy2Y76bSCiyFy6aZ1qK1db8h6hY=.733bab82-8499-4f50-af4c-8dace6aba84d@github.com>

On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the code clean up reviewed?
>>  
>> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
>> 
>> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
>> 
>> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
>> 
>> Except that, I also cleaned up some code warnings from the IDE I used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add back final keyword and comments about where the tables are from

Look good. Thanks for the patch~

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10568

From bhuang at openjdk.org  Mon Oct 10 18:27:48 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 18:27:48 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to validate
 i18n compliance
Message-ID: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>

The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 

In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.

-------------

Commit messages:
 - Update keytool i18n test.

Changes: https://git.openjdk.org/jdk/pull/10635/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294994
  Stats: 407 lines in 2 files changed: 395 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From valeriep at openjdk.org  Mon Oct 10 18:27:52 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 10 Oct 2022 18:27:52 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine [v2]
In-Reply-To: <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
Message-ID: <iF4wLHdvXZu-NE1qQrY00TnSLTeUtujyNCWMmK2x0p8=.6d4259aa-848f-409e-b195-19d0bd7d2b93@github.com>

On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the code clean up reviewed?
>>  
>> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
>> 
>> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
>> 
>> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
>> 
>> Except that, I also cleaned up some code warnings from the IDE I used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add back final keyword and comments about where the tables are from

BTW,  probably should add a noreg-perf label to the bug.

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From xuelei at openjdk.org  Mon Oct 10 19:07:50 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 19:07:50 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine [v2]
In-Reply-To: <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
Message-ID: <tEP06kT7ip19bgzxIl5jcZICxSXJcjxYy98zLqkdvvc=.cf6fb7d0-2d0e-476d-b77e-63750ed6b331@github.com>

On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the code clean up reviewed?
>>  
>> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
>> 
>> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
>> 
>> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
>> 
>> Except that, I also cleaned up some code warnings from the IDE I used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add back final keyword and comments about where the tables are from

Anyone can help run Mach5 testing in case I missed something?

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From coffeys at openjdk.org  Mon Oct 10 19:23:51 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 10 Oct 2022 19:23:51 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v4]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <y4e8nEYTOQ4XjLUzOwtzKTQKImMO4yvitpmb5xpQRKk=.a16d72af-bf4c-4792-9a62-ac1437cd705f@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Address Oct 10 review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/f8faecf4..323938d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=02-03

  Stats: 22 lines in 6 files changed: 9 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Mon Oct 10 19:23:52 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 10 Oct 2022 19:23:52 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
Message-ID: <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>

On Mon, 10 Oct 2022 14:19:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/ProtectionDomain.java line 76:
>> 
>>> 74:     static class JavaSecurityAccessImpl implements JavaSecurityAccess {
>>> 75:         /* cache a copy for recording purposes */
>>> 76:         static Properties initialSecurityProperties;
>> 
>> This doesn't look very clean. Could the Security class hold the initial security properties and provide an accessor method that JavaSecurityAccess:getIinitialProperties could use?
>
> Agree, and alternatively, it seems cleaner to add a new SharedSecrets class for `java.security.Security` and remove the dependency on PD.

modified code to have Security class hold the initial properties and provided an accessor method

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Mon Oct 10 19:23:56 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 10 Oct 2022 19:23:56 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <o7TrYfjkQIrkZNh298CrsjG1huBZFuCsEMo6tIhqXEE=.6acdcc2a-a59f-4dbe-ba23-f56c05b5de1c@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <o7TrYfjkQIrkZNh298CrsjG1huBZFuCsEMo6tIhqXEE=.6acdcc2a-a59f-4dbe-ba23-f56c05b5de1c@github.com>
Message-ID: <Zuvegr4Pv59B6shXJosepTjILF-5PEzwNG7zzSZu0xI=.81f11cbd-a06f-422d-9b4c-cac0776ce391@github.com>

On Mon, 10 Oct 2022 07:19:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 29:
> 
>> 27: 
>> 28: import jdk.jfr.*;
>> 29: import jdk.jfr.internal.MirrorEvent;
> 
> Hello Sean, this `MirrorEvent` appears to be an unused import. Furthermore, as far as I know, in `core-libs` the `*` wildcard imports aren't typically used. I don't know if it's OK to use it here in the `jdk.jfr` module.

Thanks Jai - I removed the unused import and reverted to non-wildcard import use

> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 318:
> 
>> 316:                 InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
>> 317:                 e.key = (String) entry.getKey();
>> 318:                 e.value = (String) entry.getValue();
> 
> To avoid any (odd/unexpected) `ClassCastException` here, perhaps this loop can be changed to something like:
> 
> for (Set<String> name : p.stringPropertyNames()) {
>     InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
>     e.key = name;
>     e.value = p.getProperty(name);
> 
> Since this code anyway wants to deal with string key/values, this wouldn't introduce any functional change and yet at the same time prevent any unexpected/theoretical `ClassCastException`s

nice - wasn't aware of that method in Properties. Code updated.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From valeriep at openjdk.org  Mon Oct 10 19:41:48 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 10 Oct 2022 19:41:48 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine [v2]
In-Reply-To: <tEP06kT7ip19bgzxIl5jcZICxSXJcjxYy98zLqkdvvc=.cf6fb7d0-2d0e-476d-b77e-63750ed6b331@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
 <tEP06kT7ip19bgzxIl5jcZICxSXJcjxYy98zLqkdvvc=.cf6fb7d0-2d0e-476d-b77e-63750ed6b331@github.com>
Message-ID: <99KL2WIT8opFWXUUO4OmhXuQSuxjx-30y8flMf8jZFc=.2c703de9-8e93-4ae2-ab96-1ee68a1ab3c0@github.com>

On Mon, 10 Oct 2022 19:05:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Anyone can help run Mach5 testing in case I missed something?

Sure, I can help with that.

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From naoto at openjdk.org  Mon Oct 10 19:54:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Oct 2022 19:54:10 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>

On Mon, 10 Oct 2022 18:18:55 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.

Looks good overall. Some minor suggestions.

test/jdk/sun/security/tools/keytool/i18n.java line 62:

> 60:  * @library /test/lib
> 61:  * @run main/manual/othervm i18n zh CN
> 62:  */

Do you need to triplicate these `@test` tags? Would 3-lines of `@run` suffice?
Also setting the locale by `-Duser.language/country` and `getProperty` them in the main would be preferable to passing them as the test case arguments.

test/jdk/sun/security/tools/keytool/i18n.java line 250:

> 248:     private Thread currentThread = null;
> 249: 
> 250:     public static class DialogBuilder {

This seems to be a boilerplate for displaying the panel. Could this be separated from the test and converted into some library?

test/jdk/sun/security/tools/keytool/i18n.java line 334:

> 332:         } else if (args.length == 2) {
> 333:             Locale.setDefault(Locale.of(args[0], args[1]));
> 334:         }

Can be eliminated with the suggestion above.

test/jdk/sun/security/tools/keytool/i18n.java line 335:

> 333:             Locale.setDefault(Locale.of(args[0], args[1]));
> 334:         }
> 335:         final String LANG = Locale.getDefault().getDisplayLanguage();

Instead of `getDisplayLanguage()`, it should issue `getDisplayName()`, as for `zh-CN` case, it simply displays `Chinese` in the current impl. It's ambiguous whether it is simplified or traditional.
Also, `LANG` should be lowercase, as it is not a constant.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From mpowers at openjdk.org  Mon Oct 10 20:52:01 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 10 Oct 2022 20:52:01 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v4]
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <yYldUK0r3k2qibXIpTMZFR_vFDQ37CuiPcJ0ZH0_SuM=.4c4c5cc7-aa49-417c-872d-250554ba2553@github.com>

> https://bugs.openjdk.org/browse/JDK-8291974

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  Sean comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10206/files
  - new: https://git.openjdk.org/jdk/pull/10206/files/304134d7..b3698128

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10206&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10206&range=02-03

  Stats: 16 lines in 1 file changed: 3 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10206.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10206/head:pull/10206

PR: https://git.openjdk.org/jdk/pull/10206

From mullan at openjdk.org  Mon Oct 10 20:58:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Oct 2022 20:58:47 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
Message-ID: <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>

On Mon, 10 Oct 2022 19:19:44 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Agree, and alternatively, it seems cleaner to add a new SharedSecrets class for `java.security.Security` and remove the dependency on PD.
>
> modified code to have Security class hold the initial properties and provided an accessor method

What about creating a new `JavaSecurityPropertiesAccess` class and moving the accessor method there? It seems it would be cleaner to remove the dependency on PD in the long run.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mullan at openjdk.org  Mon Oct 10 21:06:51 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Oct 2022 21:06:51 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v4]
In-Reply-To: <yYldUK0r3k2qibXIpTMZFR_vFDQ37CuiPcJ0ZH0_SuM=.4c4c5cc7-aa49-417c-872d-250554ba2553@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <yYldUK0r3k2qibXIpTMZFR_vFDQ37CuiPcJ0ZH0_SuM=.4c4c5cc7-aa49-417c-872d-250554ba2553@github.com>
Message-ID: <sk38waNY2ZLD6EZ1k5th5T6lElJ5CVI3Q_ckpFO3gPE=.e5df5177-bcfc-4d75-89d2-484e3ede54d9@github.com>

On Mon, 10 Oct 2022 20:52:01 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sean comments

test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 35:

> 33: import java.util.*;
> 34: 
> 35: public class Serial2 implements java.io.Serializable {

I don't see why this needs to implement `Serializable` (I see you probably used the other `Serial.java` test in this directory as a template. I don't think that needs it either, but you can leave that as is for now).

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From bhuang at openjdk.org  Mon Oct 10 21:53:49 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 21:53:49 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion
Message-ID: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>

This task converts 5 manual tests to automated tests.

sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
sun/security/provider/PolicyParser/ExtDirsChange.java 
sun/security/provider/PolicyParser/ExtDirs.java 
java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
javax/crypto/CryptoPermissions/InconsistentEntries.java

-------------

Commit messages:
 - Converted security manual tests to automated tests.

Changes: https://git.openjdk.org/jdk/pull/10637/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295087
  Stats: 210 lines in 13 files changed: 100 ins; 37 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From mpowers at openjdk.org  Mon Oct 10 21:59:56 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 10 Oct 2022 21:59:56 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v3]
In-Reply-To: <zRGN-rDLApIaySKsTIeZ-fkq2SVnUNS0IZCzWdw_0uA=.ec302d9f-d506-49b9-a902-c91544098ec2@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <I2BsL98FtFc_Xo9AvKgcNgVJZ5rEi9iaqOfCGAob8VE=.a8f01d3f-130c-469f-adba-e006bd5f7360@github.com>
 <zRGN-rDLApIaySKsTIeZ-fkq2SVnUNS0IZCzWdw_0uA=.ec302d9f-d506-49b9-a902-c91544098ec2@github.com>
Message-ID: <qtXevAeFWUQHFx3FMhtXicxzQssrU1-PH3WCxKt-T18=.f9cacdd0-cb18-4a87-a1ab-ac935ffa0984@github.com>

On Mon, 10 Oct 2022 16:48:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Text Blocks
>>  - long line
>
> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 29:
> 
>> 27:  * @summary     PrivateCredentialPermission should not use local variable to enable debugging
>> 28:  *              implementation-dependent class
>> 29:  * @run main/othervm/policy=Serial.policy Serial2
> 
> I think you can remove `main/othervm/policy=Serial.policy` (actually you can remove the whole `@run` line then).
> The policy argument causes the test to run with a SecurityManager enabled, and there isn't any reason that this test needs to do that AFAICT. Also that policy file is for other tests in this directory for accessing the file system or JAAS credentials, which you are not accessing in this test.

fixed

> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 58:
> 
>> 56: 
>> 57:             // Deserialize input stream and create a new object.
>> 58:             ObjectInputStream ois = new ObjectInputStream(is);
> 
> Use try-with resources here so the input stream is automatically closed even if there are exceptions.

using try-with resources

> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 61:
> 
>> 59:             PrivateCredentialPermission pcp2 =
>> 60:                     (PrivateCredentialPermission)ois.readObject();
>> 61:             is.close();
> 
> Not necessary as BAIS.close() is a no-op.

removed

> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 79:
> 
>> 77:         } catch (Exception e) {
>> 78:             e.printStackTrace();
>> 79:             throw new SecurityException("Serial test failed");
> 
> If you include e as the cause (2nd argument) of `SecurityException` then you don't need to print the stack trace on line 78.

fixed

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From bhuang at openjdk.org  Mon Oct 10 22:27:37 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 22:27:37 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
Message-ID: <oG1gymJ04OGUoOFaoTXnocMaWsQH6ZZHnpqWr8xNf90=.81642b67-c620-4c87-80d9-5c9cb121ddd5@github.com>

On Mon, 10 Oct 2022 19:45:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.
>
> test/jdk/sun/security/tools/keytool/i18n.java line 62:
> 
>> 60:  * @library /test/lib
>> 61:  * @run main/manual/othervm i18n zh CN
>> 62:  */
> 
> Do you need to triplicate these `@test` tags? Would 3-lines of `@run` suffice?
> Also setting the locale by `-Duser.language/country` and `getProperty` them in the main would be preferable to passing them as the test case arguments.

Sure, I can make a change to use the system property. 
Regarding your first question, a test with multiple 'run' fails and terminates on the first test failure. So I would prefer to have multiple tests rather than multiple 'run' in a single test that it allows jtreg to run all the tests independently.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From bhuang at openjdk.org  Mon Oct 10 22:29:56 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 22:29:56 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
Message-ID: <6d1N8oLNhw4y1MVIxbJmmsKRegc5cHC0DrCrvgDiga4=.4307cd90-2a64-4aab-9ffb-f9ffd295cb71@github.com>

On Mon, 10 Oct 2022 19:47:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.
>
> test/jdk/sun/security/tools/keytool/i18n.java line 250:
> 
>> 248:     private Thread currentThread = null;
>> 249: 
>> 250:     public static class DialogBuilder {
> 
> This seems to be a boilerplate for displaying the panel. Could this be separated from the test and converted into some library?

Sure, we can move this code to the library as there is no test code in it.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From xuelei at openjdk.org  Mon Oct 10 23:01:17 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 23:01:17 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <5na2V7FIy4G-YTiXKJcvedTts0lgkZHheSx7eMyXKtg=.815c3626-98e8-47f0-bcf5-1875fd0f3077@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Close it for now.  I will open it again when I have a solution for better performance.

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From xuelei at openjdk.org  Mon Oct 10 23:01:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 23:01:19 GMT
Subject: Withdrawn: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <TqtW2Lf6ZDNbox8kzJ5qV77mPy949LD9jcPNIR3dgZc=.426bc5a9-ebcf-4b10-9dc8-9795e52587f2@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From bhuang at openjdk.org  Mon Oct 10 23:23:00 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 23:23:00 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10635/files
  - new: https://git.openjdk.org/jdk/pull/10635/files/7812f3c4..a36cd005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=00-01

  Stats: 203 lines in 2 files changed: 113 ins; 78 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From valeriep at openjdk.org  Tue Oct 11 00:09:17 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Oct 2022 00:09:17 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine [v2]
In-Reply-To: <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
Message-ID: <wzuOONqbkU35bKBQWbsx544HqEs8ZFtVIKDROR9esUE=.3b42c25e-5085-475f-9a13-5814253e2163@github.com>

On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the code clean up reviewed?
>>  
>> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
>> 
>> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
>> 
>> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
>> 
>> Except that, I also cleaned up some code warnings from the IDE I used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add back final keyword and comments about where the tables are from

Mach5 result looks ok. There is one unexpected test failure but it seems unrelated (https://mach5.us.oracle.com:10060/api/v1/results/vpeng-jdkOh-20221010-1957-37280778-open_test_lib-test-linux-x64-122-1665432715-16/log) . So, it should be fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From djelinski at openjdk.org  Tue Oct 11 07:31:19 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Oct 2022 07:31:19 GMT
Subject: RFR: 8294997: Improve ECC math operations
Message-ID: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>

This patch rewrites some BigInteger and curve point operations used in EC calculations:
- coefficient * 2^power is equivalent to coefficient << power
- number mod 2^n is equivalent to number & (2^n-1)
- pair of IntegerModuloP operations:
t2 = t1+t1
t1 = t1+t2
is equivalent to t1=t1*3, which is now implemented more efficiently.

Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:

Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s

After:

Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s

Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).

Tier1-3 tests continue to pass.

-------------

Commit messages:
 - Remove commented out code
 - Simplify multiplication
 - Simplify mod
 - Simplify math
 - Remove biginteger modulo operation

Changes: https://git.openjdk.org/jdk/pull/10614/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294997
  Stats: 50 lines in 6 files changed: 2 ins; 23 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/10614.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10614/head:pull/10614

PR: https://git.openjdk.org/jdk/pull/10614

From aturbanov at openjdk.org  Tue Oct 11 08:02:24 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 11 Oct 2022 08:02:24 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v4]
In-Reply-To: <y4e8nEYTOQ4XjLUzOwtzKTQKImMO4yvitpmb5xpQRKk=.a16d72af-bf4c-4792-9a62-ac1437cd705f@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <y4e8nEYTOQ4XjLUzOwtzKTQKImMO4yvitpmb5xpQRKk=.a16d72af-bf4c-4792-9a62-ac1437cd705f@github.com>
Message-ID: <eKCWbI-k7k5lP7nvJT-uuObDQI1mn3yGDsnpwx4Iumk=.509eb66a-2949-4a06-bc23-9623c6fb1a0c@github.com>

On Mon, 10 Oct 2022 19:23:51 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Oct 10 review comments

test/lib/jdk/test/lib/jfr/EventNames.java line 195:

> 193:     public final static String X509Certificate = PREFIX + "X509Certificate";
> 194:     public final static String X509Validation = PREFIX + "X509Validation";
> 195:     public final static String InitialSecurityProperty = PREFIX + "InitialSecurityProperty";

Let's unify order of modifiers in this file. Some fields use `public final static` and some `public static final`

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From duke at openjdk.org  Tue Oct 11 08:42:31 2022
From: duke at openjdk.org (jquanC)
Date: Tue, 11 Oct 2022 08:42:31 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v5]
In-Reply-To: <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com>
Message-ID: <8nlO_dEtEB_DjbZzyRZeo7b3oDF8R0Hcpp1WjSG-zxM=.640e2e1b-4564-40d2-95df-0e8c45d42d65@github.com>

On Sat, 23 Jul 2022 05:29:07 GMT, jquanC <duke at openjdk.org> wrote:

>> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
>> 
>> 
>> /**
>>  * Private helper routine for writing DER encoded string values.
>>  * @param s the string to write
>>  * @param stringTag one of the DER string tags that indicate which
>>  * encoding should be used to write the string out.
>>  * @param enc the name of the encoder that should be used corresponding
>>  * to the above tag.
>>  */
>> private void writeString(String s, byte stringTag, Charset charset) throws IOException
>> 
>> The parameter is charset, but not enc.
>> 
>> 
>> /**
>>  * Marshals a DER integer on the output stream.
>>  *
>>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>>  */
>> public void putInteger(byte[] buf) throws IOException {
>> 
>> The parameter is buf, but not i.
>
> jquanC has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290775: Some doc errors in DerOutputStream.java  Update: add a modification and improve an expression according to the specification

Thanks for your valuable advice. I will continue to improve.
Best wishes!




------------------&nbsp;????&nbsp;------------------
???:                                                                                                                        "openjdk/jdk"                                                                                    ***@***.***&gt;;
????:&nbsp;2022?7?22?(???) ??1:25
***@***.***&gt;;
***@***.******@***.***&gt;;
??:&nbsp;Re: [openjdk/jdk] 8290775: Some doc errors in DerOutputStream.java (PR #9585)





  
On the second point, I have some doubts. 1) Here don't need to add @.*** charset" because it's clear to everyone? @.*** enc" does not seem to be used in the method. Shouldn't it be deleted?
  
Sorry for the confusing.
 
I think it is fine to update the "param enc" to "param charset", but it may be not necessary to update the parameter description.  With "parameter description", I refer to this part, "the name of the encoder that should be used corresponding to the above tag".
 
The parameter description may be still confusing to someone, as the 'the name of the encoder' is not well-defined here.  Maybe, it could be simplified as "the charset that ..."
 
Here is the proposed update:
  
 * @param enc the name of the encoder that should be used corresponding  
 
  
to the above tag.
  
   
  
@param charset the specified character set encodes a string into a
  
 
  
sequence of bytes using
  
  
I may use an update like :
  
 * @param enc the name of the encoder that should be used corresponding  
 
  
to the above tag.
  
   
  
@param charset the charset that is should used corresponding to the
  
 
  
above tag.
  
  
?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

-------------

PR: https://git.openjdk.org/jdk/pull/9585

From coffeys at openjdk.org  Tue Oct 11 11:30:28 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 11 Oct 2022 11:30:28 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
Message-ID: <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>

On Mon, 10 Oct 2022 20:54:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> modified code to have Security class hold the initial properties and provided an accessor method
>
> What about creating a new `JavaSecurityPropertiesAccess` class and moving the accessor method there? It seems it would be cleaner to remove the dependency on PD in the long run.

@seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 

In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mullan at openjdk.org  Tue Oct 11 12:41:26 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Oct 2022 12:41:26 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
 <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
Message-ID: <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>

On Tue, 11 Oct 2022 11:28:10 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> What about creating a new `JavaSecurityPropertiesAccess` class and moving the accessor method there? It seems it would be cleaner to remove the dependency on PD in the long run.
>
> @seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 
> 
> In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?

Maybe I am missing something. If this JFR event is enabled, and the properties have not yet been accessed, then it seems ok for JFR to load the `Security` class when JFR is started since the user is interested in this event.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Tue Oct 11 13:13:45 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 11 Oct 2022 13:13:45 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
 <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
 <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
Message-ID: <gvBuel-mv6ErQQAZ7Cy16yj4aY_gnnKYn9heMJDPfoY=.707c8b59-4f66-4828-8ee3-cbb0e215412f@github.com>

On Tue, 11 Oct 2022 12:39:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 
>> 
>> In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?
>
> Maybe I am missing something. If this JFR event is enabled, and the properties have not yet been accessed, then it seems ok for JFR to load the `Security` class when JFR is started since the user is interested in this event.

My own thoughts here would be that the JFR event system should try and avoid side effects in such areas. If the Security class hasn't been loaded at time of recording, then I'd argue that the number InitialSecurityProperty events should be zero. (which is not possible at the moment since JFR does trigger Security class loading itself anyway)

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From weijun at openjdk.org  Tue Oct 11 15:19:21 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Oct 2022 15:19:21 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
Message-ID: <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>

On Mon, 10 Oct 2022 23:23:00 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

I have a question, why must this test be manual? Can't we compare the localized texts?

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From djelinski at openjdk.org  Tue Oct 11 16:10:44 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Oct 2022 16:10:44 GMT
Subject: RFR: 8277970: Test
 jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails
 with "tag mismatch"
Message-ID: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>

This patch fixes the issue where a thread doing SSLSocket.close() could destroy the read cipher while it was used by another thread doing SSLSocket.read().

The reported issue was triggered by SSLSocket.close() calling inputRecord.close() -> readCipher.dispose() -> cipher.doFinal() on an AES/GCM cipher between `updateAAD` and `doFinal`; this changed the cipher state and caused the doFinal call to fail.

The issue for AES/GCM (and all other AEAD ciphers) was fixed by JDK-8294848; this patch addresses the non-AEAD ciphers.

Tier1-3 clean. Also, no failures after 1200 repetitions of NoInvalidateSocketException.

-------------

Commit messages:
 - Ensure we do not destroy cipher while using it

Changes: https://git.openjdk.org/jdk/pull/10657/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10657&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277970
  Stats: 7 lines in 2 files changed: 6 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10657.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10657/head:pull/10657

PR: https://git.openjdk.org/jdk/pull/10657

From xuelei at openjdk.org  Tue Oct 11 16:24:12 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 11 Oct 2022 16:24:12 GMT
Subject: RFR: 8294821: Class load improvement for AES crypto engine [v2]
In-Reply-To: <wzuOONqbkU35bKBQWbsx544HqEs8ZFtVIKDROR9esUE=.3b42c25e-5085-475f-9a13-5814253e2163@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
 <-Ri89cNR-qZ8RlmBhGmtYvB1FTo1dN3xQ_BD8sSnFdQ=.637bb9d6-e8a7-48ff-b2ea-0391ba8de456@github.com>
 <wzuOONqbkU35bKBQWbsx544HqEs8ZFtVIKDROR9esUE=.3b42c25e-5085-475f-9a13-5814253e2163@github.com>
Message-ID: <y_76KUzVLQ_9TXiUhIyKC5ozyVW3g2G71OqS5KbhPYk=.0458ffb3-830a-4c9f-b980-deb4ae5725a3@github.com>

On Tue, 11 Oct 2022 00:05:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Mach5 result looks ok. There is one unexpected test failure but it seems unrelated (https://mach5.us.oracle.com:10060/api/v1/results/vpeng-jdkOh-20221010-1957-37280778-open_test_lib-test-linux-x64-122-1665432715-16/log) . So, it should be fine.

@valeriepeng Thank you very much!

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From xuelei at openjdk.org  Tue Oct 11 16:25:41 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 11 Oct 2022 16:25:41 GMT
Subject: Integrated: 8294821: Class load improvement for AES crypto engine
In-Reply-To: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
References: <0cLTDmtH0Wf6t6YjLUE6WT0i1aSl55B1sI-kRiA0gsE=.5cb58485-1c2f-4a55-a538-466a05d827cd@github.com>
Message-ID: <UgYXtRAvVI82j8pQumpMYWbDzqK02omDVvlcl770UeA=.7f878be5-ce1e-4aa0-bce8-e0127d29dadb@github.com>

On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the code clean up reviewed?
>  
> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
> 
> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
> 
> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
> 
> Except that, I also cleaned up some code warnings from the IDE I used.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: 3c7ae122
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c7ae1225f0d5575fd927a9b76fb40dc30e208cd
Stats:     1168 lines in 1 file changed: 957 ins; 203 del; 8 mod

8294821: Class load improvement for AES crypto engine

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.org/jdk/pull/10568

From duke at openjdk.org  Tue Oct 11 16:28:12 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 11 Oct 2022 16:28:12 GMT
Subject: RFR: 8294997: Improve ECC math operations
In-Reply-To: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
Message-ID: <-Bo8rvaYhDcHMXyMX3pHH08SdLVwOIkIw4WL2boLkW8=.259acf33-4b17-491e-9466-cbba4de9482e@github.com>

On Fri, 7 Oct 2022 21:11:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch rewrites some BigInteger and curve point operations used in EC calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP operations:
> t2 = t1+t1
> t1 = t1+t2
> is equivalent to t1=t1*3, which is now implemented more efficiently.
> 
> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
> 
> After:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
> 
> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
> 
> Tier1-3 tests continue to pass.

In src/java.base/share/classes/sun/security/provider/DSAParameterGenerator.java there a still some mod(Biginteger.TWO.pow(...)) type subexpressions, e.g. in lines 214, 220, 231, 240 (not that it matters much).

-------------

PR: https://git.openjdk.org/jdk/pull/10614

From jnimeh at openjdk.org  Tue Oct 11 16:46:14 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 11 Oct 2022 16:46:14 GMT
Subject: RFR: 8277970: Test
 jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails
 with "tag mismatch"
In-Reply-To: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
References: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
Message-ID: <IX5OSqVLVK1sGJ6RKNMr16Zb2sn1i7IqvNjWu0_FYEw=.51c61b81-2621-40c6-bf72-22f64eda45d8@github.com>

On Tue, 11 Oct 2022 14:38:35 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the issue where a thread doing SSLSocket.close() could destroy the read cipher while it was used by another thread doing SSLSocket.read().
> 
> The reported issue was triggered by SSLSocket.close() calling inputRecord.close() -> readCipher.dispose() -> cipher.doFinal() on an AES/GCM cipher between `updateAAD` and `doFinal`; this changed the cipher state and caused the doFinal call to fail.
> 
> The issue for AES/GCM (and all other AEAD ciphers) was fixed by JDK-8294848; this patch addresses the non-AEAD ciphers.
> 
> Tier1-3 clean. Also, no failures after 1200 repetitions of NoInvalidateSocketException.

Overall the changes look clean.  Thanks for taking care of this.  A couple notes:

- Per our side discussion, can you please remove noreg-self from the bug and add this bug ID to NoInvalidateSocketException.java
- Can you please do a large-iteration run on test/jdk/sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java

I'll approve once that multi-iteration run comes back clean.

-------------

PR: https://git.openjdk.org/jdk/pull/10657

From naoto at openjdk.org  Tue Oct 11 17:08:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Oct 2022 17:08:41 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
 <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
Message-ID: <TXZt3gfVDzpleZaEp_Qt_cjO2YVByYdiBgFbNpnpVOY=.6ea536d2-245d-4374-ab7d-ab256eae5ae1@github.com>

On Tue, 11 Oct 2022 15:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I have a question, why must this test be manual? Can't we compare the localized texts?

Thought about that, but it could be a nuisance if we compared word-to-word translations, considering the situation if an engineer made some changes in the English resource bundle, but l10n may not come at the same time which is guaranteed to fail.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From bhuang at openjdk.org  Tue Oct 11 17:08:41 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 11 Oct 2022 17:08:41 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <TXZt3gfVDzpleZaEp_Qt_cjO2YVByYdiBgFbNpnpVOY=.6ea536d2-245d-4374-ab7d-ab256eae5ae1@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
 <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
 <TXZt3gfVDzpleZaEp_Qt_cjO2YVByYdiBgFbNpnpVOY=.6ea536d2-245d-4374-ab7d-ab256eae5ae1@github.com>
Message-ID: <Hznob_JJlKWR3g7hg3cCf8rsWmWMkxjXMW1BgHg-ruo=.fb14c4fc-609f-4b43-9124-3b8db19b2518@github.com>

On Tue, 11 Oct 2022 17:03:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I have a question, why must this test be manual? Can't we compare the localized texts?

@wangweij Good question. We can definitely compare the localized texts at least some keywords. The fact that automation is one of the goals of this task. In terms of localization, perhaps in our tests we can reuse the resource bundles implemented in these tools to turn english texts into localized texts.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From xuelei at openjdk.org  Tue Oct 11 17:52:18 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 11 Oct 2022 17:52:18 GMT
Subject: RFR: 8294997: Improve ECC math operations
In-Reply-To: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
Message-ID: <LFGRTvDblWch9YmcId_w5L61hwfKWiGwyqybJFHL3jM=.0d5b0ac0-985a-4969-a812-e77db4f1d205@github.com>

On Fri, 7 Oct 2022 21:11:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch rewrites some BigInteger and curve point operations used in EC calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP operations:
> t2 = t1+t1
> t1 = t1+t2
> is equivalent to t1=t1*3, which is now implemented more efficiently.
> 
> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
> 
> After:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
> 
> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
> 
> Tier1-3 tests continue to pass.

src/java.base/share/classes/sun/security/provider/DSAParameterGenerator.java line 240:

> 238:                     W = W.add(V[i].shiftLeft(i * outLen));
> 239:                 }
> 240:                 W = W.add((V[n].mod(BigInteger.TWO.pow(b)))

Did you want to update the "BigInteger.TWO.pow(b)" as well?

src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 332:

> 330: 
> 331:     protected void setLimbsValuePositive(BigInteger v, long[] limbs) {
> 332:         assert bitsPerLimb < 32;

I may have this assert in the constructors as it is a final field.

-------------

PR: https://git.openjdk.org/jdk/pull/10614

From djelinski at openjdk.org  Tue Oct 11 18:53:54 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Oct 2022 18:53:54 GMT
Subject: RFR: 8277970: Test
 jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails
 with "tag mismatch" [v2]
In-Reply-To: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
References: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
Message-ID: <WjRu-ysvg2jUWYMAf-Xf4b1fwei65JXpV5bQL-a7DoY=.15df31a0-010c-4028-b44c-0e575804d5aa@github.com>

> This patch fixes the issue where a thread doing SSLSocket.close() could destroy the read cipher while it was used by another thread doing SSLSocket.read().
> 
> The reported issue was triggered by SSLSocket.close() calling inputRecord.close() -> readCipher.dispose() -> cipher.doFinal() on an AES/GCM cipher between `updateAAD` and `doFinal`; this changed the cipher state and caused the doFinal call to fail.
> 
> The issue for AES/GCM (and all other AEAD ciphers) was fixed by JDK-8294848; this patch addresses the non-AEAD ciphers.
> 
> Tier1-3 clean. Also, no failures after 1200 repetitions of NoInvalidateSocketException.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Add bug ID

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10657/files
  - new: https://git.openjdk.org/jdk/pull/10657/files/be7d6ae1..c518ab09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10657&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10657&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10657.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10657/head:pull/10657

PR: https://git.openjdk.org/jdk/pull/10657

From djelinski at openjdk.org  Tue Oct 11 19:04:17 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Oct 2022 19:04:17 GMT
Subject: RFR: 8277970: Test
 jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails
 with "tag mismatch" [v2]
In-Reply-To: <WjRu-ysvg2jUWYMAf-Xf4b1fwei65JXpV5bQL-a7DoY=.15df31a0-010c-4028-b44c-0e575804d5aa@github.com>
References: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
 <WjRu-ysvg2jUWYMAf-Xf4b1fwei65JXpV5bQL-a7DoY=.15df31a0-010c-4028-b44c-0e575804d5aa@github.com>
Message-ID: <X_MbpBxf_OWrePd9fTbpvJkqBcJCe-VdXFQLVe4Vm7Y=.90f6444d-501e-4238-9e36-18e47f703765@github.com>

On Tue, 11 Oct 2022 18:53:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the issue where a thread doing SSLSocket.close() could destroy the read cipher while it was used by another thread doing SSLSocket.read().
>> 
>> The reported issue was triggered by SSLSocket.close() calling inputRecord.close() -> readCipher.dispose() -> cipher.doFinal() on an AES/GCM cipher between `updateAAD` and `doFinal`; this changed the cipher state and caused the doFinal call to fail.
>> 
>> The issue for AES/GCM (and all other AEAD ciphers) was fixed by JDK-8294848; this patch addresses the non-AEAD ciphers.
>> 
>> Tier1-3 clean. Also, no failures after 1200 repetitions of NoInvalidateSocketException.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug ID

Bug ID added, JBS updated.
Finished running 1200 iterations (300*4 platforms) of test/jdk/sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java, all passed.

-------------

PR: https://git.openjdk.org/jdk/pull/10657

From valeriep at openjdk.org  Tue Oct 11 19:30:34 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 11 Oct 2022 19:30:34 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 NSS TLS server [v2]
In-Reply-To: <tZxcN3YPjglppTld3-iwPoqyr4Bxf_XGcLMoUJsHPk0=.fb4b824b-3ba0-4dce-863c-90fe9a34a562@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
 <tZxcN3YPjglppTld3-iwPoqyr4Bxf_XGcLMoUJsHPk0=.fb4b824b-3ba0-4dce-863c-90fe9a34a562@github.com>
Message-ID: <1ULFN7CLsB6iO5kPNqPTmJbnRDneoxq_zs3TETm1-AY=.f7af2eed-a6c2-40ec-b1d3-a9a429e2f007@github.com>

On Fri, 7 Oct 2022 07:42:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
>> 
>> Verified that:
>> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
>> - The same server continues to function correctly
>> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
>> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check if mac keys are present

Changes look fine, just have one nit.
Thanks for finding and fixing this!

BTW, if this NSS behavior is still present in newer NSS releases, we should raise the priority of this and backport it.

test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java line 150:

> 148:                         clientRandom, serverRandom, cipherAlgorithm,
> 149:                         keyLength, expandedKeyLength, ivLength, macLength,
> 150:                         hashAlgorithm, -1, -1);

nit: add a comment that PKCS11 does not use the prfHashLength and prfBlockSize fields. So that's why this test does not set the values as in the com/sun/crypto/provider/TLS/TestKeyMaterial.java file.

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10594

From jnimeh at openjdk.org  Tue Oct 11 19:36:25 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 11 Oct 2022 19:36:25 GMT
Subject: RFR: 8277970: Test
 jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails
 with "tag mismatch" [v2]
In-Reply-To: <WjRu-ysvg2jUWYMAf-Xf4b1fwei65JXpV5bQL-a7DoY=.15df31a0-010c-4028-b44c-0e575804d5aa@github.com>
References: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
 <WjRu-ysvg2jUWYMAf-Xf4b1fwei65JXpV5bQL-a7DoY=.15df31a0-010c-4028-b44c-0e575804d5aa@github.com>
Message-ID: <gaclBnWMy0yQ34pT0fTaksp55u5g8ZOe05Dl4cxXAR8=.06dc5fe5-a46d-46c3-9eb5-239fdbaf0c09@github.com>

On Tue, 11 Oct 2022 18:53:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the issue where a thread doing SSLSocket.close() could destroy the read cipher while it was used by another thread doing SSLSocket.read().
>> 
>> The reported issue was triggered by SSLSocket.close() calling inputRecord.close() -> readCipher.dispose() -> cipher.doFinal() on an AES/GCM cipher between `updateAAD` and `doFinal`; this changed the cipher state and caused the doFinal call to fail.
>> 
>> The issue for AES/GCM (and all other AEAD ciphers) was fixed by JDK-8294848; this patch addresses the non-AEAD ciphers.
>> 
>> Tier1-3 clean. Also, no failures after 1200 repetitions of NoInvalidateSocketException.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug ID

Thanks for doing that additional focused test on the other closure/read specific test.  This looks good to me.

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10657

From rriggs at openjdk.org  Tue Oct 11 20:02:06 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Oct 2022 20:02:06 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <DR-uyBBpPw3Axz2hKRE5BW5atXyhNR7fL738Pwig5Zs=.4580adaf-6bc8-4fca-bba9-d570d7809a59@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10578

From xuelei at openjdk.org  Tue Oct 11 20:35:22 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 11 Oct 2022 20:35:22 GMT
Subject: RFR: 8277970: Test
 jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails
 with "tag mismatch" [v2]
In-Reply-To: <WjRu-ysvg2jUWYMAf-Xf4b1fwei65JXpV5bQL-a7DoY=.15df31a0-010c-4028-b44c-0e575804d5aa@github.com>
References: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
 <WjRu-ysvg2jUWYMAf-Xf4b1fwei65JXpV5bQL-a7DoY=.15df31a0-010c-4028-b44c-0e575804d5aa@github.com>
Message-ID: <xsRjYWKp7OVLvKXweX1BtMD0XS80yLzm927I1gANT08=.3f7f01a8-0be2-4b0c-91b6-4ce7fda21ede@github.com>

On Tue, 11 Oct 2022 18:53:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the issue where a thread doing SSLSocket.close() could destroy the read cipher while it was used by another thread doing SSLSocket.read().
>> 
>> The reported issue was triggered by SSLSocket.close() calling inputRecord.close() -> readCipher.dispose() -> cipher.doFinal() on an AES/GCM cipher between `updateAAD` and `doFinal`; this changed the cipher state and caused the doFinal call to fail.
>> 
>> The issue for AES/GCM (and all other AEAD ciphers) was fixed by JDK-8294848; this patch addresses the non-AEAD ciphers.
>> 
>> Tier1-3 clean. Also, no failures after 1200 repetitions of NoInvalidateSocketException.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug ID

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10657

From bhuang at openjdk.org  Wed Oct 12 01:42:11 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 01:42:11 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
 <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
Message-ID: <t0Le2-UKI7k4Bf3ZerhkW_uq-GRmSPPzxStm--dJd8o=.9319753f-bfd7-4612-bf47-0a49b98fbcb1@github.com>

On Tue, 11 Oct 2022 15:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>
> I have a question, why must this test be manual? Can't we compare the localized texts?

Hi @wangweij, I have a discussion with @naotoj about automating this test. Here is a summary.

1. We can't hard code localized texts into the test and compare to the localized message form the tool. The main reason is mentioned above by @naotoj. Another reason is that localization sometimes may come in slightly different, correctness of translation is not the goal of this test.

2. We can't do a word-to-word comparison. But even so, we can't rely on the same resource bundle used by the tools for localization validation. It provokes a risk that test may fail to detect any localization error in the tool as they use the same mechanism.

3. It makes a bit more sense for this test being a manual test because it matches the look-and-feel criteria. With someone looking into the result, at least it can raise a flag if something doesn?t look right. And only engineers can do this.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From ihse at openjdk.org  Wed Oct 12 09:52:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 09:52:26 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
Message-ID: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>

Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

-------------

Commit messages:
 - 8295205: Add jcheck whitespace checking for markdown files

Changes: https://git.openjdk.org/jdk/pull/10671/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10671&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295205
  Stats: 34 lines in 9 files changed: 0 ins; 0 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/10671.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10671/head:pull/10671

PR: https://git.openjdk.org/jdk/pull/10671

From djelinski at openjdk.org  Wed Oct 12 12:13:20 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Oct 2022 12:13:20 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 NSS TLS server [v3]
In-Reply-To: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
Message-ID: <347z_2TAvP6GBk6b2th9LSAjG2ayTK0eJsc2JFmmrTg=.eb7a3e10-3b1a-4801-993d-0494741d0b98@github.com>

> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
> 
> Verified that:
> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
> - The same server continues to function correctly
> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about unused parameters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10594/files
  - new: https://git.openjdk.org/jdk/pull/10594/files/fdbe559f..4bb0db7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10594&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10594&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10594.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10594/head:pull/10594

PR: https://git.openjdk.org/jdk/pull/10594

From djelinski at openjdk.org  Wed Oct 12 12:16:12 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Oct 2022 12:16:12 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 NSS TLS server [v2]
In-Reply-To: <tZxcN3YPjglppTld3-iwPoqyr4Bxf_XGcLMoUJsHPk0=.fb4b824b-3ba0-4dce-863c-90fe9a34a562@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
 <tZxcN3YPjglppTld3-iwPoqyr4Bxf_XGcLMoUJsHPk0=.fb4b824b-3ba0-4dce-863c-90fe9a34a562@github.com>
Message-ID: <uZhOqsXcOzkzAO54NGhV3EEMLROV_QSxFkIUntFx7ug=.200ee4ac-7a56-458f-86e0-956a07e27fe8@github.com>

On Fri, 7 Oct 2022 07:42:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
>> 
>> Verified that:
>> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
>> - The same server continues to function correctly
>> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
>> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check if mac keys are present

Thanks for the review! Comment added.

I was unable to find any working Windows NSS binaries that are less than 3 years old; apparently there are no official builds. I tried using Firefox's NSS, but for some reason Java couldn't load them.
I'll see if I can find a Linux distro with something more recent.

-------------

PR: https://git.openjdk.org/jdk/pull/10594

From djelinski at openjdk.org  Wed Oct 12 12:35:05 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Oct 2022 12:35:05 GMT
Subject: RFR: 8294997: Improve ECC math operations
In-Reply-To: <LFGRTvDblWch9YmcId_w5L61hwfKWiGwyqybJFHL3jM=.0d5b0ac0-985a-4969-a812-e77db4f1d205@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
 <LFGRTvDblWch9YmcId_w5L61hwfKWiGwyqybJFHL3jM=.0d5b0ac0-985a-4969-a812-e77db4f1d205@github.com>
Message-ID: <ktjelmja2AIORjUVUi4kllkvQ-FmOW8XaYMcfmJWG6k=.005079f3-4dfd-4b38-be43-99eba0b45272@github.com>

On Tue, 11 Oct 2022 17:30:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This patch rewrites some BigInteger and curve point operations used in EC calculations:
>> - coefficient * 2^power is equivalent to coefficient << power
>> - number mod 2^n is equivalent to number & (2^n-1)
>> - pair of IntegerModuloP operations:
>> t2 = t1+t1
>> t1 = t1+t2
>> is equivalent to t1=t1*3, which is now implemented more efficiently.
>> 
>> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
>> 
>> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
>> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
>> 
>> After:
>> 
>> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
>> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
>> 
>> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
>> 
>> Tier1-3 tests continue to pass.
>
> src/java.base/share/classes/sun/security/provider/DSAParameterGenerator.java line 240:
> 
>> 238:                     W = W.add(V[i].shiftLeft(i * outLen));
>> 239:                 }
>> 240:                 W = W.add((V[n].mod(BigInteger.TWO.pow(b)))
> 
> Did you want to update the "BigInteger.TWO.pow(b)" as well?

Actually I think I'll revert the DSA changes; I'm not prepared to measure their effect at this moment.

> src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 332:
> 
>> 330: 
>> 331:     protected void setLimbsValuePositive(BigInteger v, long[] limbs) {
>> 332:         assert bitsPerLimb < 32;
> 
> I may have this assert in the constructors as it is a final field.

I added it here as a comment explaining why using intValue is okay here; it wouldn't serve its purpose if I moved it elsewhere.
Asserts are eliminated by the compiler by default anyway. If you think this assert shouldn't be here, I can replace it with a normal comment.

-------------

PR: https://git.openjdk.org/jdk/pull/10614

From djelinski at openjdk.org  Wed Oct 12 12:43:09 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Oct 2022 12:43:09 GMT
Subject: RFR: 8294997: Improve ECC math operations [v2]
In-Reply-To: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
Message-ID: <lKUUub_FNbsUlDJ1yq2HIT6HoqDPjAgV2WfzVO5IOhk=.eb076527-21d9-455f-b5f0-443dacc9d144@github.com>

> This patch rewrites some BigInteger and curve point operations used in EC calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP operations:
> t2 = t1+t1
> t1 = t1+t2
> is equivalent to t1=t1*3, which is now implemented more efficiently.
> 
> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
> 
> After:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
> 
> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
> 
> Tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - Revert DSA changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10614/files
  - new: https://git.openjdk.org/jdk/pull/10614/files/effc1a65..ecc7f41b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10614&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10614&range=00-01

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10614.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10614/head:pull/10614

PR: https://git.openjdk.org/jdk/pull/10614

From erikj at openjdk.org  Wed Oct 12 13:19:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:19:22 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <2owj2BREdvPlEo70s1rAvPywZeUPcimsej24fiAHyB4=.26f3a76b-0765-49ea-882d-591748bf1dcf@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

Thank you! Since I enabled visible whitespace in emacs (to be able to properly edit makefiles) editing any file where trailing whitespace isn't enforced makes my eyes bleed. :)

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10671

From ihse at openjdk.org  Wed Oct 12 13:34:32 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:34:32 GMT
Subject: Integrated: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <4JUC33BHEbQxyvmLXseCLGOGURYFR_6f0uHcyJaGUkc=.cb1528a9-2718-4bfc-9a70-dce6a9e4db00@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

This pull request has now been integrated.

Changeset: 86078423
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/860784238ea1f3e4a817fc3c28fb89cfee7549dd
Stats:     34 lines in 9 files changed: 0 ins; 0 del; 34 mod

8295205: Add jcheck whitespace checking for markdown files

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10671

From mpowers at openjdk.org  Wed Oct 12 14:02:13 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 12 Oct 2022 14:02:13 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 NSS TLS server [v3]
In-Reply-To: <347z_2TAvP6GBk6b2th9LSAjG2ayTK0eJsc2JFmmrTg=.eb7a3e10-3b1a-4801-993d-0494741d0b98@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
 <347z_2TAvP6GBk6b2th9LSAjG2ayTK0eJsc2JFmmrTg=.eb7a3e10-3b1a-4801-993d-0494741d0b98@github.com>
Message-ID: <a8TWpJG-VwNu2a0d2XlS7JEWVIt1M-nGquARBw1OOZQ=.0057680f-675c-4cc2-ab10-f818384d26d7@github.com>

On Wed, 12 Oct 2022 12:13:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
>> 
>> Verified that:
>> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
>> - The same server continues to function correctly
>> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
>> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about unused parameters

On Linux you might be able to use brew to get an older version of nss:

% brew tap-new $USER/local-nss
% brew extract --version=3.35 nss $USER/local-nss
% brew install nss at 3.35

-------------

PR: https://git.openjdk.org/jdk/pull/10594

From xuelei at openjdk.org  Wed Oct 12 14:59:24 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Oct 2022 14:59:24 GMT
Subject: RFR: 8294997: Improve ECC math operations [v2]
In-Reply-To: <lKUUub_FNbsUlDJ1yq2HIT6HoqDPjAgV2WfzVO5IOhk=.eb076527-21d9-455f-b5f0-443dacc9d144@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
 <lKUUub_FNbsUlDJ1yq2HIT6HoqDPjAgV2WfzVO5IOhk=.eb076527-21d9-455f-b5f0-443dacc9d144@github.com>
Message-ID: <OlxJDmKxRBlSqJTqqJU3SgbO13DeXPikGNg8aF2ibPE=.4dac0c0c-7162-40ae-8480-74a054862222@github.com>

On Wed, 12 Oct 2022 12:43:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch rewrites some BigInteger and curve point operations used in EC calculations:
>> - coefficient * 2^power is equivalent to coefficient << power
>> - number mod 2^n is equivalent to number & (2^n-1)
>> - pair of IntegerModuloP operations:
>> t2 = t1+t1
>> t1 = t1+t2
>> is equivalent to t1=t1*3, which is now implemented more efficiently.
>> 
>> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
>> 
>> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
>> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
>> 
>> After:
>> 
>> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
>> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
>> 
>> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Revert DSA changes

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10614

From xuelei at openjdk.org  Wed Oct 12 14:59:24 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Oct 2022 14:59:24 GMT
Subject: RFR: 8294997: Improve ECC math operations [v2]
In-Reply-To: <ktjelmja2AIORjUVUi4kllkvQ-FmOW8XaYMcfmJWG6k=.005079f3-4dfd-4b38-be43-99eba0b45272@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
 <LFGRTvDblWch9YmcId_w5L61hwfKWiGwyqybJFHL3jM=.0d5b0ac0-985a-4969-a812-e77db4f1d205@github.com>
 <ktjelmja2AIORjUVUi4kllkvQ-FmOW8XaYMcfmJWG6k=.005079f3-4dfd-4b38-be43-99eba0b45272@github.com>
Message-ID: <Oj-ggA45uEDYVYyBFFbrTStQA_ItnLj_R4ceu6dFu30=.cadccdb9-612d-41da-a772-2b40635ee8be@github.com>

On Wed, 12 Oct 2022 12:31:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 332:
>> 
>>> 330: 
>>> 331:     protected void setLimbsValuePositive(BigInteger v, long[] limbs) {
>>> 332:         assert bitsPerLimb < 32;
>> 
>> I may have this assert in the constructors as it is a final field.
>
> I added it here as a comment explaining why using intValue is okay here; it wouldn't serve its purpose if I moved it elsewhere.
> Asserts are eliminated by the compiler by default anyway. If you think this assert shouldn't be here, I can replace it with a normal comment.

The assert feature can be turned on.  I may prefer to use comment if that's the intention.  I'm fine to you want to keep it.

-------------

PR: https://git.openjdk.org/jdk/pull/10614

From xuelei at openjdk.org  Wed Oct 12 15:34:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Oct 2022 15:34:16 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit [v2]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <TAwK9hBDCv_-kKTS-MJWk0fBEJe2n33U-Ukgcoo3hMs=.882bfa2a-3992-4544-9eec-2eebf0692e02@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  reduce if needed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10624/files
  - new: https://git.openjdk.org/jdk/pull/10624/files/09747eb9..c2fa6e8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=00-01

  Stats: 196 lines in 5 files changed: 147 ins; 4 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

PR: https://git.openjdk.org/jdk/pull/10624

From djelinski at openjdk.org  Wed Oct 12 15:35:12 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Oct 2022 15:35:12 GMT
Subject: Integrated: 8277970: Test
 jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails
 with "tag mismatch"
In-Reply-To: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
References: <kuLOkoippRPIJAHjHPfKgp68gXqHyR15w7MSsrHiZaU=.442a6b6a-3306-4db0-8a47-57f7449b6699@github.com>
Message-ID: <i03ndMjF-wxr7IhIzqkNLd8bk6pY2GTernq7BBYBx_Q=.e635cbdf-df3d-49ff-b585-38589c5cc27a@github.com>

On Tue, 11 Oct 2022 14:38:35 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the issue where a thread doing SSLSocket.close() could destroy the read cipher while it was used by another thread doing SSLSocket.read().
> 
> The reported issue was triggered by SSLSocket.close() calling inputRecord.close() -> readCipher.dispose() -> cipher.doFinal() on an AES/GCM cipher between `updateAAD` and `doFinal`; this changed the cipher state and caused the doFinal call to fail.
> 
> The issue for AES/GCM (and all other AEAD ciphers) was fixed by JDK-8294848; this patch addresses the non-AEAD ciphers.
> 
> Tier1-3 clean. Also, no failures after 1200 repetitions of NoInvalidateSocketException.

This pull request has now been integrated.

Changeset: d1252653
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1252653b07ee3d0347b39b96f734e45772b5b36
Stats:     9 lines in 3 files changed: 6 ins; 1 del; 2 mod

8277970: Test jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java fails with "tag mismatch"

Reviewed-by: jnimeh, xuelei

-------------

PR: https://git.openjdk.org/jdk/pull/10657

From naoto at openjdk.org  Wed Oct 12 16:14:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Oct 2022 16:14:28 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
Message-ID: <qDqXEgE8gASVTwohMaAZL3DYpAzQurzoQICQApcpCdw=.562c873e-5426-40ab-b24d-89f2d5974e58@github.com>

On Mon, 10 Oct 2022 23:23:00 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Looks much better now. A minor comment on the library.

test/lib/jdk/test/lib/TestUI.java line 30:

> 28: import java.awt.event.WindowEvent;
> 29: 
> 30: public class TestUI {

I would expect some class description for this library. Also, could the library name be more descriptive than "TestUI"?

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From xuelei at openjdk.org  Wed Oct 12 16:22:43 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Oct 2022 16:22:43 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit [v3]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <8ztnDOwivFAvV_iI6C3xHWfcwR-4qlURqhbI4KrAI68=.a1cbf54f-b2cb-4206-9d25-3be46bffdeaa@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  missed reduce

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10624/files
  - new: https://git.openjdk.org/jdk/pull/10624/files/c2fa6e8b..8f3ff011

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=01-02

  Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

PR: https://git.openjdk.org/jdk/pull/10624

From bhuang at openjdk.org  Wed Oct 12 18:03:19 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 18:03:19 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v3]
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <4aosQzAkhEDzQJGGmKkrXlqNuzcC6CrQf4L5ri6ny8o=.bdb6a3a4-dd6c-4931-910a-704058413bd3@github.com>

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Added documentation to UIBuilder.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10635/files
  - new: https://git.openjdk.org/jdk/pull/10635/files/a36cd005..b808c0a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=01-02

  Stats: 267 lines in 3 files changed: 160 ins; 105 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From bhuang at openjdk.org  Wed Oct 12 18:31:16 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 18:31:16 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v4]
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <RKFYi2Kv9-fIuAyvg0YBEBwRHxb2RYCK_v8AFg7qPow=.00febe82-bd61-492b-a9f2-f03c70d7afc0@github.com>

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Fixed typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10635/files
  - new: https://git.openjdk.org/jdk/pull/10635/files/b808c0a5..4c08a3e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From naoto at openjdk.org  Wed Oct 12 20:53:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Oct 2022 20:53:07 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v4]
In-Reply-To: <RKFYi2Kv9-fIuAyvg0YBEBwRHxb2RYCK_v8AFg7qPow=.00febe82-bd61-492b-a9f2-f03c70d7afc0@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <RKFYi2Kv9-fIuAyvg0YBEBwRHxb2RYCK_v8AFg7qPow=.00febe82-bd61-492b-a9f2-f03c70d7afc0@github.com>
Message-ID: <lr7Zbd6n4nOHLZSkinyO7iv1zNVp2ybeg4OnrrOhzgY=.58ae0071-46db-4772-80e9-cba73b471d1c@github.com>

On Wed, 12 Oct 2022 18:31:16 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From bhuang at openjdk.org  Wed Oct 12 22:20:28 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 22:20:28 GMT
Subject: Integrated: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <JwZZkExq0NKv2jpXbjvE4tthBJK7JVMARWDQ8Z6TxSo=.f6806f6e-8a37-410a-a17b-b98e34a75597@github.com>

On Mon, 10 Oct 2022 18:18:55 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).

This pull request has now been integrated.

Changeset: ac194142
Author:    Bill Huang <bhuang at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac1941425bdb1a25aa3364eef9eb1092ee716761
Stats:     497 lines in 3 files changed: 485 ins; 2 del; 10 mod

8294994: Update Jarsigner and Keytool i18n tests to validate i18n compliance

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From djelinski at openjdk.org  Thu Oct 13 09:32:34 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Oct 2022 09:32:34 GMT
Subject: RFR: 8294906: Memory leak in PKCS11 NSS TLS server [v3]
In-Reply-To: <347z_2TAvP6GBk6b2th9LSAjG2ayTK0eJsc2JFmmrTg=.eb7a3e10-3b1a-4801-993d-0494741d0b98@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
 <347z_2TAvP6GBk6b2th9LSAjG2ayTK0eJsc2JFmmrTg=.eb7a3e10-3b1a-4801-993d-0494741d0b98@github.com>
Message-ID: <re6x_5XMFMDykw137KSiNJvzskzr0FnUG0OSboOnX00=.cf69740c-9785-4b30-9c4f-1e59e5dbbc44@github.com>

On Wed, 12 Oct 2022 12:13:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
>> 
>> Verified that:
>> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
>> - The same server continues to function correctly
>> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
>> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about unused parameters

Verified that the behavior is still present in NSS 3.82. JBS updated.
Thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/10594

From djelinski at openjdk.org  Thu Oct 13 09:32:34 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Oct 2022 09:32:34 GMT
Subject: Integrated: 8294906: Memory leak in PKCS11 NSS TLS server
In-Reply-To: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
References: <qBE3OYn-zjViiUVnTZfOoaZr_VbJnDNwEh2h4bMbiHE=.0e01d85b-e7ef-4529-806b-089dde8ee386@github.com>
Message-ID: <SoRXYNXd7C0ApQ3Z3LRAL8Ft-qT07VNCuotxGQUBRek=.33bdcc49-c813-44ff-9f37-df3075485632@github.com>

On Thu, 6 Oct 2022 13:27:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> C_DeriveKey with mechanisms `CKM_*_KEY_AND_MAC_DERIVE` always returns mac keys, even if macBits is zero. These keys must be free'd when no longer needed.
> 
> Verified that:
> - SSL server configured with PKCS11-NSS provider leaks memory without this patch, does not leak memory with this patch
> - The same server continues to function correctly
> - Existing tier1-3 tests continue to pass with NSS; did not test any other PKCS11 providers
> - new tests for AES-128-GCM-SHA256 and AES-256-GCM-SHA384 key derivation pass

This pull request has now been integrated.

Changeset: 94caecbe
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/94caecbe574227b232e22d9f56361f8ecd507be6
Stats:     119 lines in 5 files changed: 108 ins; 3 del; 8 mod

8294906: Memory leak in PKCS11 NSS TLS server

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.org/jdk/pull/10594

From djelinski at openjdk.org  Thu Oct 13 10:19:08 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Oct 2022 10:19:08 GMT
Subject: Integrated: 8294997: Improve ECC math operations
In-Reply-To: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
Message-ID: <fHLViiuL5U7q2HH0r9WKRjXqsVePQFR8ZUSl5C6wKRA=.98a24352-9bc8-4028-ad64-dad4abf55fa4@github.com>

On Fri, 7 Oct 2022 21:11:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch rewrites some BigInteger and curve point operations used in EC calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP operations:
> t2 = t1+t1
> t1 = t1+t2
> is equivalent to t1=t1*3, which is now implemented more efficiently.
> 
> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
> 
> After:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
> 
> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
> 
> Tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: 2f60675e
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f60675e06801b8ee495729d8bff2faec37ce509
Stats:     49 lines in 5 files changed: 2 ins; 23 del; 24 mod

8294997: Improve ECC math operations

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.org/jdk/pull/10614

From jpai at openjdk.org  Thu Oct 13 12:32:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 12:32:05 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <2LlIOshAZkGspRSquIBSNWRjLcyCHuVgC2RGXuhPrc4=.70400537-b1a7-4a53-8b1b-f76285cde5b5@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 59:

> 57:      * @return true - if the factory is allowed to be instantiated; false - otherwise
> 58:      */
> 59:     public static boolean checkGlobalFilter(Class<?> serialClass) {

I think the `serialClass` param should be renamed to `factoryClass` or something like that, since I think the `serialClass` reference comes from serialization/deserialization usage.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 12:37:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 12:37:08 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <FGZbktWLAcghlwjFdTrPV6vrZZkyK5FBv7Jx64AkfjA=.2e34222d-3f26-48b9-b6b2-fb9db51d52e9@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.base/share/conf/security/java.security line 1408:

> 1406: # references bound to LDAP contexts. The factory class named by the reference instance will
> 1407: # be matched against this filter. The filter property supports pattern-based filter syntax
> 1408: # with the same format as jdk.serialFilter.

Hello Aleksei, as far as I can see the `jdk.serialFilter` allows for additional details like `limits` (example: `maxdepth=value`). Should we note here that this JNDI specific property will ignore those configurations?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 12:41:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 12:41:09 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.base/share/conf/security/java.security line 1423:

> 1421: #
> 1422: # The default pattern value allows any object factory class defined in the java.naming module
> 1423: # to be specified by the reference instance, but rejects any other.

Should this instead say:
> The default pattern value allows any object factory class belonging to the `com.sun.jndi.ldap` and its sub-packages of the `java.naming` module to be specified by the reference instance...?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:23:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:23:10 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <5WZp2QFcNIapf6FaRhY6JWf3ZBCr930jLAlF-BYmXUg=.accba2c1-84c5-49b4-b978-bc7c320c1b89@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 109:

> 107:      * @see java.lang.SecurityManager#checkSetFactory
> 108:      */
> 109:     public static synchronized void setObjectFactoryBuilder(

Perhaps remove the `synchronized` from this method and the getter, now that the synchronization has moved to the `NamingManagerHelper` class?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:33:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:33:10 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <ingf31EKum851vQsVe04hBXRAwENQ0AUtWeEqSYulKE=.58863a5f-dbea-48f0-8c63-4e084bd9870c@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/com/sun/naming/internal/NamingManagerHelper.java line 416:

> 414:     /**
> 415:      * Package-private; used by DirectoryManager and NamingManager.
> 416:      */

This comment is no longer relevant, given that this is now an internal private field of this class.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:39:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:39:17 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <cTG4s1RthBsc-_3HHzk_LdZgasfGBgpL98pSjULfIaU=.d990e794-ca0c-4f08-be49-cca1ed4b8a4c@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.base/share/conf/security/java.security line 1410:

> 1408: # with the same format as jdk.serialFilter.
> 1409: #
> 1410: # Each pattern is matched against the factory class name to allow or disallow it's

I believe this should be `its` instead of `it's`

src/java.base/share/conf/security/java.security line 1411:

> 1409: #
> 1410: # Each pattern is matched against the factory class name to allow or disallow it's
> 1411: # instantiation. The access to a factory class is allowed only when its not rejected by this filter

and here it should be `it's` instead of `its`

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From rriggs at openjdk.org  Thu Oct 13 13:58:19 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Oct 2022 13:58:19 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <FGZbktWLAcghlwjFdTrPV6vrZZkyK5FBv7Jx64AkfjA=.2e34222d-3f26-48b9-b6b2-fb9db51d52e9@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <FGZbktWLAcghlwjFdTrPV6vrZZkyK5FBv7Jx64AkfjA=.2e34222d-3f26-48b9-b6b2-fb9db51d52e9@github.com>
Message-ID: <eptZUHUsJFrKtALEGpIxXHbFHlpwPuniJpQ-n0oowUY=.e1744050-962c-4ac2-8e9d-055221cd470d@github.com>

On Thu, 13 Oct 2022 12:34:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.base/share/conf/security/java.security line 1408:
> 
>> 1406: # references bound to LDAP contexts. The factory class named by the reference instance will
>> 1407: # be matched against this filter. The filter property supports pattern-based filter syntax
>> 1408: # with the same format as jdk.serialFilter.
> 
> Hello Aleksei, as far as I can see the `jdk.serialFilter` allows for additional details like `limits` (example: `maxdepth=value`). Should we note here that this JNDI specific property will ignore those configurations?

Yes, worth noting, but I would say they are "unused", not ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:58:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:58:20 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <hC0IplTN6hRI7nQrsmxqczSRpnP_iObiGarvFCyjCMw=.46e10839-a7e7-4da0-aff5-b8efa16b7061@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/com/sun/naming/internal/NamingManagerHelper.java line 81:

> 79:                 // No factory found, so return original refInfo.
> 80:                 // Will reach this point if factory class is not in
> 81:                 // class path and reference does not contain a URL for it

I think this "Will reach this point ..." part should be updated to note that the code will additionally reach here if the factory class is disallowed by the filters.

Similar change would be needed for the comment in `getDirObjectInstance` method.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From coffeys at openjdk.org  Thu Oct 13 16:06:13 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 16:06:13 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v5]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - test update
 - Merge branch 'master' into secEvent-8292177
 - Use stringPropertyNames()
 - Refactor getter method name
 - Restore ProtectionDomain to original
 - Store properties cache in Security class
 - Remove unused import
 - Address Oct 10 review comments
 - Check for 0 security events
 - Null check on Properties
 - ... and 7 more: https://git.openjdk.org/jdk/compare/3644e26c...3a347dae

-------------

Changes: https://git.openjdk.org/jdk/pull/10394/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=04
  Stats: 255 lines in 12 files changed: 252 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Thu Oct 13 16:08:07 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 16:08:07 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
 <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
 <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
Message-ID: <D8TG79W6XZC2rkrQ6a8MZjKQ7iX4nZUeC-KrThk2VlU=.caf70d0c-5644-46f4-8242-10b4adfa555a@github.com>

On Tue, 11 Oct 2022 12:39:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 
>> 
>> In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?
>
> Maybe I am missing something. If this JFR event is enabled, and the properties have not yet been accessed, then it seems ok for JFR to load the `Security` class when JFR is started since the user is interested in this event.

After further conversation with @seanjmullan , a sharedSecrets accessor for the Properties map should be ok. Edits pushed.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aefimov at openjdk.org  Thu Oct 13 17:45:26 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 17:45:26 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <2LlIOshAZkGspRSquIBSNWRjLcyCHuVgC2RGXuhPrc4=.70400537-b1a7-4a53-8b1b-f76285cde5b5@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <2LlIOshAZkGspRSquIBSNWRjLcyCHuVgC2RGXuhPrc4=.70400537-b1a7-4a53-8b1b-f76285cde5b5@github.com>
Message-ID: <17uHllhsdXbhG6eiXncEdORpmBQPpeTGzOUnjHZtXeU=.f9b4b754-ff9d-4b8d-98ae-b9b34b86ae40@github.com>

On Thu, 13 Oct 2022 12:29:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 59:
> 
>> 57:      * @return true - if the factory is allowed to be instantiated; false - otherwise
>> 58:      */
>> 59:     public static boolean checkGlobalFilter(Class<?> serialClass) {
> 
> I think the `serialClass` param should be renamed to `factoryClass` or something like that, since I think the `serialClass` reference comes from serialization/deserialization usage.

The name comes from `ObjectInputFilter.FilterInfo` - it's been renamed from `factoryClass`to make it clear that the supplied lambda fills-in the non-default `ObjectInputFilter.FilterInfo.serialClass()` method.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From xuelei at openjdk.org  Thu Oct 13 18:15:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 13 Oct 2022 18:15:30 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v4]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be reduced if required in EC limbs operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs if required for EC limbs operations.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1417.507 ?  5.809  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1412.620 ?  7.040  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1417.364 ?  6.643  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1364.720 ? 44.354  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   609.924 ?  9.858  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   610.873 ?  5.519  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   608.573 ? 13.324  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   597.802 ?  7.074  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   301.954 ?  6.449  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   300.774 ?  5.849  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   295.831 ?  8.423  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   276.258 ? 43.146  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1171.878 ?  4.187  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1175.175 ?  4.611  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1168.459 ?  5.750  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1086.906 ?  6.514  ops/s
> Signatures.sign        Ed448               64  thrpt   15   326.475 ?  3.274  ops/s
> Signatures.sign        Ed448              512  thrpt   15   328.709 ?  3.867  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   315.480 ? 15.377  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   312.388 ?  1.067  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1377.447 ? 38.889  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1403.149 ?  5.151  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1401.101 ?  6.937  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1381.855 ? 10.606  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   595.979 ?  1.967  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   592.419 ?  6.087  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   581.800 ? 18.815  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   583.224 ?  9.856  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   264.772 ? 36.883  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   302.084 ?  1.074  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   296.619 ?  3.272  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   290.112 ?  5.085  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1163.293 ?  4.266  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1157.093 ?  8.145  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1140.900 ?  8.660  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1053.233 ? 40.591  ops/s
> Signatures.sign        Ed448               64  thrpt   15   317.509 ?  6.870  ops/s
> Signatures.sign        Ed448              512  thrpt   15   320.975 ?  1.534  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   322.157 ?  1.914  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   303.532 ?  6.419  ops/s
> 
> 
> From the numbers, it looks like the performance impact is limited.  Based on this update, the performance could get rewarded by using less limbs.  For examples if using less limbs for secp256r1/secp384r1/secp521r1, [see PR for PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow (note: I did not update to use less limbs for Ed25519/Ed448 yet, the numbers listed below for them are just for comparing with the numbers above):
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1632.905 ? 12.235  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1626.057 ?  3.052  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1625.676 ?  8.435  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1603.612 ?  4.289  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   605.713 ? 14.951  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   608.920 ?  7.715  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   601.338 ?  1.638  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   602.315 ?  3.308  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   320.946 ?  0.877  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   322.642 ?  1.222  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   322.204 ?  1.929  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   316.769 ?  5.398  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1143.084 ? 13.169  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1145.780 ?  7.880  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1144.818 ?  5.768  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1081.061 ?  8.283  ops/s
> Signatures.sign        Ed448               64  thrpt   15   321.304 ?  0.638  ops/s
> Signatures.sign        Ed448              512  thrpt   15   320.501 ?  1.924  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   319.234 ?  1.082  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   306.937 ?  1.060  ops/s
> ``` 
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - missed reduce
 - reduce if needed
 - add the key pair generation bench code
 - remove tabs
 - 8295010: EC limbs addition and subtraction limit

-------------

Changes: https://git.openjdk.org/jdk/pull/10624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=03
  Stats: 291 lines in 10 files changed: 233 ins; 35 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

PR: https://git.openjdk.org/jdk/pull/10624

From aefimov at openjdk.org  Thu Oct 13 19:23:53 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 19:23:53 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <5WZp2QFcNIapf6FaRhY6JWf3ZBCr930jLAlF-BYmXUg=.accba2c1-84c5-49b4-b978-bc7c320c1b89@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <5WZp2QFcNIapf6FaRhY6JWf3ZBCr930jLAlF-BYmXUg=.accba2c1-84c5-49b4-b978-bc7c320c1b89@github.com>
Message-ID: <c2IMKzhWSsPJBAGb469Fz-TJ7AqwsTD6H0C-bsyioxY=.db536863-cf53-4951-8f4c-7baf531e80b9@github.com>

On Thu, 13 Oct 2022 13:18:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 109:
> 
>> 107:      * @see java.lang.SecurityManager#checkSetFactory
>> 108:      */
>> 109:     public static synchronized void setObjectFactoryBuilder(
> 
> Perhaps remove the `synchronized` from this method and the getter, now that the synchronization has moved to the `NamingManagerHelper` class?

Agreed - I think it is safe to remove `synchronized`. I doubt that there is a code that relies on `synchronized (javax.naming.spi.NamingManager.class)` to prevent other code setting the factory builder (also it can be set only once), therefore it should be ok to remove `synchronized`.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From mullan at openjdk.org  Thu Oct 13 19:31:44 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Oct 2022 19:31:44 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v5]
In-Reply-To: <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>
Message-ID: <gfGORysX8ROdaRi0EHYjQijgnmIrSS3ag7cxrQWK6k8=.3b547c3b-4dcc-47cc-9d33-1af57df7bc92@github.com>

On Thu, 13 Oct 2022 16:06:13 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - test update
>  - Merge branch 'master' into secEvent-8292177
>  - Use stringPropertyNames()
>  - Refactor getter method name
>  - Restore ProtectionDomain to original
>  - Store properties cache in Security class
>  - Remove unused import
>  - Address Oct 10 review comments
>  - Check for 0 security events
>  - Null check on Properties
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3644e26c...3a347dae

Changes requested by mullan (Reviewer).

src/java.base/share/classes/java/security/Security.java line 68:

> 66: 
> 67:     /* cache a copy for recording purposes */
> 68:     static Properties initialSecurityProperties;

This can be `private` now.

src/java.base/share/classes/java/security/Security.java line 184:

> 182:     }
> 183: 
> 184:     static Properties getInitialSecurityProperties() {

Don't think we need this method anymore.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aefimov at openjdk.org  Thu Oct 13 19:38:51 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 19:38:51 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>
Message-ID: <sFnmPA7BE8YtR8gegvlv_bmhqL6NTDp3Q6VNu1WbMpA=.a80d42c8-65a0-435e-af89-e0c73b2da44f@github.com>

On Thu, 13 Oct 2022 12:37:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.base/share/conf/security/java.security line 1423:
> 
>> 1421: #
>> 1422: # The default pattern value allows any object factory class defined in the java.naming module
>> 1423: # to be specified by the reference instance, but rejects any other.
> 
> Should this instead say:
>> The default pattern value allows any object factory class belonging to the `com.sun.jndi.ldap` and its sub-packages of the `java.naming` module to be specified by the reference instance...?

I would prefer to keep a filter default value explanation sentences simpler since exact default values are listed just one line after.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Thu Oct 13 19:52:09 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 19:52:09 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v4]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <EkFZCfoZecPOqLipwqiQiDzE-81sl1SmTOGA9h8Ke-I=.c401ce02-e88a-4355-a8b6-eb3983ab1da6@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Remove factory builder synchronization from NamingManager. Update comments/docs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/528489b0..53806048

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=02-03

  Stats: 26 lines in 3 files changed: 9 ins; 3 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From coffeys at openjdk.org  Thu Oct 13 19:53:27 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 19:53:27 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v6]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <kcuxYSNa864tHJgrAiKK28Ky2W_KeyFcEk-aMqIpTiI=.494d9939-ac22-4747-a767-13c9f43d1158@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:

 - remove previous edit
 - Use blessed modifier order in EventNames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/3a347dae..138004ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=04-05

  Stats: 148 lines in 2 files changed: 0 ins; 4 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Thu Oct 13 19:53:31 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 19:53:31 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v5]
In-Reply-To: <gfGORysX8ROdaRi0EHYjQijgnmIrSS3ag7cxrQWK6k8=.3b547c3b-4dcc-47cc-9d33-1af57df7bc92@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>
 <gfGORysX8ROdaRi0EHYjQijgnmIrSS3ag7cxrQWK6k8=.3b547c3b-4dcc-47cc-9d33-1af57df7bc92@github.com>
Message-ID: <ThBhW4D3Nb1PKRb2VTXN_UipNBkp7ZzxYSdfkmwP4qE=.adb5be4d-4be7-4f01-9f6e-3b96f67b36dc@github.com>

On Thu, 13 Oct 2022 19:19:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - test update
>>  - Merge branch 'master' into secEvent-8292177
>>  - Use stringPropertyNames()
>>  - Refactor getter method name
>>  - Restore ProtectionDomain to original
>>  - Store properties cache in Security class
>>  - Remove unused import
>>  - Address Oct 10 review comments
>>  - Check for 0 security events
>>  - Null check on Properties
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3644e26c...3a347dae
>
> src/java.base/share/classes/java/security/Security.java line 184:
> 
>> 182:     }
>> 183: 
>> 184:     static Properties getInitialSecurityProperties() {
> 
> Don't think we need this method anymore.

Thanks - did another pass through the edits and caught these.  Patch updated.

[Use blessed modifier order in EventNames]


[remove previous edit]

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mullan at openjdk.org  Thu Oct 13 20:48:45 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Oct 2022 20:48:45 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v6]
In-Reply-To: <kcuxYSNa864tHJgrAiKK28Ky2W_KeyFcEk-aMqIpTiI=.494d9939-ac22-4747-a767-13c9f43d1158@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <kcuxYSNa864tHJgrAiKK28Ky2W_KeyFcEk-aMqIpTiI=.494d9939-ac22-4747-a767-13c9f43d1158@github.com>
Message-ID: <_Wyi6Cde0JI9dTfKlk6KTxxafSPWLwurYoIxxkQ07mo=.ca0f0473-973f-405b-8db4-42e699115cb2@github.com>

On Thu, 13 Oct 2022 19:53:27 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove previous edit
>  - Use blessed modifier order in EventNames

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mchhipa at openjdk.org  Fri Oct 14 11:32:06 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 14 Oct 2022 11:32:06 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>

On Mon, 10 Oct 2022 21:39:05 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Changes requested by mchhipa (Committer).

test/jdk/java/security/Policy/Root/Root.java line 48:

> 46:     private static final Path TARGET = Paths.get(ROOT, ".java.policy");
> 47:     public static void main(String[] args) throws Exception {
> 48:         Files.copy(SOURCE, TARGET, StandardCopyOption.REPLACE_EXISTING);

Could you please use the testng framework for initial setup of test.

test/jdk/java/security/Policy/Root/Root.java line 57:

> 55: 
> 56:     private static void test() throws Exception{
> 57:         ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(

No need to create ProceesBuilder if use the testng framework

test/jdk/java/security/Policy/Root/Root.java line 64:

> 62:         OutputAnalyzer output = new OutputAnalyzer(proc);
> 63:         output.stdoutShouldNotBeEmpty();
> 64:         output.shouldContain("Test succeeded");

p.implies() returns boolean value, instead of checking for string "Test succeded", use Assert.assertTrue()

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 31:

> 29:  * @summary Test limited/default_local.policy containing inconsistent entries
> 30:  * @library /test/lib
> 31:  * @run driver InconsistentEntries

Use the testng framework.

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 76:

> 74:         OutputAnalyzer output = new OutputAnalyzer(proc);
> 75:         output.shouldContain("Test completed successfully");
> 76:         System.out.println("Test passed.");

Please use testng framework instead of creating ProcessBuilder

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 105:

> 103:             } catch (ExceptionInInitializerError e) {
> 104:                 e.printStackTrace();
> 105:                 System.out.println("Test completed successfully");

This test can be rewritten and use @Test(expectedException = ExceptionInInitializerError.class) instead of creating the ProcessBuilder to capture the output.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From coffeys at openjdk.org  Fri Oct 14 15:45:23 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Oct 2022 15:45:23 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
Message-ID: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>

By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)

test case also updated to capture new logic

-------------

Commit messages:
 - restore import style
 - Merge branch 'master' into 8292033-x509Event
 - Minor clean up
 - Merge branch 'master' into 8292033-x509Event
 - update commit method name
 - Record all X509 generate events
 - fix up merge
 - merge with master
 - 8292033

Changes: https://git.openjdk.org/jdk/pull/10422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10422&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292033
  Stats: 121 lines in 6 files changed: 61 ins; 49 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10422.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10422/head:pull/10422

PR: https://git.openjdk.org/jdk/pull/10422

From bhuang at openjdk.org  Fri Oct 14 15:55:43 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 14 Oct 2022 15:55:43 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion
In-Reply-To: <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>
Message-ID: <bmQOg7gqjEWiMVTCEnVY1RUqFeOssuxk8veYu0W67kM=.a68b3625-1649-4c58-8a89-12cc0fdf7ba6@github.com>

On Fri, 14 Oct 2022 11:00:44 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> test/jdk/java/security/Policy/Root/Root.java line 48:
> 
>> 46:     private static final Path TARGET = Paths.get(ROOT, ".java.policy");
>> 47:     public static void main(String[] args) throws Exception {
>> 48:         Files.copy(SOURCE, TARGET, StandardCopyOption.REPLACE_EXISTING);
> 
> Could you please use the testng framework for initial setup of test.

This is a @driver test that copies the Root.policy file to the home directory before running the RootTest in a new JVM. The reason is that upon the start of the new JVM it loads the default system-wide policy file and the default user policy file which is the Root.policy we just copied. With the testng framework, there is no way to load the custom user policy file without reinstalling the security manager in the test, that said, it doesn't match what the manual test does.

> test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 31:
> 
>> 29:  * @summary Test limited/default_local.policy containing inconsistent entries
>> 30:  * @library /test/lib
>> 31:  * @run driver InconsistentEntries
> 
> Use the testng framework.

Same reason as Root.java. The custom policy file needs to place in Java home directory before running the test.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From aefimov at openjdk.org  Fri Oct 14 16:19:41 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 14 Oct 2022 16:19:41 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov 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 ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Remove factory builder synchronization from NamingManager. Update comments/docs.
 - Change checkInput to be the global filter centric
 - Refactor checkInput, better reporting for invalid filter patterns
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/53806048..b3849168

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=03-04

  Stats: 15973 lines in 334 files changed: 11307 ins; 2971 del; 1695 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From dfuchs at openjdk.org  Fri Oct 14 16:38:36 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Oct 2022 16:38:36 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
Message-ID: <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>

On Fri, 14 Oct 2022 16:19:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Remove factory builder synchronization from NamingManager. Update comments/docs.
>  - Change checkInput to be the global filter centric
>  - Refactor checkInput, better reporting for invalid filter patterns
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Additional comments/formatting cleanup.
>  - More tests clean-up. Code/doc comments cleanup.
>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

src/java.base/share/conf/security/java.security line 1388:

> 1386: # are unused.
> 1387: #
> 1388: # Each class name pattern is matched against the factory class name to allow or disallow its

It appears that for those protocols for which there is no specific filter, a factory class will be accepted only if the global filter returns ALLOWED - which contradicts what is written here (where it says that the class is allowed if it's not REJECTED). Is this something that has changed with this fix - or was the documentation wrong before?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Fri Oct 14 17:30:02 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 14 Oct 2022 17:30:02 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
 <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
Message-ID: <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>

On Fri, 14 Oct 2022 16:35:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov 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 ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Remove factory builder synchronization from NamingManager. Update comments/docs.
>>  - Change checkInput to be the global filter centric
>>  - Refactor checkInput, better reporting for invalid filter patterns
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Additional comments/formatting cleanup.
>>  - More tests clean-up. Code/doc comments cleanup.
>>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation
>
> src/java.base/share/conf/security/java.security line 1388:
> 
>> 1386: # are unused.
>> 1387: #
>> 1388: # Each class name pattern is matched against the factory class name to allow or disallow its
> 
> It appears that for those protocols for which there is no specific filter, a factory class will be accepted only if the global filter returns ALLOWED - which contradicts what is written here (where it says that the class is allowed if it's not REJECTED). Is this something that has changed with this fix - or was the documentation wrong before?

Very good catch Daniel! It is with this fix and I believe the code needs to be change to match what is written for the global filter here:
What we've had before in `checkInput`:

    private static boolean checkInput(FactoryInfo factoryInfo) {
        Status result = GLOBAL.checkInput(factoryInfo);
        return result != Status.REJECTED;

What we have now:

        if (filter == GLOBAL_FILTER) {
            return globalResult == Status.ALLOWED;
        }


I think it needs to be changed to (to match the description for global filter):

        if (filter == GLOBAL_FILTER) {
            return globalResult != Status.REJECTED;
        }

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From rriggs at openjdk.org  Fri Oct 14 17:48:04 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Oct 2022 17:48:04 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
 <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
 <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>
Message-ID: <QS-ou-X1c4It5-vKse8h6YSFZqoYVqwh7I6EdfuRN-0=.b649ffbb-8288-4484-8032-e1c0c627caef@github.com>

On Fri, 14 Oct 2022 17:27:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 1388:
>> 
>>> 1386: # are unused.
>>> 1387: #
>>> 1388: # Each class name pattern is matched against the factory class name to allow or disallow its
>> 
>> It appears that for those protocols for which there is no specific filter, a factory class will be accepted only if the global filter returns ALLOWED - which contradicts what is written here (where it says that the class is allowed if it's not REJECTED). Is this something that has changed with this fix - or was the documentation wrong before?
>
> Very good catch Daniel! It is with this fix and I believe the code needs to be change to match what is written for the global filter here:
> What we've had before in `checkInput`:
> 
>     private static boolean checkInput(FactoryInfo factoryInfo) {
>         Status result = GLOBAL.checkInput(factoryInfo);
>         return result != Status.REJECTED;
> 
> What we have now:
> 
>         if (filter == GLOBAL_FILTER) {
>             return globalResult == Status.ALLOWED;
>         }
> 
> 
> I think it needs to be changed to (to match the description for global filter):
> 
>         if (filter == GLOBAL_FILTER) {
>             return globalResult != Status.REJECTED;
>         }

In the general composition of filters, it is preferable that UNDECIDED is treated as REJECTED.
That keeps unintentional holes in a filter from being permissive.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From aturbanov at openjdk.org  Fri Oct 14 19:23:00 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 14 Oct 2022 19:23:00 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
In-Reply-To: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
Message-ID: <B2GveulVDqeOjCZfyILL17tyHpocNMgbKk2sGWoVrmE=.23402eff-adff-4b55-a305-c58995cf5e91@github.com>

On Mon, 26 Sep 2022 13:45:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)
> 
> test case also updated to capture new logic

src/java.base/share/classes/jdk/internal/event/X509CertificateEvent.java line 34:

> 32: 
> 33: public final class X509CertificateEvent extends Event {
> 34:     private final static X509CertificateEvent EVENT = new X509CertificateEvent();

Use blessed modifiers order
Suggestion:

    private static final X509CertificateEvent EVENT = new X509CertificateEvent();

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From duke at openjdk.org  Fri Oct 14 21:38:22 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 14 Oct 2022 21:38:22 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions
Message-ID: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>

Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.

- Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
  - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
- Added a JMH perf test.
   - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.

Perf before:

Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s

and after:

Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

-------------

Commit messages:
 - missed white-space fix
 - - Fix whitespace and copyright statements
 - Merge remote-tracking branch 'vpaprotsk/master' into avx512-poly
 - Poly1305 AVX512 intrinsic for x86_64

Changes: https://git.openjdk.org/jdk/pull/10582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288047
  Stats: 1676 lines in 29 files changed: 1665 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10582.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10582/head:pull/10582

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 14 21:38:22 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 14 Oct 2022 21:38:22 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <G9mBlYnnbsXYWxFS4FfAYnhC1t7Mgd0Y9oNVpsBQ17c=.5f2bc122-7d47-4e0e-96cf-4c6e0e78f959@github.com>

On Wed, 5 Oct 2022 21:28:26 GMT, vpaprotsk <duke at openjdk.org> wrote:

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

I am part of Intel Java Team

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From jpai at openjdk.org  Sat Oct 15 04:56:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Oct 2022 04:56:26 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <sFnmPA7BE8YtR8gegvlv_bmhqL6NTDp3Q6VNu1WbMpA=.a80d42c8-65a0-435e-af89-e0c73b2da44f@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>
 <sFnmPA7BE8YtR8gegvlv_bmhqL6NTDp3Q6VNu1WbMpA=.a80d42c8-65a0-435e-af89-e0c73b2da44f@github.com>
Message-ID: <j66dCEOlqsAey1w0UDDhpM-C359IEb7T7VHQbCpV3jQ=.c9e93313-3a56-4917-9014-987f242c95c3@github.com>

On Thu, 13 Oct 2022 19:34:52 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 1423:
>> 
>>> 1421: #
>>> 1422: # The default pattern value allows any object factory class defined in the java.naming module
>>> 1423: # to be specified by the reference instance, but rejects any other.
>> 
>> Should this instead say:
>>> The default pattern value allows any object factory class belonging to the `com.sun.jndi.ldap` and its sub-packages of the `java.naming` module to be specified by the reference instance...?
>
> I would prefer to keep a filter default value explanation sentences simpler since exact default values are listed just one line after.

What you have here is OK with me then.

>> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 59:
>> 
>>> 57:      * @return true - if the factory is allowed to be instantiated; false - otherwise
>>> 58:      */
>>> 59:     public static boolean checkGlobalFilter(Class<?> serialClass) {
>> 
>> I think the `serialClass` param should be renamed to `factoryClass` or something like that, since I think the `serialClass` reference comes from serialization/deserialization usage.
>
> The name comes from `ObjectInputFilter.FilterInfo` - it's been renamed from `factoryClass`to make it clear that the supplied lambda fills-in the non-default `ObjectInputFilter.FilterInfo.serialClass()` method.

Thank you for that clarification, Aleksei. This sounds fine to me then.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jwaters at openjdk.org  Sun Oct 16 08:45:54 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 16 Oct 2022 08:45:54 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
Message-ID: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>

Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

-------------

Commit messages:
 - Commit remaining libraries
 - Merge branch 'openjdk:master' into patch-2
 - Comment change, force link failures to determine libraries to include in make
 - Update WinSysInfo.cpp
 - Update WinFileUtils.cpp
 - Update WinApp.cpp
 - Update MsiUtils.cpp
 - Update MsiDb.cpp
 - Update MsiCA.cpp
 - Update Guid.cpp
 - ... and 12 more: https://git.openjdk.org/jdk/compare/0043d58c...cfa80528

Changes: https://git.openjdk.org/jdk/pull/10633/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295231
  Stats: 35 lines in 14 files changed: 3 ins; 22 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From alanb at openjdk.org  Sun Oct 16 13:21:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Oct 2022 13:21:53 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 38:

> 36: 
> 37: #include <Mswsock.h>
> 38: #pragma comment(lib, "Mswsock.lib")

I think this came about with one of the early Microsoft contributions to have transferTo optionally use TransmitFile on Windows. This create the dependency on Mswsock.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From dholmes at openjdk.org  Mon Oct 17 02:42:48 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Oct 2022 02:42:48 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <bcCMkRFyhoaqWFr-bpraFJLPnv9jB1ozA700K_-JLZ8=.f5a0047d-7674-4b17-8eae-28b72ed4d816@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

I don't agree with the justification here. This seems very windows specific but I like the idea that the source code tracks its own library dependencies. If I am writing some windows code that uses a particular Windows API which in turn requires a specific windows library, then these pragma comments seem an ideal way to express that dependency. This has the advantage that (a) the developer doesn't require detailed knowledge of the build system to make things work; and (b) there is more chance that if the code is later removed then removing the linking of the library will not get overlooked.

YMMV.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From stuefe at openjdk.org  Mon Oct 17 06:08:04 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 06:08:04 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <fqolzndii_HWLbTdOthl88tMEu7oWcPrrze74rHVQlY=.07f4b867-564f-4758-a665-b209b1cfa979@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

I like this change. I am pretty sure not many know about this feature at all, we don't have that many knowledgeable Windows developers. If the methods are equivalent, I prefer linking via make file.

Pinging @magicus, maybe he can chime in.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From ihse at openjdk.org  Mon Oct 17 09:27:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:27:10 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Marked as reviewed by ihse (Reviewer).

Wow. I did not even know this was possible. Thank you for fixing this! I would have been mighty surprised if I were to learn that a library has more dependencies than the one in the makefile.

@dholmes-ora The point is that we need to be consistent. If we would go that route, then *all* libraries should be loaded by pragmas. That could of course be an alternative, but I really see no upside to it. To do it like we currently do, load 99% of the libraries via make files, and then have few scattered pragmas, that's just bad.

@TheShermanTanker Question: is this a Windows-specific thing, or are there pragma-loaded libraries for other compilers as well?

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From mbaesken at openjdk.org  Mon Oct 17 10:49:34 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Oct 2022 10:49:34 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of IllegalArgumentException
 and InvalidParameterException shown by sun/security/pkcs11 tests
Message-ID: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>

We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see

https://bugs.openjdk.org/browse/JDK-8295343
8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6

The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.

-------------

Commit messages:
 - JDK-8295405

Changes: https://git.openjdk.org/jdk/pull/10726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295405
  Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10726/head:pull/10726

PR: https://git.openjdk.org/jdk/pull/10726

From jwaters at openjdk.org  Mon Oct 17 14:21:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:21:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>
Message-ID: <yQkQ2fv6xhYKVjxQcawlr6dCgrA2Ic4GM1JgBnS7-QA=.0e6d20f9-8857-49c6-9cae-1ea5681a28fe@github.com>

On Mon, 17 Oct 2022 09:24:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @TheShermanTanker Question: is this a Windows-specific thing, or are there pragma-loaded libraries for other compilers as well?

To my knowledge only Visual C++ has the ability to perform linking through pragmas, the comment pragma works by leaving a linker comment in the object file (hence the name), meaning this only works with the Visual C++ linker, so while clang does support this pragma with clang-cl, for the use cases in the JDK it wouldn't matter. gcc does not have an equivalent pragma (or provide support for linking from inside source files at all, for that matter)

> If the methods are equivalent, I prefer linking via make file.

There isn't any difference between the 2 unless the library is tampered with by `-nodefaultlib`, but I can only find that specified in https://github.com/openjdk/jdk/blob/a033aa5a3d9c63d72d11af218b9896b037fbd8de/make/autoconf/flags-other.m4#L38 and https://github.com/openjdk/jdk/blob/392f35df4be1a9a8d7a67a25ae01230c7dd060ac/make/autoconf/lib-hsdis.m4#L45, neither of which have an effect on the libraries in this changeset

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:25:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:25:08 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v2]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <3fTguMGwo3QBguzYDzhuTVTiqTzn8ZVPiGM5xYuqZbw=.96637af9-ed38-49aa-aa99-71c656a11320@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - user32
 - Mswsock.lib requirement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/cfa80528..54e6ec10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:27:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:27:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v3]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <2ETlbmDLPJuS-GkWsIceJISmHts7aROCmrbPKS3lsag=.1fbf54ad-a174-4865-87b1-66c20004cb12@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update Guid.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/54e6ec10..fe15f907

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:27:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:27:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v3]
In-Reply-To: <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>
Message-ID: <Sdp31g_wPD_84xtCvZxXWZziMxRFoBtCKGaTuAYkJEE=.44879988-0df8-4555-af8f-96fd82870594@github.com>

On Sun, 16 Oct 2022 13:18:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Guid.cpp
>
> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 38:
> 
>> 36: 
>> 37: #include <Mswsock.h>
>> 38: #pragma comment(lib, "Mswsock.lib")
> 
> I think this came about with one of the early Microsoft contributions to have transferTo optionally use TransmitFile on Windows. This created the dependency on Mswsock. It's not clear why a pragma was used though.

I believe it may have had to do with explicitly showing the dependency as David suggests, I added a comment explaining this just in case

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:31:46 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:31:46 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v4]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with five additional commits since the last revision:

 - Update WinSysInfo.cpp
 - Update WinApp.cpp
 - Update MsiUtils.cpp
 - Update MsiDb.cpp
 - Update MsiCA.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/fe15f907..8afaf85d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02-03

  Stats: 12 lines in 5 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:35:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:35:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v5]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <1FdeByT381QCHgVhV7RfaietWwt_xj2jmQuZBFklSJM=.0cfa6d5d-3ccd-45cf-84c4-66d3e8b595e4@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update WindowsRegistry.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/8afaf85d..0779d1fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:35:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:35:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v4]
In-Reply-To: <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>
Message-ID: <q0n5fVZ_fV97Q5JdJI9Ck9Oype80Zuy0mVLJq4MkbVc=.6788d427-8f9c-46f9-9529-87e71be67803@github.com>

On Mon, 17 Oct 2022 14:31:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Update WinSysInfo.cpp
>  - Update WinApp.cpp
>  - Update MsiUtils.cpp
>  - Update MsiDb.cpp
>  - Update MsiCA.cpp

Thanks all for the reviews, I placed comments where the pragmas used to be detailing the library required by the source file to address David's concerns

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:41:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:41:06 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/0779d1fa..4eb2eb7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From aefimov at openjdk.org  Mon Oct 17 15:32:55 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 17 Oct 2022 15:32:55 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v6]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Update filter docs to match implementation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/b3849168..4449dda1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=04-05

  Stats: 10 lines in 3 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Mon Oct 17 15:45:47 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 17 Oct 2022 15:45:47 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <QS-ou-X1c4It5-vKse8h6YSFZqoYVqwh7I6EdfuRN-0=.b649ffbb-8288-4484-8032-e1c0c627caef@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
 <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
 <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>
 <QS-ou-X1c4It5-vKse8h6YSFZqoYVqwh7I6EdfuRN-0=.b649ffbb-8288-4484-8032-e1c0c627caef@github.com>
Message-ID: <2OYgybrPaDz6IGDPeJuztwySKWAn6YJjCnnFUqKzR5E=.ab31e70a-b2c8-47da-b443-418840b72c8a@github.com>

On Fri, 14 Oct 2022 17:45:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In the general composition of filters, it is preferable that UNDECIDED is treated as REJECTED.
 > That keeps unintentional holes in a filter from being permissive.

That is a good point Roger. The "java.security" file was updated (4449dda) to match the `ObjectFactoriesFilter` implementation, ie the global filter treats UNDECIDED as REJECTED. Also, the CSR has been updated to highlight that.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From bhuang at openjdk.org  Mon Oct 17 16:37:36 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 17 Oct 2022 16:37:36 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v2]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <kbn8N4pXF1cO3lk2pvHVM5H1e8xF0fIn3Ypgw8iVil0=.69005d39-cfb7-4a08-ad9b-0d6c72434960@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Refactored to use testng framework for test enviroment setup.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/5a47cacd..4911518e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=00-01

  Stats: 83 lines in 2 files changed: 10 ins; 29 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Mon Oct 17 16:41:54 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 17 Oct 2022 16:41:54 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v2]
In-Reply-To: <bmQOg7gqjEWiMVTCEnVY1RUqFeOssuxk8veYu0W67kM=.a68b3625-1649-4c58-8a89-12cc0fdf7ba6@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>
 <bmQOg7gqjEWiMVTCEnVY1RUqFeOssuxk8veYu0W67kM=.a68b3625-1649-4c58-8a89-12cc0fdf7ba6@github.com>
Message-ID: <5PtU-LzTnAPk_XYMeilrE_8CNTmplIOmWSIntJSaRcQ=.fae39780-b601-4d9e-87dd-febd47dc1334@github.com>

On Fri, 14 Oct 2022 15:50:30 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/java/security/Policy/Root/Root.java line 48:
>> 
>>> 46:     private static final Path TARGET = Paths.get(ROOT, ".java.policy");
>>> 47:     public static void main(String[] args) throws Exception {
>>> 48:         Files.copy(SOURCE, TARGET, StandardCopyOption.REPLACE_EXISTING);
>> 
>> Could you please use the testng framework for initial setup of test.
>
> This is a @driver test that copies the Root.policy file to the home directory before running the RootTest in a new JVM. The reason is that upon the start of the new JVM it loads the default system-wide policy file and the default user policy file which is the Root.policy we just copied. With the testng framework, there is no way to load the custom user policy file without reinstalling the security manager in the test, that said, it doesn't match what the manual test does.

Discussed with Mahendra offline, testng framework `@BeforeTest` performs test setup in the client JVM before test starts in the other JVM. We can use testng framework in this case to handle the policy file operations.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Mon Oct 17 16:57:06 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 17 Oct 2022 16:57:06 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  AssertThrows an exception in InconsistentEntries test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/4911518e..cfb9f74d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=01-02

  Stats: 9 lines in 1 file changed: 1 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From mpowers at openjdk.org  Mon Oct 17 17:10:09 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 17 Oct 2022 17:10:09 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests
In-Reply-To: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
Message-ID: <RcXolpYzDbrDfq-bR8EWCwAFyyVDikrT0HOweeiT0dM=.bd74118a-8fd2-4ff1-b251-a2127bca3a8c@github.com>

On Mon, 17 Oct 2022 10:42:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
> 
> https://bugs.openjdk.org/browse/JDK-8295343
> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
> 
> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.

There are several other files in the pkcs11 directory where cause is missing from the thrown exception. Might as well fix them all.

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From asemenyuk at openjdk.org  Mon Oct 17 17:19:59 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 17 Oct 2022 17:19:59 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
Message-ID: <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>

On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

The change looks harmless. Howevere I don't understand how searching for the standard Windows libs can then become frustrating.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From erikj at openjdk.org  Mon Oct 17 17:35:59 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Oct 2022 17:35:59 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
Message-ID: <r0umuBwCmFWWe9qkQRYTFlfbkyddQ7m8s13CN2geicM=.5af8a5c4-74b1-4a13-b54a-f596a67d7e6c@github.com>

On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From erikj at openjdk.org  Mon Oct 17 17:41:07 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Oct 2022 17:41:07 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
 <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
Message-ID: <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>

On Mon, 17 Oct 2022 17:16:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The change looks harmless. Howevere I don't understand how searching for the standard Windows libs can then become frustrating.

I believe this is part of the effort for https://bugs.openjdk.org/browse/JDK-8288293.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From asemenyuk at openjdk.org  Mon Oct 17 17:46:04 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 17 Oct 2022 17:46:04 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
 <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
 <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>
Message-ID: <bVlrub4RmKlF4OQ1B7hhwVOSL6wysDgQjLBqKqSfTIU=.89091be9-b6c4-4071-91c9-2e85b268bd68@github.com>

On Mon, 17 Oct 2022 17:37:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I believe this is part of the effort for https://bugs.openjdk.org/browse/JDK-8288293.

Agree. I'd prefer to have a different description of the bug though to make it clear that this is necessary for decoupling a compiler and an OS.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From mpowers at openjdk.org  Mon Oct 17 17:53:12 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 17 Oct 2022 17:53:12 GMT
Subject: RFR: JDK-8293681 ResponseAPDU getData() method javadoc
Message-ID: <y8j4pROipm1TE-W9vQ-Ff51ZaZh59Oo69BlQEp915Y4=.ded94518-9125-408e-9a42-674b342865be@github.com>

https://bugs.openjdk.org/browse/JDK-8293681

-------------

Commit messages:
 - first iteration

Changes: https://git.openjdk.org/jdk/pull/10732/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293681
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10732.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10732/head:pull/10732

PR: https://git.openjdk.org/jdk/pull/10732

From jwaters at openjdk.org  Mon Oct 17 21:00:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 21:00:10 GMT
Subject: Integrated: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <LJqNsfDg8OzA5tusYcYOBxXZnvR0HQH1dmryNmNTJnM=.c6e7c7fa-efd1-4f09-a3cf-02689ce58e20@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

This pull request has now been integrated.

Changeset: 8d751de3
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d751de3198675b22704cdccafaff2fc0fdd3f59
Stats:     26 lines in 14 files changed: 3 ins; 6 del; 17 mod

8295231: Move all linking of native libraries to make

Reviewed-by: ihse, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From valeriep at openjdk.org  Tue Oct 18 03:51:59 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 18 Oct 2022 03:51:59 GMT
Subject: RFR: JDK-8293681 ResponseAPDU getData() method javadoc
In-Reply-To: <y8j4pROipm1TE-W9vQ-Ff51ZaZh59Oo69BlQEp915Y4=.ded94518-9125-408e-9a42-674b342865be@github.com>
References: <y8j4pROipm1TE-W9vQ-Ff51ZaZh59Oo69BlQEp915Y4=.ded94518-9125-408e-9a42-674b342865be@github.com>
Message-ID: <yvZTrMtYok9Wjc-v-6SyKSCnGBrV_YBLnY8k2FiZY2U=.12c475a7-4577-436e-a902-34c2577dd253@github.com>

On Mon, 17 Oct 2022 17:45:13 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293681

Looks good. Thanks~

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10732

From jpai at openjdk.org  Tue Oct 18 09:34:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Oct 2022 09:34:47 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v6]
In-Reply-To: <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
Message-ID: <PKuaybhxN84oCkg5JuIFQuVDD5JBA41ceDqQoY5z2To=.de1b3a51-9407-4435-990c-4da7e127a23b@github.com>

On Mon, 17 Oct 2022 15:32:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update filter docs to match implementation.

The latest state of this PR in `4449dda` looks good to me. Thank you Aleksei.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10578

From coffeys at openjdk.org  Tue Oct 18 11:45:02 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Oct 2022 11:45:02 GMT
Subject: Integrated: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <Rl862xTOhIUsE-DDxA6obudF2yZPG6fd4xXvCQSDH7Y=.dda72aad-6737-4246-9494-a1f4300aa2d4@github.com>

On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

This pull request has now been integrated.

Changeset: 8c40b7dc
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c40b7dc8cd7b6a6d0c9349b991e0e01b69349c3
Stats:     393 lines in 12 files changed: 248 ins; 0 del; 145 mod

8292177: InitialSecurityProperty JFR event

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From dfuchs at openjdk.org  Tue Oct 18 13:03:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Oct 2022 13:03:31 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v6]
In-Reply-To: <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
Message-ID: <MNkZSXSe3DMkXbyWcyTvF8XQmw75WJ3nk4TTbpjjE_c=.10f4d62b-d612-4613-a338-734a082aec71@github.com>

On Mon, 17 Oct 2022 15:32:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update filter docs to match implementation.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From mbaesken at openjdk.org  Tue Oct 18 14:46:00 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Oct 2022 14:46:00 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests
In-Reply-To: <RcXolpYzDbrDfq-bR8EWCwAFyyVDikrT0HOweeiT0dM=.bd74118a-8fd2-4ff1-b251-a2127bca3a8c@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <RcXolpYzDbrDfq-bR8EWCwAFyyVDikrT0HOweeiT0dM=.bd74118a-8fd2-4ff1-b251-a2127bca3a8c@github.com>
Message-ID: <NR5ssaUBuZgZ3LuBa10x-MxredfXNk8MkzaXD2BXVoc=.7189cc6b-28f5-421f-a16a-2e6c868fc0c3@github.com>

On Mon, 17 Oct 2022 17:06:11 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> There are several other files in the pkcs11 directory where cause is missing from the thrown exception. Might as well fix them all.

Hi, I first focused on the exceptions I saw when looking into 8295343  (issues  with some pkcs11 related tests on RHEL 8).
But  indeed there are a couple other exceptions where the cause is missing.

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From mbaesken at openjdk.org  Tue Oct 18 14:55:12 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Oct 2022 14:55:12 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
Message-ID: <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>

> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
> 
> https://bugs.openjdk.org/browse/JDK-8295343
> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
> 
> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  More causes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10726/files
  - new: https://git.openjdk.org/jdk/pull/10726/files/d8dad7ed..ed346e06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10726&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10726&range=00-01

  Stats: 18 lines in 5 files changed: 8 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10726/head:pull/10726

PR: https://git.openjdk.org/jdk/pull/10726

From ihse at openjdk.org  Tue Oct 18 15:45:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 15:45:02 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <v3W5NeJ07ZOb3Q9438eICJZDJYgnGRzSmOSQ_YixhIM=.61781355-3c3b-4a8c-b18f-a64d71771dee@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

I noticed that a couple of files where missing copyright headers, when I tried to update those. I did some code archaeology and found out which year they were created, and added a copyright header.

Just to be reasonably sure that I did not affect any tests, I have let this go through the GHA and our internal CI testing tier1-3. The failed GHA test is `SuperWaitTest`, which I did not modify.

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From ihse at openjdk.org  Tue Oct 18 15:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 15:45:01 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code
Message-ID: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>

This is a continuation of the effort to update all our URLs to the new top-level domain.

This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.

I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

-------------

Commit messages:
 - 8295470: Update openjdk.java.net => openjdk.org URLs in test code

Changes: https://git.openjdk.org/jdk/pull/10744/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295470
  Stats: 138 lines in 45 files changed: 46 ins; 0 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/10744.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10744/head:pull/10744

PR: https://git.openjdk.org/jdk/pull/10744

From michaelm at openjdk.org  Tue Oct 18 16:03:57 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 18 Oct 2022 16:03:57 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <CfPkyYI0R_caEpiCxoTNMXatXKfS_8jk6xM0IzrMlFc=.881f4da4-2de8-4044-a51f-dfdd87ed360f@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

net changes look fine

-------------

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10744

From prr at openjdk.org  Tue Oct 18 16:51:10 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 18 Oct 2022 16:51:10 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <m0t2ZmdJ-yCzmpDu8zgql3thiOR8ea2bRlp9F1X6_ZM=.b720bff5-afdd-41e1-984a-be2b0bf95067@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From darcy at openjdk.org  Tue Oct 18 17:24:02 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Oct 2022 17:24:02 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <h2_NlmWAUfCsO8WRXBZKPYWb4jBgLGigcLgk15s97S4=.a0d0812b-0952-4bb0-828c-508a4304f048@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From mchhipa at openjdk.org  Tue Oct 18 19:56:22 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 18 Oct 2022 19:56:22 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
Message-ID: <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>

On Mon, 17 Oct 2022 16:57:06 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertThrows an exception in InconsistentEntries test.

test/jdk/javax/crypto/CryptoPermissions/default_local.policy line 4:

> 2:     permission javax.crypto.CryptoAllPermission;
> 3:     permission javax.crypto.CryptoPermission "DES", 64;
> 4: }

please remove extra line.

test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 46:

> 44:  * @summary standard extensions path is hard-coded in default
> 45:  *      system policy file
> 46:  *

No need to repeat these statement again.

test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 54:

> 52:  * @bug 4993819
> 53:  * @summary standard extensions path is hard-coded in default
> 54:  *      system policy file

No need to repeat these statement.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From mchhipa at openjdk.org  Tue Oct 18 19:59:22 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 18 Oct 2022 19:59:22 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
Message-ID: <dQ470QgtAwC38FFw4ER0Pe6HVlVU6l2qNRcxHKN8u_A=.10932b33-291e-43e7-8f8f-befd740facf7@github.com>

On Mon, 17 Oct 2022 16:57:06 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertThrows an exception in InconsistentEntries test.

Looks good to me. Please update few formatting related comments.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Tue Oct 18 22:16:47 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 18 Oct 2022 22:16:47 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
 <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
Message-ID: <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>

On Tue, 18 Oct 2022 19:53:50 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AssertThrows an exception in InconsistentEntries test.
>
> test/jdk/javax/crypto/CryptoPermissions/default_local.policy line 4:
> 
>> 2:     permission javax.crypto.CryptoAllPermission;
>> 3:     permission javax.crypto.CryptoPermission "DES", 64;
>> 4: }
> 
> please remove extra line.

I double-checked, there is no extra line at the end of this file.

> test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 46:
> 
>> 44:  * @summary standard extensions path is hard-coded in default
>> 45:  *      system policy file
>> 46:  *
> 
> No need to repeat these statement again.

Are you saying that we don't need to run the ExtDir2.policy and ExtDir3.policy?

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From sviswanathan at openjdk.org  Tue Oct 18 23:25:10 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 18 Oct 2022 23:25:10 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <523ASDMlZe7mAZaBQe3ipxBLaLum7_XZqLLUUgsCJi0=.db28f521-c957-4fb2-8dcc-7c09d46189e3@github.com>

On Wed, 5 Oct 2022 21:28:26 GMT, vpaprotsk <duke at openjdk.org> wrote:

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 262:

> 260:     private static void processMultipleBlocks(byte[] input, int offset, int length, byte[] aBytes, byte[] rBytes) {
> 261:         MutableIntegerModuloP A = ipl1305.getElement(aBytes).mutable();
> 262:         MutableIntegerModuloP R = ipl1305.getElement(rBytes).mutable();

R doesn't need to be mutable.

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 286:

> 284:      * numeric values.
> 285:      */
> 286:     private void setRSVals() { //throws InvalidKeyException {

The R and S check for invalid key (all bytes zero) could be submitted as a separate PR. 
It is not related to the Poly1305 acceleration.

test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/java.base/com/sun/crypto/provider/Poly1305IntrinsicFuzzTest.java line 39:

> 37:         public static void main(String[] args) throws Exception {
> 38:                 //Note: it might be useful to increase this number during development of new Poly1305 intrinsics
> 39:                 final int repeat = 100;

Should we increase this repeat count for the c2 compiler to kick in for compiling engineUpdate() and have the call to stub in place from there?

test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/java.base/com/sun/crypto/provider/Poly1305KAT.java line 133:

> 131:             System.out.println("*** Test " + ++testNumber + ": " +
> 132:                     test.testName);
> 133:             if (runSingleTest(test)) {

runSingleTest may need to be called enough number of times for the engineUpdate to be compiled by c2.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From aefimov at openjdk.org  Wed Oct 19 11:34:35 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 19 Oct 2022 11:34:35 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v7]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <D_ksOPRyLbfskloPWPfJdbmZEZ-375vDyp6LYg1MlOo=.42ab57e6-afd7-479e-9ff2-285f0a949cb3@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov 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 11 additional commits since the last revision:

 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Update filter docs to match implementation.
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Remove factory builder synchronization from NamingManager. Update comments/docs.
 - Change checkInput to be the global filter centric
 - Refactor checkInput, better reporting for invalid filter patterns
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/91faca3a...fbc4d577

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/4449dda1..fbc4d577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=05-06

  Stats: 8758 lines in 746 files changed: 5155 ins; 1434 del; 2169 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From alanb at openjdk.org  Wed Oct 19 13:41:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Oct 2022 13:41:46 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <oEDAuhIBqZqqS3y_9Q7BuQkndrxJSU-ozVrKMhAUr3g=.875d970e-8dc9-4240-97bb-19623b89a247@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

This updates several tests that are also in Doug Lea's CVS for j.u.concurrent. That should be okay, just need to get them in sync at some point.

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From aefimov at openjdk.org  Wed Oct 19 14:46:07 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 19 Oct 2022 14:46:07 GMT
Subject: Integrated: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <tFEqEi8ZsbIS6DW5ZzZQKPD_fb8on-ke45_fz4IGEmk=.f7e9a1ba-f640-41e1-9664-0ed0817c1597@github.com>

On Wed, 5 Oct 2022 15:23:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

This pull request has now been integrated.

Changeset: d37ce4cd
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d37ce4cdd18afc4facf996598f79e72aae68f4ff
Stats:     1566 lines in 22 files changed: 1211 ins; 303 del; 52 mod

8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

Reviewed-by: dfuchs, rriggs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jbhateja at openjdk.org  Wed Oct 19 16:30:04 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 19 Oct 2022 16:30:04 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <npOOltGaDg0pBoDy--l6gRcVb6yshqt-F63jJNkLTas=.bd69a7a6-c9c1-4d08-9e6c-0e7409a64166@github.com>

On Wed, 5 Oct 2022 21:28:26 GMT, vpaprotsk <duke at openjdk.org> wrote:

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

Some initial assembler level comments.

src/hotspot/cpu/x86/assembler_x86.cpp line 5484:

> 5482: 
> 5483: void Assembler::evpunpckhqdq(XMMRegister dst, KRegister mask, XMMRegister src1, XMMRegister src2, bool merge, int vector_len) {
> 5484:   assert(UseAVX > 2, "requires AVX512F");

Please replace flag with feature EVEX check.

src/hotspot/cpu/x86/assembler_x86.cpp line 7831:

> 7829: 
> 7830: void Assembler::vpandq(XMMRegister dst, XMMRegister nds, Address src, int vector_len) {
> 7831:   assert(VM_Version::supports_evex(), "");

Assertion should check existence of AVX512VL for non 512 but vectors.

src/hotspot/cpu/x86/assembler_x86.cpp line 7958:

> 7956: 
> 7957: void Assembler::vporq(XMMRegister dst, XMMRegister nds, Address src, int vector_len) {
> 7958:   assert(VM_Version::supports_evex(), "");

Same as above

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1960:

> 1958: address StubGenerator::generate_poly1305_masksCP() {
> 1959:   StubCodeMark mark(this, "StubRoutines", "generate_poly1305_masksCP");
> 1960:   address start = __ pc();

You may use [align64](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L777) here, like

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From mchhipa at openjdk.org  Wed Oct 19 16:53:03 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 19 Oct 2022 16:53:03 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
Message-ID: <kuEEZwYSUrURbOW6cTEwb3xDo3NeAJbnbuW-CWF_ZF0=.c54775d1-4a01-4618-b9d0-ea9cdfef0940@github.com>

On Mon, 17 Oct 2022 16:57:06 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertThrows an exception in InconsistentEntries test.

Looks good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From mchhipa at openjdk.org  Wed Oct 19 16:53:05 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 19 Oct 2022 16:53:05 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
 <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
 <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>
Message-ID: <aCzEuNkifbMrbyl3CJkWfNqtBK45oFLV0gbVfPQ8kQw=.c82f097b-b74f-4266-98d8-0b6db933098e@github.com>

On Tue, 18 Oct 2022 22:11:57 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/javax/crypto/CryptoPermissions/default_local.policy line 4:
>> 
>>> 2:     permission javax.crypto.CryptoAllPermission;
>>> 3:     permission javax.crypto.CryptoPermission "DES", 64;
>>> 4: }
>> 
>> please remove extra line.
>
> I double-checked, there is no extra line at the end of this file.

Ok

>> test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 46:
>> 
>>> 44:  * @summary standard extensions path is hard-coded in default
>>> 45:  *      system policy file
>>> 46:  *
>> 
>> No need to repeat these statement again.
>
> Are you saying that we don't need to run the ExtDir2.policy and ExtDir3.policy?

Its fine, ignore my previous comment.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Wed Oct 19 20:06:21 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 19 Oct 2022 20:06:21 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v4]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <lx1wq-j0m7IGx9eMqwGKdFoQNNElmcWWPVYIxd4TWWw=.adfcaeed-788e-4b90-9257-1bb1565e128b@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Added an extra line to the end of the policy file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/cfb9f74d..8b45f39f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From mpowers at openjdk.org  Wed Oct 19 22:57:56 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 19 Oct 2022 22:57:56 GMT
Subject: RFR: JDK-8293681 ResponseAPDU getData() method javadoc
In-Reply-To: <yvZTrMtYok9Wjc-v-6SyKSCnGBrV_YBLnY8k2FiZY2U=.12c475a7-4577-436e-a902-34c2577dd253@github.com>
References: <y8j4pROipm1TE-W9vQ-Ff51ZaZh59Oo69BlQEp915Y4=.ded94518-9125-408e-9a42-674b342865be@github.com>
 <yvZTrMtYok9Wjc-v-6SyKSCnGBrV_YBLnY8k2FiZY2U=.12c475a7-4577-436e-a902-34c2577dd253@github.com>
Message-ID: <UJ8ew0E6hIeP6TwhN5oLlsMbh6kYHf09tJHBj3Yyhbc=.4c3ed65b-2561-46e2-b134-8b90e77df8b0@github.com>

On Tue, 18 Oct 2022 03:48:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293681
>
> Looks good. Thanks~

@valeriepeng thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/10732

From ihse at openjdk.org  Thu Oct 20 10:36:03 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:36:03 GMT
Subject: Integrated: 8295470: Update openjdk.java.net => openjdk.org URLs in
 test code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <ikUR8BWcMaOfzg0XpZjCi7OeWhugVYhHsAcXp2KZV1k=.0baf7f30-4033-44f8-b6ea-19442a984b97@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

This pull request has now been integrated.

Changeset: d5a1521f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5a1521fde3f6ff7e810e8257a4722a09c9ef60b
Stats:     138 lines in 45 files changed: 46 ins; 0 del; 92 mod

8295470: Update openjdk.java.net => openjdk.org URLs in test code

Reviewed-by: michaelm, prr, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From ihse at openjdk.org  Thu Oct 20 12:06:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 12:06:27 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
Message-ID: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>

Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).

The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

-------------

Commit messages:
 - 8295729: Add jcheck whitespace checking for properties files

Changes: https://git.openjdk.org/jdk/pull/10792/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295729
  Stats: 1105 lines in 368 files changed: 0 ins; 0 del; 1105 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From erikj at openjdk.org  Thu Oct 20 18:06:01 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:06:01 GMT
Subject: RFR: 8295716: Minimize disabled warnings in security libs
In-Reply-To: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
References: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
Message-ID: <C_hTNhozwawu9AmPdvWJoKbfNDoh6omJ7XuOHNMC8pM=.f3e0f2cd-75ff-427e-91bb-822155f39d4b@github.com>

On Thu, 20 Oct 2022 10:19:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the security native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10787

From erikj at openjdk.org  Thu Oct 20 18:26:46 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:26:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <NObZDn88VUQ8fHaLhcrqe0wkth0EfVAwjWA7K4eAY2k=.0c70399e-f307-4ca4-a637-e2f1ebedf960@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Nice job!

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 18:33:47 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 18:33:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

LGTM. Haven't looked at all the l10n files.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Thu Oct 20 18:40:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:40:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I would vote against this change.  Per java properties spec
https://github.com/openjdk/jdk/pull/10792


White space following the property value is not ignored, and is treated as part of the property value.


This change might break localization or messages where trailing whitespace is important (example: "Label: ")

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Thu Oct 20 18:48:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:48:17 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> I would vote against this change.  Per java properties spec
> https://github.com/openjdk/jdk/pull/10792
> 
> 
> White space following the property value is not ignored, and is treated as part of the property value.
> 
> 
> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
> 
> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
> 
> 
> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;

@andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From erikj at openjdk.org  Thu Oct 20 18:53:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:53:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <qf8daMUSgSlaXN3bROLfbFbpzrDJh5wSJdnTYQdol64=.df762075-9646-4aab-ab95-ead96e45936a@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Given that trailing whitespace may be part of a property value, then I take back my review.

-------------

Changes requested by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From cjplummer at openjdk.org  Thu Oct 20 18:53:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 18:53:50 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <uNs096Y7_C0U9CTifzO1PL71uAgKv0RwAxTfOuL5LGw=.e8e725f6-3fac-4b54-b406-111628923ae8@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> `White space following the property value is not ignored, and is treated as part of the property value.`

Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Thu Oct 20 18:53:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:53:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
 <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
Message-ID: <HJm4YG5tr3dJ4SeXPS58BEpkBqzUEk7QwX6Cmf5x8JA=.7076b0a9-6fe2-4e0a-99f9-d3ca8a828a5a@github.com>

On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I would vote against this change.  Per java properties spec
>> https://github.com/openjdk/jdk/pull/10792
>> 
>> 
>> White space following the property value is not ignored, and is treated as part of the property value.
>> 
>> 
>> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
>> 
>> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
>> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
>> 
>> 
>> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;
>
> @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

@magicus  : 
no, this is how Properties were working from day one.


package goryachev.research;

import java.io.IOException;
import java.io.StringReader;
import java.util.Properties;

public class TestProperties {
    public static void main(String[] args) throws IOException {
        String text = "key= value ";
        Properties p = new Properties();
        p.load(new StringReader(text));
        System.out.println("value=["  +p.getProperty("key") + "]");
    }
}


outputs:

value=[value ]

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Thu Oct 20 19:07:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:07:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <vN85_fh3ocln38nEOKYh1GBwW5xzb3nIo_jYOQYqiLY=.6e65e099-3d3c-40fe-8cfa-1acf25fdd0a7@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Okay. That definitely rules out adding .properties to the whitespace jcheck verification.

However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language.

I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes.

For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct.

Does that sound reasonable?

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 19:29:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:29:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <iu-qPLbaWYYTSq2jVgsGXDGt8Weqq2RVuoaHyuI0YRg=.f4131b5a-9685-4246-bbac-85b776fee6e3@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Retracting my approval too. Thanks for the catch, Andy!
That sounds reasonable > Magnus

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 19:40:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:40:55 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <eJ0YaIIkCYOV7stEG2AEVx05evyYix9H9Zp2eAlJsjA=.2e14e322-75f6-4651-bb96-c24cf2f10391@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

(retracting approval)

-------------

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Oct 21 08:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:17:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove check for .properties from jcheck
 - Restore trailing whitespace for property values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00-01

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Oct 21 08:31:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:31:59 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines.

I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From thartmann at openjdk.org  Fri Oct 21 10:00:48 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Oct 2022 10:00:48 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <GngrT4IEygRXlLwO_Qg7E5-1R-PrNAeprX5ZNBjWWjY=.b513408a-88a4-4a5b-9f6b-dec39b379803@github.com>

On Wed, 5 Oct 2022 21:28:26 GMT, vpaprotsk <duke at openjdk.org> wrote:

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

I executed some quick testing and this fails with:


[2022-10-21T09:54:28,696Z] # A fatal error has been detected by the Java Runtime Environment:
[2022-10-21T09:54:28,696Z] #
[2022-10-21T09:54:28,696Z] #  Internal Error (/opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S8380/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/5903b026-cdbd-4aa4-8433-6a45fb7ee593/runs/f75b29aa-40ef-46a5-b323-3a80aaa9aa6b/workspace/open/src/hotspot/cpu/x86/assembler_x86.cpp:5358), pid=2385300, tid=2385302
[2022-10-21T09:54:28,696Z] #  Error: assert(vector_len == AVX_128bit ? VM_Version::supports_avx() : vector_len == AVX_256bit ? VM_Version::supports_avx2() : vector_len == AVX_512bit ? VM_Version::supports_avx512bw() : 0) failed
[2022-10-21T09:54:28,696Z] #
[2022-10-21T09:54:28,696Z] # JRE version:  (20.0) (fastdebug build )
[2022-10-21T09:54:28,696Z] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-internal-2022-10-21-0733397.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
[2022-10-21T09:54:28,696Z] # Problematic frame:
[2022-10-21T09:54:28,696Z] # V  [libjvm.so+0x6e3bf0]  Assembler::vpslldq(XMMRegister, XMMRegister, int, int)+0x190

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From erikj at openjdk.org  Fri Oct 21 12:59:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 12:59:48 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <AoFGXlCHPgwZa3u0Kwp6W-h5k-I_Malb2gWa3tSxSbw=.500a110c-0c73-4205-9a2e-e281bfb3a730@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Fri Oct 21 16:09:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 16:09:28 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020".  This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Fri Oct 21 16:09:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Oct 2022 16:09:29 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
Message-ID: <khuIARsEyKMyIfUxBD69kijyjnwDFCzAra51YwctMyY=.71b00eb7-1312-4db9-a6a5-ff85f7635132@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> replace those dangling white spaces with explicit Unicode escapes

this is a *very good* idea.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Fri Oct 21 18:09:51 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 21 Oct 2022 18:09:51 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <GngrT4IEygRXlLwO_Qg7E5-1R-PrNAeprX5ZNBjWWjY=.b513408a-88a4-4a5b-9f6b-dec39b379803@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <GngrT4IEygRXlLwO_Qg7E5-1R-PrNAeprX5ZNBjWWjY=.b513408a-88a4-4a5b-9f6b-dec39b379803@github.com>
Message-ID: <YJj4_wTpLseCNdk0_wneV4TspIJVleUTui9sJq5Ryg8=.79c1428c-85c9-4492-8e06-7fb21154a81d@github.com>

On Fri, 21 Oct 2022 09:57:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> I executed some quick testing and this fails with:
> 
> 
> [2022-10-21T09:54:28,696Z] # A fatal error has been detected by the Java Runtime Environment:
> [2022-10-21T09:54:28,696Z] #
> [2022-10-21T09:54:28,696Z] #  Internal Error (/opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S8380/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/5903b026-cdbd-4aa4-8433-6a45fb7ee593/runs/f75b29aa-40ef-46a5-b323-3a80aaa9aa6b/workspace/open/src/hotspot/cpu/x86/assembler_x86.cpp:5358), pid=2385300, tid=2385302
> [2022-10-21T09:54:28,696Z] #  Error: assert(vector_len == AVX_128bit ? VM_Version::supports_avx() : vector_len == AVX_256bit ? VM_Version::supports_avx2() : vector_len == AVX_512bit ? VM_Version::supports_avx512bw() : 0) failed
> [2022-10-21T09:54:28,696Z] #
> [2022-10-21T09:54:28,696Z] # JRE version:  (20.0) (fastdebug build )
> [2022-10-21T09:54:28,696Z] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-internal-2022-10-21-0733397.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> [2022-10-21T09:54:28,696Z] # Problematic frame:
> [2022-10-21T09:54:28,696Z] # V  [libjvm.so+0x6e3bf0]  Assembler::vpslldq(XMMRegister, XMMRegister, int, int)+0x190

Hi @TobiHartmann , thanks for looking. Could you share CPU Model and flags from `hs_err` please?

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From kvn at openjdk.org  Fri Oct 21 18:23:08 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 21 Oct 2022 18:23:08 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <mBCiz0Kw_IL2BBZr1EUVDR7I62y0AI5URwtclYsADHE=.d821a38d-c77a-4d1f-af17-89cd2bf88fd2@github.com>

On Wed, 5 Oct 2022 21:28:26 GMT, vpaprotsk <duke at openjdk.org> wrote:

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

Test: jdk/incubator/vector/VectorMaxConversionTests.java#id1
Flags: `-ea -esa -XX:UseAVX=3 -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting -XX:+UseZGC`
CPU: Intel 8358 (all AVX512 features).

I think the problem is this subtest runs with ` -XX:+UseKNLSetting`[VectorMaxConversionTests.java#L50](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/incubator/vector/VectorMaxConversionTests.java#L50) which limits AVX512 features.

Call stack:

V  [libjvm.so+0x6e3bf0]  Assembler::vpslldq(XMMRegister, XMMRegister, int, int)+0x190  (assembler_x86.cpp:5358)
V  [libjvm.so+0x152a23b]  MacroAssembler::poly1305_process_blocks_avx512(Register, Register, Register, Register, Register, Register, Register, Register)+0xc7b  (macroAssembler_x86_poly.cpp:590)
V  [libjvm.so+0x152c23d]  MacroAssembler::poly1305_process_blocks(Register, Register, Register, Register)+0x3ad  (macroAssembler_x86_poly.cpp:849)
V  [libjvm.so+0x192dc00]  StubGenerator::generate_poly1305_processBlocks()+0x170  (stubGenerator_x86_64.cpp:2069)
V  [libjvm.so+0x1936a89]  StubGenerator::generate_initial()+0x419  (stubGenerator_x86_64.cpp:3798)
V  [libjvm.so+0x1937b78]  StubGenerator_generate(CodeBuffer*, int)+0xf8  (stubGenerator_x86_64.hpp:526)
V  [libjvm.so+0x198e695]  StubRoutines::initialize1() [clone .part.0]+0x155  (stubRoutines.cpp:229)
V  [libjvm.so+0xfc4342]  init_globals()+0x32  (init.cpp:123)
V  [libjvm.so+0x1a7268f]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x37f

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From mpowers at openjdk.org  Fri Oct 21 20:03:04 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 21 Oct 2022 20:03:04 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID
Message-ID: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>

https://bugs.openjdk.org/browse/JDK-8293093

-------------

Commit messages:
 - Merge
 - second iteration
 - first iteration

Changes: https://git.openjdk.org/jdk/pull/10823/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10823&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293093
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10823.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10823/head:pull/10823

PR: https://git.openjdk.org/jdk/pull/10823

From mpowers at openjdk.org  Fri Oct 21 20:03:04 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 21 Oct 2022 20:03:04 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID
In-Reply-To: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
Message-ID: <6MNXyPBdmVl0KKPVyV8ok387j-c2Q77Kosy1xKAGS-w=.501ec676-07eb-4d39-9def-a17095384531@github.com>

On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293093

I was finally able to reproduce this failure and was able to verify the fix. Took forever.

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From duke at openjdk.org  Fri Oct 21 20:12:05 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 21 Oct 2022 20:12:05 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v2]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <anXQC9q47NMON4pyIWBGBTGgxekz4Wpdf9f3P7NYYuQ=.9ae56235-df30-40fb-8575-c5e12cc20587@github.com>

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:

  Stash: fetch limbs directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/7e070d9e..6a60c128

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=00-01

  Stats: 61 lines in 3 files changed: 28 ins; 1 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10582.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10582/head:pull/10582

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 21 20:13:29 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 21 Oct 2022 20:13:29 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <uaDRVrBgtedQkTvXJ2UNxtv3pu8vpr5anFR2-MfO6Io=.7222933e-5d1a-48b8-9934-233757bad6c1@github.com>

On Wed, 5 Oct 2022 21:28:26 GMT, vpaprotsk <duke at openjdk.org> wrote:

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

(Apologies, ignore the `Stash: fetch limbs directly` commit.. got git commit command mixed up.. will force-push a fix to the crash in a sec)

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 21 20:20:58 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 21 Oct 2022 20:20:58 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v3]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

vpaprotsk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  further restrict UsePolyIntrinsics with supports_avx512vlbw

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/6a60c128..f048f938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=01-02

  Stats: 62 lines in 4 files changed: 1 ins; 28 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/10582.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10582/head:pull/10582

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 21 20:28:56 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 21 Oct 2022 20:28:56 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <mBCiz0Kw_IL2BBZr1EUVDR7I62y0AI5URwtclYsADHE=.d821a38d-c77a-4d1f-af17-89cd2bf88fd2@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <mBCiz0Kw_IL2BBZr1EUVDR7I62y0AI5URwtclYsADHE=.d821a38d-c77a-4d1f-af17-89cd2bf88fd2@github.com>
Message-ID: <GHSqD5KqJ4Fzd67pKsm4kdLYZOrbTU0k-sZDUMLYoBA=.1483ea8b-1154-4e18-bbe0-259bca4ebcaf@github.com>

On Fri, 21 Oct 2022 18:20:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> Test: jdk/incubator/vector/VectorMaxConversionTests.java#id1
> Flags: `-ea -esa -XX:UseAVX=3 -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting -XX:+UseZGC`
> CPU: Intel 8358 (all AVX512 features).
> 
> I think the problem is this subtest runs with ` -XX:+UseKNLSetting`[VectorMaxConversionTests.java#L50](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/incubator/vector/VectorMaxConversionTests.java#L50) which limits AVX512 features.
> 
> Call stack:
> 
> V  [libjvm.so+0x6e3bf0]  Assembler::vpslldq(XMMRegister, XMMRegister, int, int)+0x190  (assembler_x86.cpp:5358)
> V  [libjvm.so+0x152a23b]  MacroAssembler::poly1305_process_blocks_avx512(Register, Register, Register, Register, Register, Register, Register, Register)+0xc7b  (macroAssembler_x86_poly.cpp:590)
> V  [libjvm.so+0x152c23d]  MacroAssembler::poly1305_process_blocks(Register, Register, Register, Register)+0x3ad  (macroAssembler_x86_poly.cpp:849)
> V  [libjvm.so+0x192dc00]  StubGenerator::generate_poly1305_processBlocks()+0x170  (stubGenerator_x86_64.cpp:2069)
> V  [libjvm.so+0x1936a89]  StubGenerator::generate_initial()+0x419  (stubGenerator_x86_64.cpp:3798)
> V  [libjvm.so+0x1937b78]  StubGenerator_generate(CodeBuffer*, int)+0xf8  (stubGenerator_x86_64.hpp:526)
> V  [libjvm.so+0x198e695]  StubRoutines::initialize1() [clone .part.0]+0x155  (stubRoutines.cpp:229)
> V  [libjvm.so+0xfc4342]  init_globals()+0x32  (init.cpp:123)
> V  [libjvm.so+0x1a7268f]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x37f

Thanks @vnkozlov, was able to reproduce. @TobiHartmann, I added `supports_avx512vlbw` check to `UsePolyIntrinsics`.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Sat Oct 22 15:41:29 2022
From: duke at openjdk.org (Florent Guillaume)
Date: Sat, 22 Oct 2022 15:41:29 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID
In-Reply-To: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
Message-ID: <0a_cCW0yaOHNTtZW3_sCfpt2h2JMv_hEOHpQDo-Tw1Y=.ed7985b9-6a4d-4ac3-940c-a31ab53a606c@github.com>

On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293093

Given the repeated code wouldn't you want to create a small helper method like `getIDNullSafe`?

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From xuelei at openjdk.org  Sat Oct 22 18:31:47 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 22 Oct 2022 18:31:47 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID
In-Reply-To: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
Message-ID: <QnWsEmLspymm8_S1G9qvei0MwR2cnHXT_wWMPwUjMeA=.240746e0-50a6-4366-baba-20192cb7f48d@github.com>

On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293093

There are some other places, for example in updatePkey(), that use cka_id.  Did you have a chance to check if NPE is possible there as well?

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From prr at openjdk.org  Mon Oct 24 03:55:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:55:56 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From thartmann at openjdk.org  Mon Oct 24 09:06:55 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Oct 2022 09:06:55 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v3]
In-Reply-To: <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
Message-ID: <9XWZNcNcmELCLXDwpuNgpztPrw8xXajJQcj_daf4jhU=.4af44336-021f-4688-9a56-6a90c8e12f53@github.com>

On Fri, 21 Oct 2022 20:20:58 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> vpaprotsk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   further restrict UsePolyIntrinsics with supports_avx512vlbw

Thanks, I'll re-run testing.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From ascarpino at openjdk.org  Mon Oct 24 16:21:55 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 24 Oct 2022 16:21:55 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID
In-Reply-To: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
Message-ID: <JJ21bVmfuI5SoHcaIJQjmk7_CQLmM3YzXjUywV1rKQ8=.878e035b-edef-4cf3-928c-80daccf381ac@github.com>

On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293093

Looking at the usage of getID(), it seems like debug msgs and exceptions are where the null maybe a problem.  mapLabel() checks for null.  It maybe best to change getID(bytes[]) to return new String("null") then having if() checks for the return value.

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From mullan at openjdk.org  Mon Oct 24 17:51:45 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 24 Oct 2022 17:51:45 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID
In-Reply-To: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
Message-ID: <pGLACLpC4mVY9VkVy1a71fCfkyq4bboQAyM1oiGuSho=.993cbead-6570-4a7c-b57f-3bb4ea46cfaa@github.com>

On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293093

You should add a `noreg` label (ex: `noreg-trivial` or `noreg-other`) to the bug if you don't plan on writing a regression test.

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From mpowers at openjdk.org  Mon Oct 24 18:26:42 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 24 Oct 2022 18:26:42 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID
In-Reply-To: <0a_cCW0yaOHNTtZW3_sCfpt2h2JMv_hEOHpQDo-Tw1Y=.ed7985b9-6a4d-4ac3-940c-a31ab53a606c@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <0a_cCW0yaOHNTtZW3_sCfpt2h2JMv_hEOHpQDo-Tw1Y=.ed7985b9-6a4d-4ac3-940c-a31ab53a606c@github.com>
Message-ID: <PjV2fl5fKmxh5z1uHQ9IMF4YJsgz9pmd2p5iwe9DATk=.aa86fc58-b9af-4e6b-a755-5c2e7b2e29ac@github.com>

On Sat, 22 Oct 2022 15:37:38 GMT, Florent Guillaume <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293093
>
> Given the repeated code wouldn't you want to create a small helper method like `getIDNullSafe`?

@efge Good suggestion. And having `NullSafe` in the name answers an important question.

@XueleiFan Regarding `updatePkey`, `getID` is only used for exception messages. I'm going to use `getIDNullSafe` to prevent an unexpected exception doesn't throw yet another exception.

@ascarpino Agreed.

@seanjmullan `noreg-trivial`

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From sviswanathan at openjdk.org  Mon Oct 24 18:26:51 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 24 Oct 2022 18:26:51 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v3]
In-Reply-To: <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
Message-ID: <IlBtLSr2uKorHL7R1eQop08Y7E3BeCtjpeU8oR-fn2Q=.985d05bd-bb57-454d-9c58-3eff1af67c32@github.com>

On Fri, 21 Oct 2022 20:20:58 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> vpaprotsk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   further restrict UsePolyIntrinsics with supports_avx512vlbw

@ascarpino Could you please also take a look at this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From ihse at openjdk.org  Mon Oct 24 19:21:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:21:07 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v3]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Remove check for .properties from jcheck"
   
   This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
 - Change trailing space and tab in values to unicode encoding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01-02

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:22:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:22:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:25:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:25:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <yZpwsDUeKIrGQT3tvyGfGHFjIOuQTOBfRyvV7b-uArA=.077497ab-51b8-4346-b67d-9838e3419964@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.)

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:31:26 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
Message-ID: <HmB2uBGv-fQnz3Kn7yEA0yIR4akDfM4tmso3sgA4-aQ=.d84de722-5d04-4aad-8ba3-572eea3cacc1@github.com>

On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove check for .properties from jcheck
>>  - Restore trailing whitespace for property values
>
> 368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

@andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2

This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial.

The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21

This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:

> 185: ### Button Demo ###
> 186: 
> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020

trailing whitespace looks unnecessary (accessible description?)

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner
> 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta
> 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier
> 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella
> 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC
> 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp
> 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1}
> 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1}
> 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0}\u0020
> 127: crswriter.params2 = Value of params2 : {0}\u0020
> 128: crswriter.conflictsno =  conflicts while synchronizing\u0020

this is tricky.  if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong.  it's hard to tell without looking further into the code.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73:

> 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe
> 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen
> 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020

prob. unnecessary

-------------

Marked as reviewed by angorya (no project role).

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons:

1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems.

2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed.

And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs.


src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties
test/jdk/javax/net/ssl/Stapling/TEST.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties
test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From jjg at openjdk.org  Mon Oct 24 19:45:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
Message-ID: <cuJYgquzi3I4fULUZZz_G_ZjmEd_wDsUPw2mzCceM_w=.ad366bc4-db7f-48ad-9d3f-a8d0ba9e1820@github.com>

On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed.

probably not needed - if nobody noticed anything until now we have no problem.  the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues.

good job!

(and we can ignore my "prob. unnecessary" comments)

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <cRpIep8vLpUKvRQH3e_vwTIqVChg5uSLhFH4sSCbmOQ=.9c8e6492-c665-4666-bba9-4947cd6059b1@github.com>

On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:
> 
>> 185: ### Button Demo ###
>> 186: 
>> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020
> 
> trailing whitespace looks unnecessary (accessible description?)

although this is in demo...

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Mon Oct 24 20:02:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:02:54 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 20:12:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 20:12:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
Message-ID: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>

On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

Good idea! I wonder if this should be done as a unit test.  go through all the bundles and check leading/trailing whitespace.

in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code.  I assume the JDK has been exhaustively tested and we have no such problems.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Mon Oct 24 20:16:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:16:56 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
 <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
Message-ID: <go6bwGp8ro_LeVwOJyBes4PXwMBEGNyPvq43vxGmmLU=.ed6bfa15-4664-41ab-87a9-51609382b9cf@github.com>

On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace.

Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Mon Oct 24 20:33:07 2022
From: duke at openjdk.org (duke)
Date: Mon, 24 Oct 2022 20:33:07 GMT
Subject: Withdrawn: 8133816: Display extra SSLServerSocket info in debug mode
In-Reply-To: <sIhMa34VadZyTSX-HBdzHNr-1XexwTB-VK7vCYr-Nro=.9dbf637f-8f1c-4dc9-af8d-45d7934e84b3@github.com>
References: <sIhMa34VadZyTSX-HBdzHNr-1XexwTB-VK7vCYr-Nro=.9dbf637f-8f1c-4dc9-af8d-45d7934e84b3@github.com>
Message-ID: <5LBgvPEjta9Hj1b-5aVr29_MlYCPNR23zl6AHO9g1a8=.a3638bbe-f6e7-4ccb-ad95-238963cb77a8@github.com>

On Wed, 3 Aug 2022 15:40:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9731

From sviswanathan at openjdk.org  Mon Oct 24 20:35:53 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 24 Oct 2022 20:35:53 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v3]
In-Reply-To: <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
Message-ID: <ofzbkQvqf812wmneYOoGC6GAOvOKjbeqmjEf7P4egCg=.be88102e-0d9a-4d7c-8048-6e003397e1e7@github.com>

On Fri, 21 Oct 2022 20:20:58 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> vpaprotsk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   further restrict UsePolyIntrinsics with supports_avx512vlbw

test/micro/org/openjdk/bench/javax/crypto/full/Poly1305DigestBench.java line 37:

> 35: import java.security.spec.AlgorithmParameterSpec;
> 36: import javax.crypto.spec.SecretKeySpec;
> 37: 

Please add the following:
import org.openjdk.jmh.annotations.Fork;
@Fork(value = 1, jvmArgsAppend = {"--add-opens", "java.base/com.sun.crypto.provider=A
LL-UNNAMED"})

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From ihse at openjdk.org  Mon Oct 24 20:39:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:39:57 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
Message-ID: <HMdFi0RZ9_Jhobfq_DLpJY4wycMf6qXcIHo90U8sq80=.4a035bff-b633-400b-bbf4-c3e7111385f3@github.com>

On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning).

Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs.

And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address.

> Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 20:51:56 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:51:56 GMT
Subject: Integrated: 8295716: Minimize disabled warnings in security libs
In-Reply-To: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
References: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
Message-ID: <eYSApZrPglwwThWP6k79a6COZTBORZdpb8afMLG-yB0=.00971739-47b0-4fa3-bf00-23c5deba0f1c@github.com>

On Thu, 20 Oct 2022 10:19:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the security native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

This pull request has now been integrated.

Changeset: 1d15e5cd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d15e5cdd698045ab9c285c92b96126ed0666ac5
Stats:     4 lines in 2 files changed: 0 ins; 1 del; 3 mod

8295716: Minimize disabled warnings in security libs

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10787

From duke at openjdk.org  Mon Oct 24 22:06:56 2022
From: duke at openjdk.org (vpaprotsk)
Date: Mon, 24 Oct 2022 22:06:56 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v4]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <E1eg4h2lICoRA-dr-BA7YiiwAAozL-zYbgLKbBtLW_c=.6314de12-339b-45f7-b610-9a4842fe8bdd@github.com>

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

vpaprotsk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - assembler checks and test case fixes
 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - Merge remote-tracking branch 'origin' into avx512-poly
 - further restrict UsePolyIntrinsics with supports_avx512vlbw
 - missed white-space fix
 - - Fix whitespace and copyright statements
   - Add benchmark
 - Merge remote-tracking branch 'vpaprotsk/master' into avx512-poly
 - Poly1305 AVX512 intrinsic for x86_64

-------------

Changes: https://git.openjdk.org/jdk/pull/10582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=03
  Stats: 1719 lines in 30 files changed: 1685 ins; 3 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/10582.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10582/head:pull/10582

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Mon Oct 24 22:06:57 2022
From: duke at openjdk.org (vpaprotsk)
Date: Mon, 24 Oct 2022 22:06:57 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v4]
In-Reply-To: <npOOltGaDg0pBoDy--l6gRcVb6yshqt-F63jJNkLTas=.bd69a7a6-c9c1-4d08-9e6c-0e7409a64166@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <npOOltGaDg0pBoDy--l6gRcVb6yshqt-F63jJNkLTas=.bd69a7a6-c9c1-4d08-9e6c-0e7409a64166@github.com>
Message-ID: <gH1-xvYZMYk852GCY85zNvZRwiClynamTvZ87dajfZo=.a2b64360-62d4-45f3-86c6-e3eeded296b4@github.com>

On Tue, 18 Oct 2022 06:26:38 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> vpaprotsk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - assembler checks and test case fixes
>>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>>  - Merge remote-tracking branch 'origin' into avx512-poly
>>  - further restrict UsePolyIntrinsics with supports_avx512vlbw
>>  - missed white-space fix
>>  - - Fix whitespace and copyright statements
>>    - Add benchmark
>>  - Merge remote-tracking branch 'vpaprotsk/master' into avx512-poly
>>  - Poly1305 AVX512 intrinsic for x86_64
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 5484:
> 
>> 5482: 
>> 5483: void Assembler::evpunpckhqdq(XMMRegister dst, KRegister mask, XMMRegister src1, XMMRegister src2, bool merge, int vector_len) {
>> 5484:   assert(UseAVX > 2, "requires AVX512F");
> 
> Please replace flag with feature EVEX check.

done

> src/hotspot/cpu/x86/assembler_x86.cpp line 7831:
> 
>> 7829: 
>> 7830: void Assembler::vpandq(XMMRegister dst, XMMRegister nds, Address src, int vector_len) {
>> 7831:   assert(VM_Version::supports_evex(), "");
> 
> Assertion should check existence of AVX512VL for non 512 but vectors.

done

> src/hotspot/cpu/x86/assembler_x86.cpp line 7958:
> 
>> 7956: 
>> 7957: void Assembler::vporq(XMMRegister dst, XMMRegister nds, Address src, int vector_len) {
>> 7958:   assert(VM_Version::supports_evex(), "");
> 
> Same as above

done

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1960:
> 
>> 1958: address StubGenerator::generate_poly1305_masksCP() {
>> 1959:   StubCodeMark mark(this, "StubRoutines", "generate_poly1305_masksCP");
>> 1960:   address start = __ pc();
> 
> You may use [align64](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L777) here, like

done

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Mon Oct 24 22:06:58 2022
From: duke at openjdk.org (vpaprotsk)
Date: Mon, 24 Oct 2022 22:06:58 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v4]
In-Reply-To: <523ASDMlZe7mAZaBQe3ipxBLaLum7_XZqLLUUgsCJi0=.db28f521-c957-4fb2-8dcc-7c09d46189e3@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <523ASDMlZe7mAZaBQe3ipxBLaLum7_XZqLLUUgsCJi0=.db28f521-c957-4fb2-8dcc-7c09d46189e3@github.com>
Message-ID: <q3RAliJ4HzQUkk4vJYctC6lV77ejuR1pLuxV8fmdHHA=.d21f345c-2639-449b-a358-c1ee81ecf71a@github.com>

On Tue, 18 Oct 2022 23:03:55 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> vpaprotsk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - assembler checks and test case fixes
>>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>>  - Merge remote-tracking branch 'origin' into avx512-poly
>>  - further restrict UsePolyIntrinsics with supports_avx512vlbw
>>  - missed white-space fix
>>  - - Fix whitespace and copyright statements
>>    - Add benchmark
>>  - Merge remote-tracking branch 'vpaprotsk/master' into avx512-poly
>>  - Poly1305 AVX512 intrinsic for x86_64
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 262:
> 
>> 260:     private static void processMultipleBlocks(byte[] input, int offset, int length, byte[] aBytes, byte[] rBytes) {
>> 261:         MutableIntegerModuloP A = ipl1305.getElement(aBytes).mutable();
>> 262:         MutableIntegerModuloP R = ipl1305.getElement(rBytes).mutable();
> 
> R doesn't need to be mutable.

done

> test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/java.base/com/sun/crypto/provider/Poly1305IntrinsicFuzzTest.java line 39:
> 
>> 37:         public static void main(String[] args) throws Exception {
>> 38:                 //Note: it might be useful to increase this number during development of new Poly1305 intrinsics
>> 39:                 final int repeat = 100;
> 
> Should we increase this repeat count for the c2 compiler to kick in for compiling engineUpdate() and have the call to stub in place from there?

did it with `@run main/othervm -Xcomp -XX:-TieredCompilation com.sun.crypto.provider.Cipher.ChaCha20.Poly1305UnitTestDriver`

> test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/java.base/com/sun/crypto/provider/Poly1305KAT.java line 133:
> 
>> 131:             System.out.println("*** Test " + ++testNumber + ": " +
>> 132:                     test.testName);
>> 133:             if (runSingleTest(test)) {
> 
> runSingleTest may need to be called enough number of times for the engineUpdate to be compiled by c2.

added a second copy with `@run main/othervm -Xcomp -XX:-TieredCompilation com.sun.crypto.provider.Cipher.ChaCha20.Poly1305UnitTestDriver`

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Mon Oct 24 22:07:00 2022
From: duke at openjdk.org (vpaprotsk)
Date: Mon, 24 Oct 2022 22:07:00 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v3]
In-Reply-To: <ofzbkQvqf812wmneYOoGC6GAOvOKjbeqmjEf7P4egCg=.be88102e-0d9a-4d7c-8048-6e003397e1e7@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
 <ofzbkQvqf812wmneYOoGC6GAOvOKjbeqmjEf7P4egCg=.be88102e-0d9a-4d7c-8048-6e003397e1e7@github.com>
Message-ID: <WoCxm_uiDg0HFNwBVue0jE0WtPbAZyApGYfG5eypRhM=.e63759e8-bbe7-408c-b2a8-a2be50b1be84@github.com>

On Mon, 24 Oct 2022 20:31:31 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> vpaprotsk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   further restrict UsePolyIntrinsics with supports_avx512vlbw
>
> test/micro/org/openjdk/bench/javax/crypto/full/Poly1305DigestBench.java line 37:
> 
>> 35: import java.security.spec.AlgorithmParameterSpec;
>> 36: import javax.crypto.spec.SecretKeySpec;
>> 37: 
> 
> Please add the following:
> import org.openjdk.jmh.annotations.Fork;
> @Fork(value = 1, jvmArgsAppend = {"--add-opens", "java.base/com.sun.crypto.provider=A
> LL-UNNAMED"})

done. Also added longer warmup

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Mon Oct 24 22:09:29 2022
From: duke at openjdk.org (vpaprotsk)
Date: Mon, 24 Oct 2022 22:09:29 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:

  extra whitespace character

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/de7e138b..883be106

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10582.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10582/head:pull/10582

PR: https://git.openjdk.org/jdk/pull/10582

From sviswanathan at openjdk.org  Tue Oct 25 00:34:53 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 25 Oct 2022 00:34:53 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
Message-ID: <Kc1IpZcXV95qbdzVNsLaTKt4VRdafGSxXd1sqVSpsPc=.ba9f3752-817b-4cc1-82b8-edb09c6a0ce8@github.com>

On Mon, 24 Oct 2022 22:09:29 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra whitespace character

src/hotspot/cpu/x86/assembler_x86.cpp line 8306:

> 8304:   assert(dst != xnoreg, "sanity");
> 8305:   InstructionMark im(this);
> 8306:   InstructionAttr attributes(vector_len, /* vex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true);

no_mask_reg should be set to true here as we are not setting the mask register here.

src/hotspot/cpu/x86/stubRoutines_x86.cpp line 83:

> 81: address StubRoutines::x86::_join_2_3_base64 = NULL;
> 82: address StubRoutines::x86::_decoding_table_base64 = NULL;
> 83: address StubRoutines::x86::_poly1305_mask_addr = NULL;

Please also update the copyright year to 2022 for stubRoutines_x86.cpp and hpp files.

src/hotspot/cpu/x86/vm_version_x86.cpp line 925:

> 923:     _features &= ~CPU_AVX512_VBMI2;
> 924:     _features &= ~CPU_AVX512_BITALG;
> 925:     _features &= ~CPU_AVX512_IFMA;

This should also be done under is_knights_family().

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 175:

> 173:             // Choice of 1024 is arbitrary, need enough data blocks to amortize conversion overhead
> 174:             // and not affect platforms without intrinsic support
> 175:             int blockMultipleLength = (len/BLOCK_LENGTH) * BLOCK_LENGTH;

The ByteBuffer version can also benefit from this optimization if it has array as backing storage.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From cjplummer at openjdk.org  Tue Oct 25 03:16:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Oct 2022 03:16:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <qb_ryMLGem495x0rBbOxd4vVGYPmnRiOkynx6AmvZVE=.5c5d3ee8-8498-4d6d-bfec-04a075ab085c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Changes requested by cjplummer (Reviewer).

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From peter.firmstone at zeus.net.au  Tue Oct 25 06:02:28 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 25 Oct 2022 16:02:28 +1000
Subject: Command line flag to disable finalizers.
In-Reply-To: <95e54dac-e969-ffc6-cb84-9fa4cd0988c4@oracle.com>
References: <CANghgrQqQBOZW7t8Jm0nHL6Kc9BbvXJmwakpDskX1zegjGeiMw@mail.gmail.com>
 <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com>
 <CANghgrTC8mO_+p5naUpNVyGtUWg4=NoTyDgSzTa1S=V1XWQvjg@mail.gmail.com>
 <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com>
 <CANghgrSzOX=qXD14nMrVCui4rR0Vot-qnw+ian7T4CgzRWEm5g@mail.gmail.com>
 <db477f2f-d577-5065-62c4-e654c2e76729@zeus.net.au>
 <95e54dac-e969-ffc6-cb84-9fa4cd0988c4@oracle.com>
Message-ID: <f9352fcb-401a-8501-460c-a6ede244407d@zeus.net.au>

Hi Sean,

I only just read this email, thanks, it allows us to start investigating 
a new authorization layer.

Regards,

Peter.

On 21/04/2022 1:01 am, Sean Mullan wrote:
>
> On 4/15/22 10:46 PM, Peter Firmstone wrote:
>> To securely instrument access controls onto public Java API, we need to
>> have the ability to disable finalizers, to prevent finalizer attacks
>> from circumventing access controls.
>>
>> Since finalizers are planned for removal, as soon as finalizers are
>> officially deprecated, I propose a command line flag be provided to
>> disable jvm calls to finalizer methods.
>
> This is already supported. JEP 421 added a "--finalization=disabled" 
> option to JDK 18:
>
> https://openjdk.java.net/jeps/421#Command-line-option-to-disable-finalization 
>
>
> --Sean
>

From peter.firmstone at zeus.net.au  Tue Oct 25 06:25:30 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 25 Oct 2022 16:25:30 +1000
Subject: Request - Preparation for removal of SecurityManager
Message-ID: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>

Would the OpenJDK team consider the following?

Where SecurityManager is invoked directly now, such as:


 ??????? @SuppressWarnings("removal")
 ??????? SecurityManager sm = System.getSecurityManager();
 ??????? if (sm != null)
 ??????????? sm.checkPermission(new RuntimePermission("setFactory"));

Can we change these routines to the simpler form:

 ??? ??? newRuntimePermission("setFactory").checkGuard(null);

This will give us more time to transition to a replacement authorization 
layer.

We can instrument the Permission#checkGuard method, this will assist us 
to utilise existing Permission check hooks after SecurityManager is 
removed.??? Longer term we will need to maintain our own instrumentation 
hooks, but this will go a long way towards giving us a head start, by 
leveraging the existing.

-- 
Regards,
  
Peter Firmstone


From weijun at openjdk.org  Tue Oct 25 13:30:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:30:53 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <c28cQxkcVp8YCkAe0wDP4b7cUvb424JsH9ls5bR3m48=.31cad672-bef6-4d55-983d-2cb32a0cafea@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

I'm quite sure this space can be safely removed.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From coffeys at openjdk.org  Tue Oct 25 13:44:09 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 25 Oct 2022 13:44:09 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v2]
In-Reply-To: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
Message-ID: <Exa2xjTiGUTAH2K57E4E03UAmmUK4NlBlZHqu6OJeMM=.241f4f05-882c-45d1-92a5-4266e5b6f23b@github.com>

> By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)
> 
> test case also updated to capture new logic

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - blessed modifiers
 - Merge branch 'master' into 8292033-x509Event
 - restore import style
 - Merge branch 'master' into 8292033-x509Event
 - Minor clean up
 - Merge branch 'master' into 8292033-x509Event
 - update commit method name
 - Record all X509 generate events
 - fix up merge
 - merge with master
 - ... and 1 more: https://git.openjdk.org/jdk/compare/f37a6055...c58e0fa6

-------------

Changes: https://git.openjdk.org/jdk/pull/10422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10422&range=01
  Stats: 124 lines in 6 files changed: 61 ins; 49 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10422.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10422/head:pull/10422

PR: https://git.openjdk.org/jdk/pull/10422

From weijun at openjdk.org  Tue Oct 25 13:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:47:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

I suggest we focus on the English files this time and file a bug to the translation tool.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From weijun at openjdk.org  Tue Oct 25 13:54:54 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:54:54 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v2]
In-Reply-To: <Exa2xjTiGUTAH2K57E4E03UAmmUK4NlBlZHqu6OJeMM=.241f4f05-882c-45d1-92a5-4266e5b6f23b@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <Exa2xjTiGUTAH2K57E4E03UAmmUK4NlBlZHqu6OJeMM=.241f4f05-882c-45d1-92a5-4266e5b6f23b@github.com>
Message-ID: <Ytv1aEPMaznFXlxuXhd9vNXj8bq4uxvRBvFo5VioKoc=.7dbbfc67-e78f-417c-87f2-66b24a215568@github.com>

On Tue, 25 Oct 2022 13:44:09 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)
>> 
>> test case also updated to capture new logic
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - blessed modifiers
>  - Merge branch 'master' into 8292033-x509Event
>  - restore import style
>  - Merge branch 'master' into 8292033-x509Event
>  - Minor clean up
>  - Merge branch 'master' into 8292033-x509Event
>  - update commit method name
>  - Record all X509 generate events
>  - fix up merge
>  - merge with master
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f37a6055...c58e0fa6

test/lib/jdk/test/lib/security/TestCertificate.java line 45:

> 43:     ONE("1000",
> 44:         "CN=SSLCertificate,O=SomeCompany",
> 45:         "CN=Intermediate CA Cert,O=SomeCompany",

Why remove the spaces? `X500Name::toString` always has them.

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From coffeys at openjdk.org  Tue Oct 25 14:32:49 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 25 Oct 2022 14:32:49 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v2]
In-Reply-To: <Ytv1aEPMaznFXlxuXhd9vNXj8bq4uxvRBvFo5VioKoc=.7dbbfc67-e78f-417c-87f2-66b24a215568@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <Exa2xjTiGUTAH2K57E4E03UAmmUK4NlBlZHqu6OJeMM=.241f4f05-882c-45d1-92a5-4266e5b6f23b@github.com>
 <Ytv1aEPMaznFXlxuXhd9vNXj8bq4uxvRBvFo5VioKoc=.7dbbfc67-e78f-417c-87f2-66b24a215568@github.com>
Message-ID: <mekZElXUIVH3tWNyl-gwJj0xDelq1d57ikYYE3F7bcA=.2de748dd-dbea-4a43-80aa-7f4e9a6a72d4@github.com>

On Tue, 25 Oct 2022 13:51:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - blessed modifiers
>>  - Merge branch 'master' into 8292033-x509Event
>>  - restore import style
>>  - Merge branch 'master' into 8292033-x509Event
>>  - Minor clean up
>>  - Merge branch 'master' into 8292033-x509Event
>>  - update commit method name
>>  - Record all X509 generate events
>>  - fix up merge
>>  - merge with master
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f37a6055...c58e0fa6
>
> test/lib/jdk/test/lib/security/TestCertificate.java line 45:
> 
>> 43:     ONE("1000",
>> 44:         "CN=SSLCertificate,O=SomeCompany",
>> 45:         "CN=Intermediate CA Cert,O=SomeCompany",
> 
> Why remove the spaces? `X500Name::toString` always has them.

Code was modified to use the X509Certificate API (rather than X509CertImpl) 

it's using the X500Principal#getName() call now. Would it be better to use X500Principal#toString() ?

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From weijun at openjdk.org  Tue Oct 25 14:36:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 14:36:49 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v2]
In-Reply-To: <mekZElXUIVH3tWNyl-gwJj0xDelq1d57ikYYE3F7bcA=.2de748dd-dbea-4a43-80aa-7f4e9a6a72d4@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <Exa2xjTiGUTAH2K57E4E03UAmmUK4NlBlZHqu6OJeMM=.241f4f05-882c-45d1-92a5-4266e5b6f23b@github.com>
 <Ytv1aEPMaznFXlxuXhd9vNXj8bq4uxvRBvFo5VioKoc=.7dbbfc67-e78f-417c-87f2-66b24a215568@github.com>
 <mekZElXUIVH3tWNyl-gwJj0xDelq1d57ikYYE3F7bcA=.2de748dd-dbea-4a43-80aa-7f4e9a6a72d4@github.com>
Message-ID: <Noaug8bzn3IlY2woCqdAtch7ukmHDg_6jB31CXJsDUo=.b8cc4b9c-b5cd-420b-9dee-d15aa4e02668@github.com>

On Tue, 25 Oct 2022 14:30:32 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> test/lib/jdk/test/lib/security/TestCertificate.java line 45:
>> 
>>> 43:     ONE("1000",
>>> 44:         "CN=SSLCertificate,O=SomeCompany",
>>> 45:         "CN=Intermediate CA Cert,O=SomeCompany",
>> 
>> Why remove the spaces? `X500Name::toString` always has them.
>
> Code was modified to use the X509Certificate API (rather than X509CertImpl) 
> 
> it's using the X500Principal#getName() call now. Would it be better to use X500Principal#toString() ?

If you are only writing there and not parsing the string, then I assume either is OK. Still, less change is better.

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From coffeys at openjdk.org  Tue Oct 25 14:56:15 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 25 Oct 2022 14:56:15 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v3]
In-Reply-To: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
Message-ID: <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>

> By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)
> 
> test case also updated to capture new logic

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Use X500Principal#toString()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10422/files
  - new: https://git.openjdk.org/jdk/pull/10422/files/c58e0fa6..ff67470a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10422&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10422&range=01-02

  Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10422.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10422/head:pull/10422

PR: https://git.openjdk.org/jdk/pull/10422

From coffeys at openjdk.org  Tue Oct 25 14:56:15 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 25 Oct 2022 14:56:15 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v2]
In-Reply-To: <Noaug8bzn3IlY2woCqdAtch7ukmHDg_6jB31CXJsDUo=.b8cc4b9c-b5cd-420b-9dee-d15aa4e02668@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <Exa2xjTiGUTAH2K57E4E03UAmmUK4NlBlZHqu6OJeMM=.241f4f05-882c-45d1-92a5-4266e5b6f23b@github.com>
 <Ytv1aEPMaznFXlxuXhd9vNXj8bq4uxvRBvFo5VioKoc=.7dbbfc67-e78f-417c-87f2-66b24a215568@github.com>
 <mekZElXUIVH3tWNyl-gwJj0xDelq1d57ikYYE3F7bcA=.2de748dd-dbea-4a43-80aa-7f4e9a6a72d4@github.com>
 <Noaug8bzn3IlY2woCqdAtch7ukmHDg_6jB31CXJsDUo=.b8cc4b9c-b5cd-420b-9dee-d15aa4e02668@github.com>
Message-ID: <JQtkBmr8TbaTMKgC1G0oGhHe8-YbvOgV1GqPJNpN8fw=.3fca5056-c330-44d8-86e5-2f62146bd526@github.com>

On Tue, 25 Oct 2022 14:34:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Code was modified to use the X509Certificate API (rather than X509CertImpl) 
>> 
>> it's using the X500Principal#getName() call now. Would it be better to use X500Principal#toString() ?
>
> If you are only writing there and not parsing the string, then I assume either is OK. Still, less change is better.

fair point. I updated patch to use X500Principal#toString()

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From mpowers at openjdk.org  Tue Oct 25 15:57:56 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 25 Oct 2022 15:57:56 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
Message-ID: <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>

> https://bugs.openjdk.org/browse/JDK-8293093

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  add getIDNullSafe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10823/files
  - new: https://git.openjdk.org/jdk/pull/10823/files/25b192ed..43697109

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10823&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10823&range=00-01

  Stats: 17 lines in 1 file changed: 7 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10823.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10823/head:pull/10823

PR: https://git.openjdk.org/jdk/pull/10823

From ascarpino at openjdk.org  Tue Oct 25 17:30:48 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Oct 2022 17:30:48 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
Message-ID: <lhSNqkq9_Pt0kKa1Ia4VRPKThCsRf1tLznVATRp_o10=.7d338820-f62b-4f07-bd7b-63107bceb602@github.com>

On Tue, 25 Oct 2022 15:57:56 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293093
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add getIDNullSafe

looks good

-------------

Marked as reviewed by ascarpino (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10823

From naoto at openjdk.org  Tue Oct 25 17:31:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Oct 2022 17:31:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
Message-ID: <CWhtHdVfwiBt9m16ZvVgfFbu-h9bRwVLYmwORiLTSVA=.210b4cf3-7f67-4f32-9983-b9fe54bd1571@github.com>

On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

Good catch, Max. Yes, that should be dealt with in the translation process.

> I suggest we focus on the English files this time and file a bug to the translation tool.

Agree.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From mpowers at openjdk.org  Tue Oct 25 17:53:52 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 25 Oct 2022 17:53:52 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
Message-ID: <WRASAjnmycNXGiRvxfAY3IOgJoBQ7B_k_b76d6Q1Zhg=.be5948f4-9a7a-4c0b-8b21-fc85ea6c0f34@github.com>

On Tue, 25 Oct 2022 15:57:56 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293093
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add getIDNullSafe

Thanks Tony!

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From xuelei at openjdk.org  Tue Oct 25 17:59:48 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 25 Oct 2022 17:59:48 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <WRASAjnmycNXGiRvxfAY3IOgJoBQ7B_k_b76d6Q1Zhg=.be5948f4-9a7a-4c0b-8b21-fc85ea6c0f34@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
 <WRASAjnmycNXGiRvxfAY3IOgJoBQ7B_k_b76d6Q1Zhg=.be5948f4-9a7a-4c0b-8b21-fc85ea6c0f34@github.com>
Message-ID: <7Ddr0fYEVbp8g1WskyWsjN6YX08hgPEbFsYnPM85KTM=.963d1864-102c-40d0-8e84-a615e5057483@github.com>

On Tue, 25 Oct 2022 17:49:49 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add getIDNullSafe
>
> Thanks Tony!

@mcpowers Did you want to update line line 203-207 as well?  It might be safe to remove the current getID(byte[]) method.  If the parameter is null, there is an NPE (unexpected); otherwise, the new method should be safe to use.

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From mpowers at openjdk.org  Tue Oct 25 18:58:54 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 25 Oct 2022 18:58:54 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <7Ddr0fYEVbp8g1WskyWsjN6YX08hgPEbFsYnPM85KTM=.963d1864-102c-40d0-8e84-a615e5057483@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
 <WRASAjnmycNXGiRvxfAY3IOgJoBQ7B_k_b76d6Q1Zhg=.be5948f4-9a7a-4c0b-8b21-fc85ea6c0f34@github.com>
 <7Ddr0fYEVbp8g1WskyWsjN6YX08hgPEbFsYnPM85KTM=.963d1864-102c-40d0-8e84-a615e5057483@github.com>
Message-ID: <8StjfOnTd9bxSIt7ty0lqjE9pvXvwBrY01XGjDgY-vs=.76b0a3a5-8fb9-42fd-8c6f-0e535197a96d@github.com>

On Tue, 25 Oct 2022 17:56:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Thanks Tony!
>
> @mcpowers Did you want to update line line 203-207 as well?  It might be safe to remove the current getID(byte[]) method.  If the parameter is null, there is an NPE (unexpected); otherwise, the new method should be safe to use.

@XueleiFan Lines 204 and 206 can't be collapsed into a single call to getIDNullSafe because of square brackets in the output on line 204. I don't want to change existing output in any way. Perhaps I'm not understanding your question.

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From xuelei at openjdk.org  Tue Oct 25 19:26:47 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 25 Oct 2022 19:26:47 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
Message-ID: <wfcS1nG_9exbG1Ti7xc3N3fHEKFu0U_FKWLoT26YOBk=.936879f2-f6fa-43e0-8b2f-294a557e7fd4@github.com>

On Tue, 25 Oct 2022 15:57:56 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293093
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add getIDNullSafe

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From xuelei at openjdk.org  Tue Oct 25 19:26:48 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 25 Oct 2022 19:26:48 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <7Ddr0fYEVbp8g1WskyWsjN6YX08hgPEbFsYnPM85KTM=.963d1864-102c-40d0-8e84-a615e5057483@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
 <WRASAjnmycNXGiRvxfAY3IOgJoBQ7B_k_b76d6Q1Zhg=.be5948f4-9a7a-4c0b-8b21-fc85ea6c0f34@github.com>
 <7Ddr0fYEVbp8g1WskyWsjN6YX08hgPEbFsYnPM85KTM=.963d1864-102c-40d0-8e84-a615e5057483@github.com>
Message-ID: <-zl1jvmS-UPIuhV5Fukz8HDWZLs_mhV8ybzD6QPdlYY=.f1a7b799-455d-4cec-a318-30e6dd1a8859@github.com>

On Tue, 25 Oct 2022 17:56:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Thanks Tony!
>
> @mcpowers Did you want to update line line 203-207 as well?  It might be safe to remove the current getID(byte[]) method.  If the parameter is null, there is an NPE (unexpected); otherwise, the new method should be safe to use.

> @XueleiFan Lines 204 and 206 can't be collapsed into a single call to getIDNullSafe because of square brackets in the output on line 204. I don't want to change existing output in any way. Perhaps I'm not understanding your question.

I just feel that it may be not necessary to maintain both getID() and getIDNullSafe().  But no problem if you want to keep the square brackets for toString().

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From mpowers at openjdk.org  Tue Oct 25 19:37:58 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 25 Oct 2022 19:37:58 GMT
Subject: RFR: JDK-8293093 NPE in P11KeyStore.getID [v2]
In-Reply-To: <-zl1jvmS-UPIuhV5Fukz8HDWZLs_mhV8ybzD6QPdlYY=.f1a7b799-455d-4cec-a318-30e6dd1a8859@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
 <5fs5LRyubbDGcZh65MXg6kFabEZn-dAirQ9Wem22WLg=.fa600c56-bb09-4356-bb00-6671dd4551f6@github.com>
 <WRASAjnmycNXGiRvxfAY3IOgJoBQ7B_k_b76d6Q1Zhg=.be5948f4-9a7a-4c0b-8b21-fc85ea6c0f34@github.com>
 <7Ddr0fYEVbp8g1WskyWsjN6YX08hgPEbFsYnPM85KTM=.963d1864-102c-40d0-8e84-a615e5057483@github.com>
 <-zl1jvmS-UPIuhV5Fukz8HDWZLs_mhV8ybzD6QPdlYY=.f1a7b799-455d-4cec-a318-30e6dd1a8859@github.com>
Message-ID: <2882iB7ZxOfZfLKdVabg3IJ-x5YF13c0yXXBVYoGl8s=.85694118-6c6f-4560-afdc-f1880c354378@github.com>

On Tue, 25 Oct 2022 19:23:09 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> @mcpowers Did you want to update line line 203-207 as well?  It might be safe to remove the current getID(byte[]) method.  If the parameter is null, there is an NPE (unexpected); otherwise, the new method should be safe to use.
>
>> @XueleiFan Lines 204 and 206 can't be collapsed into a single call to getIDNullSafe because of square brackets in the output on line 204. I don't want to change existing output in any way. Perhaps I'm not understanding your question.
> 
> I just feel that it may be not necessary to maintain both getID() and getIDNullSafe().  But no problem if you want to keep the square brackets for toString().

@XueleiFan Thanks for reviewing this!

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From sean.mullan at oracle.com  Tue Oct 25 19:55:11 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 25 Oct 2022 15:55:11 -0400
Subject: Request - Preparation for removal of SecurityManager
In-Reply-To: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>
References: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>
Message-ID: <7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com>

When support for the Security Manager is removed, there would be little 
benefit to keeping the permission checks inside the JDK, since it would 
no longer be possible to set a Security Manager. Also, many APIs that 
perform permission checks will likely be modified to no longer throw 
SecurityException.

--Sean

On 10/25/22 2:25 AM, Peter Firmstone wrote:
> Would the OpenJDK team consider the following?
> 
> Where SecurityManager is invoked directly now, such as:
> 
> 
>   ??????? @SuppressWarnings("removal")
>   ??????? SecurityManager sm = System.getSecurityManager();
>   ??????? if (sm != null)
>   ??????????? sm.checkPermission(new RuntimePermission("setFactory"));
> 
> Can we change these routines to the simpler form:
> 
>   ??? ??? newRuntimePermission("setFactory").checkGuard(null);
> 
> This will give us more time to transition to a replacement authorization
> layer.
> 
> We can instrument the Permission#checkGuard method, this will assist us
> to utilise existing Permission check hooks after SecurityManager is
> removed.??? Longer term we will need to maintain our own instrumentation
> hooks, but this will go a long way towards giving us a head start, by
> leveraging the existing.
> 

From mullan at openjdk.org  Tue Oct 25 20:13:40 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Oct 2022 20:13:40 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v3]
In-Reply-To: <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
Message-ID: <L5o_zL_VLDqOrERDSIQhUHrgscurPw1E2KBh5yabG2c=.5452a36c-3145-4641-9808-cdc5bb446320@github.com>

On Tue, 25 Oct 2022 14:56:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)
>> 
>> test case also updated to capture new logic
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use X500Principal#toString()

I think this will miss cases where the certificates are part of a chain, and the application (or JDK code) is calling `CertificateFactory.generateCertPath` or `generateCertificates`, whereas the previous code would not have missed it (if not using a 3rd-party provider) as it was firing the event at a lower layer in the provider code.

I think this is fixable though. In these methods, you can iterate over the certificates that are in the `Collection` or `CertPath` and log an event for each.

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From mullan at openjdk.org  Tue Oct 25 20:27:06 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Oct 2022 20:27:06 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v3]
In-Reply-To: <L5o_zL_VLDqOrERDSIQhUHrgscurPw1E2KBh5yabG2c=.5452a36c-3145-4641-9808-cdc5bb446320@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
 <L5o_zL_VLDqOrERDSIQhUHrgscurPw1E2KBh5yabG2c=.5452a36c-3145-4641-9808-cdc5bb446320@github.com>
Message-ID: <k91z2ioQx0LkkYUtbZvcybAoW5JTi6yG3DOqS9mGN9I=.da73ba93-ef15-41df-a9d5-892a80d17565@github.com>

On Tue, 25 Oct 2022 20:11:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I think this will miss cases where the certificates are part of a chain, and the application (or JDK code) is calling `CertificateFactory.generateCertPath` or `generateCertificates`, whereas the previous code would not have missed it (if not using a 3rd-party provider) as it was firing the event at a lower layer in the provider code.

Actually, I think the previous code missed these cases as well. But I think it is important to try to fix this. If not as part of this issue, then a separate issue. It is just for the cases where the above methods take an `InputStream`.

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From jnimeh at openjdk.org  Tue Oct 25 22:09:49 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 25 Oct 2022 22:09:49 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
Message-ID: <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>

On Mon, 24 Oct 2022 22:09:29 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra whitespace character

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 171:

> 169:         }
> 170: 
> 171:         if (len >= 1024) {

Out of curiosity, do you have any perf numbers for the impact of this change on systems that do not support AVX512?  Does this help or hurt (or make a negligible impact) on poly1305 updates when the input is 1K or larger?

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 296:

> 294:         keyBytes[12] &= (byte)252;
> 295: 
> 296:         // This should be enabled, but Poly1305KAT would fail

I'm on the fence about this change.  I have no problem with it in basic terms.  If we ever decided to make this a general purpose Mac in JCE then this would definitely be good to do.  As of right now, the only consumer is ChaCha20 and it would submit a key through the process in the RFC.  Seems really unlikely to run afoul of these checks, but admittedly not impossible.

I would agree with @sviswa7 that we could examine this in a separate change and we could look at other approaches to getting around the KAT issue, perhaps some package-private based way to disable the check.  As long as Poly1305 remains with package-private visibility, one could make another form of the constructor with a boolean that would disable this check and that is the constructor that the KAT would use.  This is just an off-the-cuff idea, but one way we might get the best of both worlds.

If we move this down the road then we should remove the commenting.  We can refer back to this PR later.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From sviswanathan at openjdk.org  Tue Oct 25 23:52:26 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 25 Oct 2022 23:52:26 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
Message-ID: <K1uON7wj2Hf6mMIWYPfAIUiUieiJ3AOPD6xE3rnHlT0=.45d87614-875f-4ba0-9e03-2a0b94ae17f5@github.com>

On Mon, 24 Oct 2022 22:09:29 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra whitespace character

src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 806:

> 804:   evmovdquq(A0, Address(rsp, 64*0), Assembler::AVX_512bit);
> 805:   evmovdquq(A0, Address(rsp, 64*1), Assembler::AVX_512bit);
> 806:   evmovdquq(A0, Address(rsp, 64*2), Assembler::AVX_512bit);

This is load from stack into A0. Did you intend to store A0 (cleanup) into stack local area here? I think the source and destination are mixed up here.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From peter.firmstone at zeus.net.au  Wed Oct 26 00:58:25 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 26 Oct 2022 10:58:25 +1000
Subject: Request - Preparation for removal of SecurityManager
In-Reply-To: <7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com>
References: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>
 <7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com>
Message-ID: <5fe809c0-ce74-4ea3-cfb5-f18524506f76@zeus.net.au>

Hi Sean,

I would be quite willing to undertake the work.

We have a decision to make based on when & how SM will be removed, for 
obvious reasons, this decision will be delayed as long as possible:

 1. Pull the plug on our existing Java software development efforts,
    currently our software depends on SM for authorization decisions and
    authentication of our secure endpoints.? Our software is built on SM
    and would require a complete architecture redesign, and we simply
    don't have the resources to replace decades of development effort.
 2. Implement a new authorization layer to replace SM functionality.

#2 is our preferred option.

We need to replace permission check hooks in the JDK by instrumenting 
it, as per OpenJDK advise.? I had identified that this wasn't possible 
to do so securely with finalizer's enabled, from JDK18 on we can disable 
finalizers, so it enables us to commence development. ? OpenJDK has 
advised that all functionality of SM may be implemented independently by 
application developers and run on top of JDK.

Basically I'm requesting controlled dismantling of SecurityManager, as 
opposed to sudden destruction, to allow us time to develop and implement 
our migration strategy.

Using the existing permission check hooks in the JDK allows us to 
significantly speed up our development efforts.?? Each time a permission 
check hook is removed, we will need to replace it with 
instrumentation.?? I was hoping this could be done in a controlled manner.

The first step would be to instrument Permission#checkPermission, as 
this provides access to all the existing hooks within the JDK.

The API's changed to not throw SecurityException won't break backward 
compatibility and won't impact us.

We haven't yet tested how our software will behave without the 
PrivilegedAction's in JDK code, or preservation of AccessControlContext 
in executor threads etc, but we need to start exploring that to fully 
understand it before the SM removal JEP is created.

-- 
Regards,
  
Peter Firmstone


On 26/10/2022 5:55 am, Sean Mullan wrote:
> When support for the Security Manager is removed, there would be 
> little benefit to keeping the permission checks inside the JDK, since 
> it would no longer be possible to set a Security Manager. Also, many 
> APIs that perform permission checks will likely be modified to no 
> longer throw SecurityException.
>
> --Sean
>
> On 10/25/22 2:25 AM, Peter Firmstone wrote:
>> Would the OpenJDK team consider the following?
>>
>> Where SecurityManager is invoked directly now, such as:
>>
>>
>> ? ??????? @SuppressWarnings("removal")
>> ? ??????? SecurityManager sm = System.getSecurityManager();
>> ? ??????? if (sm != null)
>> ? ??????????? sm.checkPermission(new RuntimePermission("setFactory"));
>>
>> Can we change these routines to the simpler form:
>>
>> ? ??? ??? newRuntimePermission("setFactory").checkGuard(null);
>>
>> This will give us more time to transition to a replacement authorization
>> layer.
>>
>> We can instrument the Permission#checkGuard method, this will assist us
>> to utilise existing Permission check hooks after SecurityManager is
>> removed.??? Longer term we will need to maintain our own instrumentation
>> hooks, but this will go a long way towards giving us a head start, by
>> leveraging the existing.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221026/e510bc5c/attachment.htm>

From Alan.Bateman at oracle.com  Wed Oct 26 06:24:49 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Oct 2022 07:24:49 +0100
Subject: Request - Preparation for removal of SecurityManager
In-Reply-To: <5fe809c0-ce74-4ea3-cfb5-f18524506f76@zeus.net.au>
References: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>
 <7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com>
 <5fe809c0-ce74-4ea3-cfb5-f18524506f76@zeus.net.au>
Message-ID: <a68be7f4-51f5-fcfd-9360-eae1cf1c7524@oracle.com>

On 26/10/2022 02:58, Peter Firmstone wrote:
> :
>
> Using the existing permission check hooks in the JDK allows us to 
> significantly speed up our development efforts.?? Each time a 
> permission check hook is removed, we will need to replace it with 
> instrumentation.?? I was hoping this could be done in a controlled manner.
>
The permission checks in the JDK might give you a baseline for what you 
want to do right now but once the ability the set a SM goes away then 
you have to assume those permission checks will rapidly bit rot and be 
removed. The JDK code is constantly changing and features are added in 
most releases. Most new features would have historically interacted with 
the SM in some way. So trying to instrument everywhere where a 
permission check might live will be a lot of work. It will mean keeping 
up with all code changes and all new features, it will give you a 
sensitive of the effort to keep the SM execution mode working security 
today.

-Alan

From peter.firmstone at zeus.net.au  Wed Oct 26 07:02:12 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 26 Oct 2022 17:02:12 +1000
Subject: Request - Preparation for removal of SecurityManager
In-Reply-To: <a68be7f4-51f5-fcfd-9360-eae1cf1c7524@oracle.com>
References: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>
 <7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com>
 <5fe809c0-ce74-4ea3-cfb5-f18524506f76@zeus.net.au>
 <a68be7f4-51f5-fcfd-9360-eae1cf1c7524@oracle.com>
Message-ID: <1fbcb952-a2e7-2a23-1c77-9f98133ffbf9@zeus.net.au>

Thanks Alan,

That's correct, however some parts will bit rot faster than others, 
historically some parts of the JDK are very slow to change, unless 
someone comes through deliberately removing them, which I would hope 
not, but I realise that new methods and classes might open new code 
paths that don't invoke them.

It's an additional layer of indirection that buys us some time.

What would make a significant difference is returning non null 
ProtectionDomain's for JDK modules, so we can reduce the size of the 
trusted computing base, to make our job smaller, hopefully that will 
allow focusing on placing authorization checks on the low level access 
to file systems and networks, which are our main concerns.

Basically if all our hooks are in a small number of trusted computing 
base modules, then we can authorize access for other modules, as needed, 
but no more than required, hopefully without needing to maintain hooks 
for the entire JDK codebase.

Examples for JDK modules which have non-null ProtectionDomain's:

Do you think that tighter module boundaries will negate the need for 
RuntimePermission accessClassInPackage.* below?

grant codebase "jrt:/jdk.crypto.ec"
{
 ??? permission java.security.SecurityPermission 
"putProviderProperty.SunEC";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.jca";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.pkcs";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math.intpoly";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.x509";
};

grant codebase "jrt:/java.xml.crypto"
{
 ??? permission java.security.SecurityPermission 
"putProviderProperty.XMLDSig";
 ??? permission java.util.PropertyPermission 
"java.specification.version", "read";
};

grant codebase "jrt:/jdk.security.jgss"
{
 ??? permission java.security.SecurityPermission 
"putProviderProperty.JdkSASL";
 ??? permission java.security.SecurityPermission 
"putProviderProperty.SunJGSS";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
};


grant codebase "jrt:/jdk.security.auth"
{
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.krb5";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
 ??? permission java.lang.RuntimePermission "getProtectionDomain";
 ??? permission java.io.FilePermission 
"${qa.home}${/}lib${/}jiniharness.jar", "read";
 ??? permission javax.security.auth.AuthPermission "modifyPrincipals";
 ??? permission javax.security.auth.AuthPermission 
"modifyPrivateCredentials";
 ??? permission javax.security.auth.AuthPermission 
"modifyPublicCredentials";
};

Regards,

Peter.

On 26/10/2022 4:24 pm, Alan Bateman wrote:
> On 26/10/2022 02:58, Peter Firmstone wrote:
>> :
>>
>> Using the existing permission check hooks in the JDK allows us to 
>> significantly speed up our development efforts.?? Each time a 
>> permission check hook is removed, we will need to replace it with 
>> instrumentation.?? I was hoping this could be done in a controlled 
>> manner.
>>
> The permission checks in the JDK might give you a baseline for what 
> you want to do right now but once the ability the set a SM goes away 
> then you have to assume those permission checks will rapidly bit rot 
> and be removed. The JDK code is constantly changing and features are 
> added in most releases. Most new features would have historically 
> interacted with the SM in some way. So trying to instrument everywhere 
> where a permission check might live will be a lot of work. It will 
> mean keeping up with all code changes and all new features, it will 
> give you a sensitive of the effort to keep the SM execution mode 
> working security today.
>
> -Alan


From Alan.Bateman at oracle.com  Wed Oct 26 13:07:16 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Oct 2022 14:07:16 +0100
Subject: Request - Preparation for removal of SecurityManager
In-Reply-To: <1fbcb952-a2e7-2a23-1c77-9f98133ffbf9@zeus.net.au>
References: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>
 <7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com>
 <5fe809c0-ce74-4ea3-cfb5-f18524506f76@zeus.net.au>
 <a68be7f4-51f5-fcfd-9360-eae1cf1c7524@oracle.com>
 <1fbcb952-a2e7-2a23-1c77-9f98133ffbf9@zeus.net.au>
Message-ID: <2eae2f6b-0e82-a357-0cb0-857b2f13845f@oracle.com>



On 26/10/2022 09:02, Peter Firmstone wrote:
> :
>
> That's correct, however some parts will bit rot faster than others, 
> historically some parts of the JDK are very slow to change, unless 
> someone comes through deliberately removing them, which I would hope 
> not, but I realise that new methods and classes might open new code 
> paths that don't invoke them.

It's too early to say whether permission checks will be removed in a 
single releases or staggered or several releases but I wouldn't expect 
dead code to hang around for too long.

> :
>
> What would make a significant difference is returning non null 
> ProtectionDomain's for JDK modules, so we can reduce the size of the 
> trusted computing base, to make our job smaller, hopefully that will 
> allow focusing on placing authorization checks on the low level access 
> to file systems and networks, which are our main concerns.
The PD should not be null, maybe you mean the CodeSource? I think we 
exchanged mail about this before and it might be generally useful to 
have that. It would mean working through some issues related to patching.


> :
>
> Do you think that tighter module boundaries will negate the need for 
> RuntimePermission accessClassInPackage.* below?
This is only needed when running with a SM.

-Alan

From mdoerr at openjdk.org  Wed Oct 26 14:24:29 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 26 Oct 2022 14:24:29 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
Message-ID: <fY-Sd5Dr02MYyZ3HaihTUXvVyiHsUB0wpvqwWmKd49A=.c70450f8-03dc-449b-932e-fb58567a04c1@github.com>

On Tue, 18 Oct 2022 14:55:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
>> 
>> https://bugs.openjdk.org/browse/JDK-8295343
>> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
>> 
>> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More causes

Change looks good. Does it need a CSR?

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10726

From mbaesken at openjdk.org  Wed Oct 26 14:35:38 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Oct 2022 14:35:38 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <fY-Sd5Dr02MYyZ3HaihTUXvVyiHsUB0wpvqwWmKd49A=.c70450f8-03dc-449b-932e-fb58567a04c1@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
 <fY-Sd5Dr02MYyZ3HaihTUXvVyiHsUB0wpvqwWmKd49A=.c70450f8-03dc-449b-932e-fb58567a04c1@github.com>
Message-ID: <J2vpPxehluL2lHJePd3VElIwhzwSo_7LNG1JfFo4LW0=.8e228d78-8b31-48e2-819f-e37be0c4161c@github.com>

On Wed, 26 Oct 2022 14:22:08 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Change looks good. Does it need a CSR?

Hi Martin , from what I read here  https://wiki.openjdk.org/display/csr/CSR+FAQs  no CSR is needed.  But I am no expert on the topic so maybe someone else has an opinion on this ?

While looking at this change, I considered adding a  constructor (String,Throwable) to InvalidAlgorithmParameterException and use it in security coding to simplify coding, but I did not do this in this change; I think adding   a  constructor (String,Throwable) to InvalidAlgorithmParameterException  would indeed  need a CSR .

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From ckozak at ckozak.net  Wed Oct 26 15:01:13 2022
From: ckozak at ckozak.net (Carter Kozak)
Date: Wed, 26 Oct 2022 11:01:13 -0400
Subject: Clogged pipes: 50x throughput degradation with large Cipher writes
Message-ID: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>

Continuing a conversation I had with Sean Mullan at Java One, for a broader audience.

We tend to believe that bulk operations are good. Large bulk operations give the system the most information at once, allowing it to make more informed decisions. Understanding the hotspot compiler on some level and how the security components interact with it, the observed performance degradation makes sense as a result, but I don?t think it?s obvious or desirable most of those using the JDK. As the industry shifts toward shorter lived and horizontally scalable instances, it becomes more important than ever to deliver cryptography performance consistently and early.

Encryption in Java is usually fast, around 2-3 GiB/second per core using the default OpenJDK JSSE provider on my test system. However, when developers use larger buffers (~10 MiB, perhaps large for networking/TLS, but reasonable for local data), I can observe throughput drop to 60 MiB/second (between 2 and 3 percent of the expected throughput!).

Results from https://github.com/carterkozak/java-crypto-buffer-performance:
Benchmark                             (cipher)  (numBytes)  (writeStrategy)   Mode  Cnt     Score     Error  Units
EncryptionBenchmark.encrypt  AES/GCM/NoPadding     1048576    ENTIRE_BUFFER  thrpt    4  2215.898 ? 185.661  ops/s
EncryptionBenchmark.encrypt  AES/GCM/NoPadding    10485760    ENTIRE_BUFFER  thrpt    4     6.427 ?   0.475  ops/s
EncryptionBenchmark.encrypt  AES/GCM/NoPadding   104857600    ENTIRE_BUFFER  thrpt    4     0.620 ?   0.096  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding     1048576    ENTIRE_BUFFER  thrpt    4  2933.808 ?  17.538  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding    10485760    ENTIRE_BUFFER  thrpt    4    31.775 ?   1.898  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding   104857600    ENTIRE_BUFFER  thrpt    4     3.174 ?   0.171  ops/s

Using `AES/GCM/NoPadding`, large buffers result in a great deal of work within GHASH.processBlocks <https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/java.base/share/classes/com/sun/crypto/provider/GHASH.java#L272-L286> which is intrinsified <https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/hotspot/share/classfile/vmIntrinsics.hpp#L462-L466>, however the intrinsic isn?t used because the method is called infrequently, and a tremendous amount of work occurs within the default implementation. You can find notes from my initial investigation are here (with flame graphs) <https://github.com/palantir/hadoop-crypto/pull/586#issuecomment-964394587>. When I introduce a wrapper to chunk input buffers into 16 KiB segments (other sizes tested here <https://github.com/palantir/hadoop-crypto/pull/586#issue-1047810949>), we can effectively force the method to warm up, and perform nearly two orders of magnitude better:

https://github.com/carterkozak/java-crypto-buffer-performance#jdk-17
Benchmark                             (cipher)  (numBytes)  (writeStrategy)   Mode  Cnt     Score     Error  Units
EncryptionBenchmark.encrypt  AES/GCM/NoPadding     1048576    ENTIRE_BUFFER  thrpt    4  2215.898 ? 185.661  ops/s
EncryptionBenchmark.encrypt  AES/GCM/NoPadding     1048576          CHUNKED  thrpt    4  2516.770 ? 193.009  ops/s
EncryptionBenchmark.encrypt  AES/GCM/NoPadding    10485760    ENTIRE_BUFFER  thrpt    4     6.427 ?   0.475  ops/s
EncryptionBenchmark.encrypt  AES/GCM/NoPadding    10485760          CHUNKED  thrpt    4   246.956 ?  51.193  ops/s
EncryptionBenchmark.encrypt  AES/GCM/NoPadding   104857600    ENTIRE_BUFFER  thrpt    4     0.620 ?   0.096  ops/s
EncryptionBenchmark.encrypt  AES/GCM/NoPadding   104857600          CHUNKED  thrpt    4    24.633 ?   2.784  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding     1048576    ENTIRE_BUFFER  thrpt    4  2933.808 ?  17.538  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding     1048576          CHUNKED  thrpt    4  3277.374 ? 569.573  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding    10485760    ENTIRE_BUFFER  thrpt    4    31.775 ?   1.898  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding    10485760          CHUNKED  thrpt    4   332.873 ?  55.589  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding   104857600    ENTIRE_BUFFER  thrpt    4     3.174 ?   0.171  ops/s
EncryptionBenchmark.encrypt  AES/CTR/NoPadding   104857600          CHUNKED  thrpt    4    33.909 ?   1.675  ops/s

The 10 MiB full-buffer benchmark is eventually partially optimized after ~3 minutes of encryption on ~10 GiB of data, however in practice this takes much longer because the encrypted data must also be put somewhere, potentially leading to rubber-banding over a network.

While writing this up I re-ran my investigation using JDK-19 <https://github.com/carterkozak/java-crypto-buffer-performance#jdk-19> and found, to my surprise, that AES/GCM performed substantially better, warming up quickly, while AES/CTR performance was largely equivalent! It turns out that JDK-8273297 <https://bugs.openjdk.org/browse/JDK-8273297>, which aimed to improve performance of an intrinsic, has the side-effect of allowing the intrinsic to be used much faster by segmenting inputs to 1mb chunks <https://github.com/openjdk/jdk/commit/13e9ea9e922030927775345b1abde1313a6ec03f#diff-a533e78f757a3ad64a8d2453bea64a0d426890ef85031452bf74070776ad8be0R575-R596>.

I?ve intentionally avoided suggesting specific solutions, as a layperson I don?t feel confident making explicit recommendations, but my goal is reliably high throughput based on the amount of work done rather than the size of individual operations. As a user, native implementations like tcnative <https://tomcat.apache.org/native-doc/> and Conscrypt <https://github.com/google/conscrypt> provide the performance characteristics I?m looking for, but without the reliability or flexibility of OpenJDK JSSE. Is there a solution which allows us to get the best of both worlds?

Thanks,
Carter Kozak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221026/e2459f98/attachment-0001.htm>

From mullan at openjdk.org  Wed Oct 26 15:22:27 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Oct 2022 15:22:27 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <J2vpPxehluL2lHJePd3VElIwhzwSo_7LNG1JfFo4LW0=.8e228d78-8b31-48e2-819f-e37be0c4161c@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
 <fY-Sd5Dr02MYyZ3HaihTUXvVyiHsUB0wpvqwWmKd49A=.c70450f8-03dc-449b-932e-fb58567a04c1@github.com>
 <J2vpPxehluL2lHJePd3VElIwhzwSo_7LNG1JfFo4LW0=.8e228d78-8b31-48e2-819f-e37be0c4161c@github.com>
Message-ID: <Zl4GY2OsoxhAu6TQJRHJRQzUaz807qCWkN66HJXXuxY=.f3d327a7-f508-4c93-b1da-924f52662c1a@github.com>

You are currently receiving this informational message with the original email attached. We need your help in notifying the team or sender responsible for this mail flow to ensure future email is delivered properly.

The host that sent this message is not compliant with Oracle's email security policy (DMARC). Please notify the person(s) responsible for this message and share the content below so they can take actions to resolve their issue.

If you have no idea who is responsible, then please address the #ww-oracle-dmarc slack channel for assistance.

Deadlines
	? We plan to move to quarantine non-compliant messages on October 26th (delayed due to change freeze).  After this date, if the issues are not fixed, messages will be held in a folder on our email gateway and will not be delivered to you.
	? We will then move to reject on November 22nd.  After this date, messages will be rejected.

For more technical resources and information, see:
https://confluence.oci.oraclecorp.com/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions
https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ

Thank you in advance for your attention to this matter.

----------------------------------------------------------------------
On Wed, 26 Oct 2022 14:33:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Change looks good. Does it need a CSR?
> 
> Hi Martin , from what I read here https://wiki.openjdk.org/display/csr/CSR+FAQs no CSR is needed. But I am no expert on the topic so maybe someone else has an opinion on this ?

It does not require a CSR.

> While looking at this change, I considered adding a constructor (String,Throwable) to InvalidAlgorithmParameterException and use it in security coding to simplify coding, but I did not do this in this change; I think adding a constructor (String,Throwable) to InvalidAlgorithmParameterException would indeed need a CSR .

I think you mean `InvalidParameterException`. `InvalidAlgorithmParameterException` has a ctor that takes a cause. Can you file an RFE?

Note: I don't know if there is much benefit to specifying the exception message as the first argument, but I'm ok with leaving this as is if you want to avoid too many changes. For example:

`throw new IllegalArgumentException(e.getMessage(), e)`

Maybe we should just change these to:

`throw new IllegalArgumentException(e)`

I think the main benefit is that you get a localized message, if applicable.

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From mullan at openjdk.org  Wed Oct 26 15:22:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Oct 2022 15:22:29 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
Message-ID: <OdTi50MHNvfkE-JZ8XqTRCFJbKM1cHI62aTYIQNznjQ=.a8d409f9-a3ca-4936-bea8-f8cf258a182a@github.com>

You are currently receiving this informational message with the original email attached. We need your help in notifying the team or sender responsible for this mail flow to ensure future email is delivered properly.

The host that sent this message is not compliant with Oracle's email security policy (DMARC). Please notify the person(s) responsible for this message and share the content below so they can take actions to resolve their issue.

If you have no idea who is responsible, then please address the #ww-oracle-dmarc slack channel for assistance.

Deadlines
	? We plan to move to quarantine non-compliant messages on October 26th (delayed due to change freeze).  After this date, if the issues are not fixed, messages will be held in a folder on our email gateway and will not be delivered to you.
	? We will then move to reject on November 22nd.  After this date, messages will be rejected.

For more technical resources and information, see:
https://confluence.oci.oraclecorp.com/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions
https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ

Thank you in advance for your attention to this matter.

----------------------------------------------------------------------
On Tue, 18 Oct 2022 14:55:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
>> 
>> https://bugs.openjdk.org/browse/JDK-8295343
>> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
>> 
>> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More causes

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 156:

> 154:             InvalidParameterException ipe = new InvalidParameterException(e.getMessage());
> 155:             ipe.initCause(e);
> 156:             throw ipe;

Or I think this could be written more simply as:

`throw new InvalidParameterException(e.getMessage()).initCause(e);`

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From mullan at openjdk.org  Wed Oct 26 15:25:19 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Oct 2022 15:25:19 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
Message-ID: <Q3nE8fY3w2Z89ijDWj8uSFBj6kOcReEy9PMK7E16UdI=.da4d35e0-d4ce-4372-8fdd-56a1f96a76ba@github.com>

You are currently receiving this informational message with the original email attached. We need your help in notifying the team or sender responsible for this mail flow to ensure future email is delivered properly.

The host that sent this message is not compliant with Oracle's email security policy (DMARC). Please notify the person(s) responsible for this message and share the content below so they can take actions to resolve their issue.

If you have no idea who is responsible, then please address the #ww-oracle-dmarc slack channel for assistance.

Deadlines
	? We plan to move to quarantine non-compliant messages on October 26th (delayed due to change freeze).  After this date, if the issues are not fixed, messages will be held in a folder on our email gateway and will not be delivered to you.
	? We will then move to reject on November 22nd.  After this date, messages will be rejected.

For more technical resources and information, see:
https://confluence.oci.oraclecorp.com/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions
https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ

Thank you in advance for your attention to this matter.

----------------------------------------------------------------------
On Tue, 18 Oct 2022 14:55:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
>> 
>> https://bugs.openjdk.org/browse/JDK-8295343
>> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
>> 
>> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More causes

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java line 212:

> 210:         } catch (NullPointerException npe) {
> 211:             throw new SignatureException("Unsupported digest: " +
> 212:                     digestAlg, npe);

I don't think the `NullPointerException` adds any value here. I would leave that out.

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From duke at openjdk.org  Wed Oct 26 15:30:23 2022
From: duke at openjdk.org (vpaprotsk)
Date: Wed, 26 Oct 2022 15:30:23 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
Message-ID: <ciNkfW7vps_NlMo48k2iiEF-n3eODjTkMXBnh5E6UOs=.d01b33ec-3807-4738-a155-4d8dad3bd67a@github.com>

On Tue, 25 Oct 2022 21:57:34 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extra whitespace character
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 296:
> 
>> 294:         keyBytes[12] &= (byte)252;
>> 295: 
>> 296:         // This should be enabled, but Poly1305KAT would fail
> 
> I'm on the fence about this change.  I have no problem with it in basic terms.  If we ever decided to make this a general purpose Mac in JCE then this would definitely be good to do.  As of right now, the only consumer is ChaCha20 and it would submit a key through the process in the RFC.  Seems really unlikely to run afoul of these checks, but admittedly not impossible.
> 
> I would agree with @sviswa7 that we could examine this in a separate change and we could look at other approaches to getting around the KAT issue, perhaps some package-private based way to disable the check.  As long as Poly1305 remains with package-private visibility, one could make another form of the constructor with a boolean that would disable this check and that is the constructor that the KAT would use.  This is just an off-the-cuff idea, but one way we might get the best of both worlds.
> 
> If we move this down the road then we should remove the commenting.  We can refer back to this PR later.

I think I will remove the check for now, dont want to hold up reviews. I wasn't sure how to 'inject a backdoor' to the commented out check either, or at least how to do it in an acceptable way. Your ideas do sound plausible, and if anyone does want this check, I can implement one of the ideas (package private boolean flag? turn it on in the test) while waiting for more reviews to come in.

The comment about ChaCha being the only way in is also relevant, thanks. i.e. this is a private class today.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Wed Oct 26 15:51:22 2022
From: duke at openjdk.org (vpaprotsk)
Date: Wed, 26 Oct 2022 15:51:22 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <K1uON7wj2Hf6mMIWYPfAIUiUieiJ3AOPD6xE3rnHlT0=.45d87614-875f-4ba0-9e03-2a0b94ae17f5@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <K1uON7wj2Hf6mMIWYPfAIUiUieiJ3AOPD6xE3rnHlT0=.45d87614-875f-4ba0-9e03-2a0b94ae17f5@github.com>
Message-ID: <4FY4SEodgFcdxFXvGWFJWHYCr1GD4nAktLa5SiyPcxM=.384b2818-b6c5-4523-8682-5b730d9ad036@github.com>

On Tue, 25 Oct 2022 23:48:49 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extra whitespace character
>
> src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 806:
> 
>> 804:   evmovdquq(A0, Address(rsp, 64*0), Assembler::AVX_512bit);
>> 805:   evmovdquq(A0, Address(rsp, 64*1), Assembler::AVX_512bit);
>> 806:   evmovdquq(A0, Address(rsp, 64*2), Assembler::AVX_512bit);
> 
> This is load from stack into A0. Did you intend to store A0 (cleanup) into stack local area here? I think the source and destination are mixed up here.

Wow! Thank you for spotting this

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Wed Oct 26 15:51:23 2022
From: duke at openjdk.org (vpaprotsk)
Date: Wed, 26 Oct 2022 15:51:23 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
Message-ID: <KwT1ejhy7yvVIpMPCpkT2E87-bwwXRvVhZ-fy_Bm8po=.d71506cf-3e0c-4eb8-a008-390ab2ff4e02@github.com>

On Tue, 25 Oct 2022 21:48:47 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extra whitespace character
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 171:
> 
>> 169:         }
>> 170: 
>> 171:         if (len >= 1024) {
> 
> Out of curiosity, do you have any perf numbers for the impact of this change on systems that do not support AVX512?  Does this help or hurt (or make a negligible impact) on poly1305 updates when the input is 1K or larger?

(The first commit in this PR actually has the code without the check if anyone wants to measure.. well its also trivial to edit..)

I measured about 50% slowdown on 64 byte payloads. One could argue that 64 bytes is not all that representative, but we don't get much out of assembler at that load either so it didn't seem worth it to figure out some sort of platform check. 

AVX512 needs at least 256 = 16 blocks.. there is overhead also pre-calculating powers of R that needs to be amortized. Assembler does fall back to 64-bit multiplies for <256, while the Java version will have to use the 32-bit multiplies. <256, purely scalar, non-vector, 64 vs 32 is not _that_ big an issue though; the algorithm is plenty happy with 26-bit limbs, and whatever the benefit of 64, it gets erased by the interface-matching code copying limbs in and out..

Right now, I measured 1k with `-XX:-UsePolyIntrinsics` to be about 10% slower. I think its acceptable, in order to get 18x?

Most/all of the slowdown comes from this need of copying limbs out/in.. I am looking at perhaps copying limbs out in the intrinsic instead. Not very 'pretty'.. limbs are hidden in a nested private class behind an interface.. I would be breaking what is a good design with neat encapsulation. (I accidentally forced-pushed that earlier, if you are curious; non-working). The current version of this code seems more robust in the long term?

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From mpowers at openjdk.org  Wed Oct 26 15:56:30 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 26 Oct 2022 15:56:30 GMT
Subject: Integrated: JDK-8293093 NPE in P11KeyStore.getID
In-Reply-To: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
References: <Ac_-BLNEzWVPQMEUn9b9bNHUxedkegSKq5S_0ogbsaA=.e9d65d6d-842f-4b49-a019-a5e70ae94b90@github.com>
Message-ID: <Kc7Jp--Bg3cfiPE6Go1EeRC4gMRclUKNltX_n_wb2Fk=.9af6f536-1e97-4cd8-9e1f-15e08375b4a5@github.com>

On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293093

This pull request has now been integrated.

Changeset: 8e5d680a
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e5d680a98ad28eb3607d227783bdea94039dde6
Stats:     18 lines in 1 file changed: 7 ins; 0 del; 11 mod

8293093: NPE in P11KeyStore.getID

Reviewed-by: ascarpino, xuelei

-------------

PR: https://git.openjdk.org/jdk/pull/10823

From dfuchs at openjdk.org  Wed Oct 26 16:11:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 16:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
Message-ID: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>

Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.

The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 

This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.

In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.

In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.

Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.

The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

-------------

Commit messages:
 - Fix whitespace issues
 - 8294241

Changes: https://git.openjdk.org/jdk/pull/10874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294241
  Stats: 849 lines in 82 files changed: 701 ins; 2 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

PR: https://git.openjdk.org/jdk/pull/10874

From michaelm at openjdk.org  Wed Oct 26 16:45:22 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 26 Oct 2022 16:45:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/JarURLConnection.java line 177:

> 175:         @SuppressWarnings("deprecation")
> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
> 177: 

I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From weijun at openjdk.org  Wed Oct 26 16:48:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Oct 2022 16:48:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <6CBNoueQtp5P8wa0FuOCHQtmw9610BdOrP7pvhg1g70=.6cc91f26-df33-4722-9c49-f390ed6387aa@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

The change to security-related code looks fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From aturbanov at openjdk.org  Wed Oct 26 17:00:03 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 26 Oct 2022 17:00:03 GMT
Subject: RFR: 8295953: Use enhanced-for cycle instead of Enumeration in
 sun.security
Message-ID: <N-bQ5FdBX42mOCwt9TikxXOO25NsrgwuMiHDCpa5eyg=.ca9865ca-467a-433d-9e70-0b376df2b15b@github.com>

java.util.Enumeration is a legacy interface from java 1.0.
There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

-------------

Commit messages:
 - [PATCH] Use enhanced-for cycle instead of Enumeration in sun.security

Changes: https://git.openjdk.org/jdk/pull/10734/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10734&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295953
  Stats: 32 lines in 6 files changed: 0 ins; 18 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10734.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10734/head:pull/10734

PR: https://git.openjdk.org/jdk/pull/10734

From weijun at openjdk.org  Wed Oct 26 17:00:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Oct 2022 17:00:05 GMT
Subject: RFR: 8295953: Use enhanced-for cycle instead of Enumeration in
 sun.security
In-Reply-To: <N-bQ5FdBX42mOCwt9TikxXOO25NsrgwuMiHDCpa5eyg=.ca9865ca-467a-433d-9e70-0b376df2b15b@github.com>
References: <N-bQ5FdBX42mOCwt9TikxXOO25NsrgwuMiHDCpa5eyg=.ca9865ca-467a-433d-9e70-0b376df2b15b@github.com>
Message-ID: <XHb3okxBp-CYZ3RCfGGiZq0zjX2UzY5BLsxon_zZul0=.2a4a1fff-c8db-45c3-a435-d4224e56961c@github.com>

On Mon, 17 Oct 2022 21:50:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> java.util.Enumeration is a legacy interface from java 1.0.
> There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

src/java.base/share/classes/sun/security/x509/X509CRLEntryImpl.java line 412:

> 410:                 ObjectIdentifier findOID = ObjectIdentifier.of(oid);
> 411:                 for (Extension ex : extensions.getAllExtensions()) {
> 412:                     ObjectIdentifier inCertOID = ex.getExtensionId();

Is the old `getElements` method still useful?

-------------

PR: https://git.openjdk.org/jdk/pull/10734

From aturbanov at openjdk.org  Wed Oct 26 17:00:06 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 26 Oct 2022 17:00:06 GMT
Subject: RFR: 8295953: Use enhanced-for cycle instead of Enumeration in
 sun.security
In-Reply-To: <XHb3okxBp-CYZ3RCfGGiZq0zjX2UzY5BLsxon_zZul0=.2a4a1fff-c8db-45c3-a435-d4224e56961c@github.com>
References: <N-bQ5FdBX42mOCwt9TikxXOO25NsrgwuMiHDCpa5eyg=.ca9865ca-467a-433d-9e70-0b376df2b15b@github.com>
 <XHb3okxBp-CYZ3RCfGGiZq0zjX2UzY5BLsxon_zZul0=.2a4a1fff-c8db-45c3-a435-d4224e56961c@github.com>
Message-ID: <AKvWd-aiCb0mn5HXqqhICaiWAjX5buVMclXW5N9IMFU=.8c2d9a65-2577-47df-9121-3f7a12e6008c@github.com>

On Tue, 18 Oct 2022 17:43:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> java.util.Enumeration is a legacy interface from java 1.0.
>> There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.
>
> src/java.base/share/classes/sun/security/x509/X509CRLEntryImpl.java line 412:
> 
>> 410:                 ObjectIdentifier findOID = ObjectIdentifier.of(oid);
>> 411:                 for (Extension ex : extensions.getAllExtensions()) {
>> 412:                     ObjectIdentifier inCertOID = ex.getExtensionId();
> 
> Is the old `getElements` method still useful?

It seems it's not used in current codebase anymore. Do you propose to drop it?

-------------

PR: https://git.openjdk.org/jdk/pull/10734

From weijun at openjdk.org  Wed Oct 26 17:00:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Oct 2022 17:00:07 GMT
Subject: RFR: 8295953: Use enhanced-for cycle instead of Enumeration in
 sun.security
In-Reply-To: <AKvWd-aiCb0mn5HXqqhICaiWAjX5buVMclXW5N9IMFU=.8c2d9a65-2577-47df-9121-3f7a12e6008c@github.com>
References: <N-bQ5FdBX42mOCwt9TikxXOO25NsrgwuMiHDCpa5eyg=.ca9865ca-467a-433d-9e70-0b376df2b15b@github.com>
 <XHb3okxBp-CYZ3RCfGGiZq0zjX2UzY5BLsxon_zZul0=.2a4a1fff-c8db-45c3-a435-d4224e56961c@github.com>
 <AKvWd-aiCb0mn5HXqqhICaiWAjX5buVMclXW5N9IMFU=.8c2d9a65-2577-47df-9121-3f7a12e6008c@github.com>
Message-ID: <jIDWnRnpJsfrc6o45KhIiGhFxZjGtU3z3_kAvobcAwg=.7c6e73db-cf14-4e4b-b259-94587da14402@github.com>

On Thu, 20 Oct 2022 11:21:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/X509CRLEntryImpl.java line 412:
>> 
>>> 410:                 ObjectIdentifier findOID = ObjectIdentifier.of(oid);
>>> 411:                 for (Extension ex : extensions.getAllExtensions()) {
>>> 412:                     ObjectIdentifier inCertOID = ex.getExtensionId();
>> 
>> Is the old `getElements` method still useful?
>
> It seems it's not used in current codebase anymore. Do you propose to drop it?

Re-read. Maybe not. A lot of other x509 classes have this `getElements` method and it seems the one you touched is the only actually used. This might be an obsolete convention and if we want to remove them we can remove them in another issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10734

From xuelei at openjdk.org  Wed Oct 26 17:11:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)

What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Wed Oct 26 17:29:01 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:29:01 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
Message-ID: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>

On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/URL.java line 852:
> 
>> 850:      * @since 20
>> 851:      */
>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
> 
> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

`URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From xuelei at openjdk.org  Wed Oct 26 17:42:31 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:42:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
Message-ID: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>

On Wed, 26 Oct 2022 17:24:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URL.java line 852:
>> 
>>> 850:      * @since 20
>>> 851:      */
>>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
>> 
>> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?
>
> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.

I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.

Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Wed Oct 26 17:57:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:57:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
Message-ID: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>

On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.
>
> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
> 
> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
> 
> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From jnimeh at openjdk.org  Wed Oct 26 20:48:24 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 26 Oct 2022 20:48:24 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <KwT1ejhy7yvVIpMPCpkT2E87-bwwXRvVhZ-fy_Bm8po=.d71506cf-3e0c-4eb8-a008-390ab2ff4e02@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
 <KwT1ejhy7yvVIpMPCpkT2E87-bwwXRvVhZ-fy_Bm8po=.d71506cf-3e0c-4eb8-a008-390ab2ff4e02@github.com>
Message-ID: <cjsKh51GqdfZ4GnIcniUrJfX7McnzDOz_cSf3BSR4FA=.4181923c-e89d-4e1d-902a-0b390b515472@github.com>

On Wed, 26 Oct 2022 15:47:08 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 171:
>> 
>>> 169:         }
>>> 170: 
>>> 171:         if (len >= 1024) {
>> 
>> Out of curiosity, do you have any perf numbers for the impact of this change on systems that do not support AVX512?  Does this help or hurt (or make a negligible impact) on poly1305 updates when the input is 1K or larger?
>
> (The first commit in this PR actually has the code without the check if anyone wants to measure.. well its also trivial to edit..)
> 
> I measured about 50% slowdown on 64 byte payloads. One could argue that 64 bytes is not all that representative, but we don't get much out of assembler at that load either so it didn't seem worth it to figure out some sort of platform check. 
> 
> AVX512 needs at least 256 = 16 blocks.. there is overhead also pre-calculating powers of R that needs to be amortized. Assembler does fall back to 64-bit multiplies for <256, while the Java version will have to use the 32-bit multiplies. <256, purely scalar, non-vector, 64 vs 32 is not _that_ big an issue though; the algorithm is plenty happy with 26-bit limbs, and whatever the benefit of 64, it gets erased by the interface-matching code copying limbs in and out..
> 
> Right now, I measured 1k with `-XX:-UsePolyIntrinsics` to be about 10% slower. I think its acceptable, in order to get 18x?
> 
> Most/all of the slowdown comes from this need of copying limbs out/in.. I am looking at perhaps copying limbs out in the intrinsic instead. Not very 'pretty'.. limbs are hidden in a nested private class behind an interface.. I would be breaking what is a good design with neat encapsulation. (I accidentally forced-pushed that earlier, if you are curious; non-working). The current version of this code seems more robust in the long term?

10% is not a negligible impact.  I see your point about AVX512 reaping the rewards of this change, but there are plenty of x86_64 systems without AVX512 that will be impacted, not to mention other platforms like aarch64 which (for this change at least) will never see the benefits from the intrinsic.

I don't have any suggestions right at this moment for how this could be streamlined at all to help reduce the pain for non-AVX512 systems.  Worth looking into though.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From jnimeh at openjdk.org  Wed Oct 26 21:15:25 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 26 Oct 2022 21:15:25 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <cjsKh51GqdfZ4GnIcniUrJfX7McnzDOz_cSf3BSR4FA=.4181923c-e89d-4e1d-902a-0b390b515472@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
 <KwT1ejhy7yvVIpMPCpkT2E87-bwwXRvVhZ-fy_Bm8po=.d71506cf-3e0c-4eb8-a008-390ab2ff4e02@github.com>
 <cjsKh51GqdfZ4GnIcniUrJfX7McnzDOz_cSf3BSR4FA=.4181923c-e89d-4e1d-902a-0b390b515472@github.com>
Message-ID: <SajtNyPTRfsIaMh_o-fFN0Q1HYmehmUl-V5QCWm5jp4=.56a900ad-c725-4577-89d1-8ea860776d88@github.com>

On Wed, 26 Oct 2022 20:45:57 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> (The first commit in this PR actually has the code without the check if anyone wants to measure.. well its also trivial to edit..)
>> 
>> I measured about 50% slowdown on 64 byte payloads. One could argue that 64 bytes is not all that representative, but we don't get much out of assembler at that load either so it didn't seem worth it to figure out some sort of platform check. 
>> 
>> AVX512 needs at least 256 = 16 blocks.. there is overhead also pre-calculating powers of R that needs to be amortized. Assembler does fall back to 64-bit multiplies for <256, while the Java version will have to use the 32-bit multiplies. <256, purely scalar, non-vector, 64 vs 32 is not _that_ big an issue though; the algorithm is plenty happy with 26-bit limbs, and whatever the benefit of 64, it gets erased by the interface-matching code copying limbs in and out..
>> 
>> Right now, I measured 1k with `-XX:-UsePolyIntrinsics` to be about 10% slower. I think its acceptable, in order to get 18x?
>> 
>> Most/all of the slowdown comes from this need of copying limbs out/in.. I am looking at perhaps copying limbs out in the intrinsic instead. Not very 'pretty'.. limbs are hidden in a nested private class behind an interface.. I would be breaking what is a good design with neat encapsulation. (I accidentally forced-pushed that earlier, if you are curious; non-working). The current version of this code seems more robust in the long term?
>
> 10% is not a negligible impact.  I see your point about AVX512 reaping the rewards of this change, but there are plenty of x86_64 systems without AVX512 that will be impacted, not to mention other platforms like aarch64 which (for this change at least) will never see the benefits from the intrinsic.
> 
> I don't have any suggestions right at this moment for how this could be streamlined at all to help reduce the pain for non-AVX512 systems.  Worth looking into though.

One small thing maybe: It doesn't look like R in `processMultipleBlocks` and `rbytes` ever changes, so maybe there's no need to repeatedly serialize/deserialize them on every call to engineUpdate?  There is already an `r` that is attached to the object that is an IntegerModuloP.  Could that be used in `processMultipleBlocks` and perhaps a private byte[] for a serialized r is also a field in Poly1305 that can be passed into the intrinsic method rather than creating it every time?  It could be set in `setRSVals`.  Perhaps we can recover a little performance there?

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From peter.firmstone at zeus.net.au  Wed Oct 26 22:53:30 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 08:53:30 +1000
Subject: Request - Preparation for removal of SecurityManager
In-Reply-To: <2eae2f6b-0e82-a357-0cb0-857b2f13845f@oracle.com>
References: <ff7695da-588f-55ca-99c5-033df9682848@zeus.net.au>
 <7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com>
 <5fe809c0-ce74-4ea3-cfb5-f18524506f76@zeus.net.au>
 <a68be7f4-51f5-fcfd-9360-eae1cf1c7524@oracle.com>
 <1fbcb952-a2e7-2a23-1c77-9f98133ffbf9@zeus.net.au>
 <2eae2f6b-0e82-a357-0cb0-857b2f13845f@oracle.com>
Message-ID: <c83a93e0-786f-2a23-a499-25021305fc2b@zeus.net.au>

Thanks Alan, comments inline below.

On 26/10/2022 11:07 pm, Alan Bateman wrote:

>
>> :
>>
>> What would make a significant difference is returning non null 
>> ProtectionDomain's for JDK modules, so we can reduce the size of the 
>> trusted computing base, to make our job smaller, hopefully that will 
>> allow focusing on placing authorization checks on the low level 
>> access to file systems and networks, which are our main concerns.
> The PD should not be null, maybe you mean the CodeSource? I think we 
> exchanged mail about this before and it might be generally useful to 
> have that. It would mean working through some issues related to patching.

Apologies, you are correct, a non-null CodeSource in system PD's.?? 
Thank you for remembering :)


>
>
>> :
>>
>> Do you think that tighter module boundaries will negate the need for 
>> RuntimePermission accessClassInPackage.* below?
> This is only needed when running with a SM.
>
I will need to assess each before I decide whether it warrants 
instrumenting or not.? Authorization controls aren't really the right 
tool for this, it feels like a hack, it belongs under language 
visibility controls, such as module boundaries.? In our system, 
authorization will only grant dynamic class loading to authenticated and 
authorised entities, so some of these things might belong under 
monitoring and reporting.?? We can also require that dynamically loaded 
code is signed, the signer certificates for code can be communicated 
after authentication, before dynamically loading code, so we don't 
require a Certificate Authority for code certs.? We're not running 
untrusted code, but we do use PD's to represent a remote service, that 
has a presence in the local JVM, which may or may not include code.

Regards,

Peter.



From peter.firmstone at zeus.net.au  Wed Oct 26 22:53:52 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 08:53:52 +1000
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
Message-ID: <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>

Interesting.? Is this RFR a done deal?

While I like the concept and and understand the reasoning of URL not 
having a public constructor, I think this may have been thought of in 
isolation, I'm not sure how a custom URI, that strictly complies with 
RFC 3986 will behave, if it must also be parsed by java.net.URI, which 
is loosely compliant with RFC 2396 and RFC 2732.? Has anyone done any 
investigation?? We stopped using java.net.URI some years ago as it's 
obsolete.? The change will have some performance impact, by requiring 
redundant parsing.

Just thought I'd mention it, in case it hasn't been thought of. If you 
do an internet search there are other implementations of RFC3986 in java 
also.

https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966

We have a strict URI 3986 implementation, which we use to create all URL 
instances from.

This is how we avoid unnecessarily incurring accesses to file systems 
and DNS, this implementation had a massive performance and scalability 
improvement for us.

/**
 ?* This class represents an immutable instance of a URI as defined by 
RFC 3986.
 ?* <p>
 ?* This class replaces java.net.URI functionality.
 ?* <p>
 ?* Unlike java.net.URI this class is not Serializable and hashCode and
 ?* equality is governed by strict RFC3986 normalisation. In addition 
"other"
 ?* characters allowed in java.net.URI as specified by javadoc, not 
specifically
 ?* allowed by RFC3986 are illegal and must be escaped.? This strict 
adherence
 ?* is essential to eliminate false negative or positive matches.
 ?* <p>
 ?* In addition to RFC3896 normalisation, on OS platforms with a \ file 
separator
 ?* the path is converted to UPPER CASE for comparison for file: schema, 
during
 ?* equals and hashCode calls.
 ?* <p>
 ?* IPv6 and IPvFuture host addresses must be enclosed in square 
brackets as per
 ?* RFC3986.? A zone delimiter %, if present, must be represented in 
escaped %25
 ?* form.
 ?* <p>
 ?* In addition to RFC3896 normalization, IPv6 host addresses will be 
normalized
 ?* to comply with RFC 5952 A Recommendation for IPv6 Address Text 
Representation.
 ?* This is to ensure consistent equality between identical IPv6 addresses.
 ?*
 ?* @since 3.0.0
 ?*/


Regards,
Peter.

On 27/10/2022 3:57 am, Daniel Fuchs wrote:
> On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:
>
>>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.
>> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
>>
>> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
>>
>> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.
> One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10874


From ecki at zusammenkunft.net  Thu Oct 27 00:39:46 2022
From: ecki at zusammenkunft.net (Bernd)
Date: Thu, 27 Oct 2022 02:39:46 +0200
Subject: Clogged pipes: 50x throughput degradation with large Cipher writes
In-Reply-To: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
References: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
Message-ID: <13A4235D-8D69-8A4F-9CFC-AEC1ADB95C86@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221027/1cfdbea4/attachment-0001.htm>

From duke at openjdk.org  Thu Oct 27 05:16:38 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 05:16:38 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
Message-ID: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>

On Wed, 26 Oct 2022 16:41:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
> 
>> 175:         @SuppressWarnings("deprecation")
>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>> 177: 
> 
> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

Having?unnamed local?variables[^1] would?probably be?best for?this.

[^1]: https://openjdk.org/jeps/8294349

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From Alan.Bateman at oracle.com  Thu Oct 27 06:26:46 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Oct 2022 07:26:46 +0100
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
Message-ID: <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>

On 26/10/2022 23:53, Peter Firmstone wrote:
> The change will have some performance impact, by requiring redundant 
> parsing.
>
> Just thought I'd mention it, in case it hasn't been thought of. If you 
> do an internet search there are other implementations of RFC3986 in 
> java also.
>
> https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966 
>
>
> We have a strict URI 3986 implementation, which we use to create all 
> URL instances from.

If your parser is using the one-arg URL constructor to create the URL 
then it will be parsed again, so you may already have duplicate 
parsing.? That said, there may be an argument that libraries should be 
able to do their own parsing and continue to construct a URL from its 
components with the non-validating constructors.

As I'm sure you know, changing URI to strictly implement RFC 3986 is not 
a compatible move. It was attempted in JDK 6 but had to backed out 
quickly as it caused widespread breakage. Hierarchical URIs using 
registry based authority components was one of significant issues. There 
has been exploration and prototypes since then to try to find a 
direction but there isn't a proposal right now.

-Alan

From mbaesken at openjdk.org  Thu Oct 27 08:03:39 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Oct 2022 08:03:39 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v3]
In-Reply-To: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
Message-ID: <HiUuGNxlJwtn8CpUChQ2V1t-NsKxpbGeufyiaPpHiyI=.896b054a-ea99-4e65-8ed3-67cc9517e95d@github.com>

> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
> 
> https://bugs.openjdk.org/browse/JDK-8295343
> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
> 
> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  small adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10726/files
  - new: https://git.openjdk.org/jdk/pull/10726/files/ed346e06..c158d416

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10726&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10726&range=01-02

  Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10726/head:pull/10726

PR: https://git.openjdk.org/jdk/pull/10726

From mbaesken at openjdk.org  Thu Oct 27 08:03:40 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Oct 2022 08:03:40 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <Q3nE8fY3w2Z89ijDWj8uSFBj6kOcReEy9PMK7E16UdI=.da4d35e0-d4ce-4372-8fdd-56a1f96a76ba@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
 <Q3nE8fY3w2Z89ijDWj8uSFBj6kOcReEy9PMK7E16UdI=.da4d35e0-d4ce-4372-8fdd-56a1f96a76ba@github.com>
Message-ID: <-F9f-yAapTd422oCGkVKgYNb1Btv2dF6lbVsYbssNpQ=.fee77c12-9b8a-424d-b80e-430c091153ea@github.com>

On Wed, 26 Oct 2022 15:22:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More causes
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java line 212:
> 
>> 210:         } catch (NullPointerException npe) {
>> 211:             throw new SignatureException("Unsupported digest: " +
>> 212:                     digestAlg, npe);
> 
> I don't think the `NullPointerException` adds any value here. I would leave that out.

okay, I removed this change.

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From peter.firmstone at zeus.net.au  Thu Oct 27 08:54:47 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 18:54:47 +1000
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
 <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
Message-ID: <2cedb39c-462e-5913-6f4c-c1149f72f468@zeus.net.au>


On 27/10/2022 4:26 pm, Alan Bateman wrote:
> On 26/10/2022 23:53, Peter Firmstone wrote:
>> The change will have some performance impact, by requiring redundant 
>> parsing.
>>
>> Just thought I'd mention it, in case it hasn't been thought of. If 
>> you do an internet search there are other implementations of RFC3986 
>> in java also.
>>
>> https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966 
>>
>>
>> We have a strict URI 3986 implementation, which we use to create all 
>> URL instances from.
>
> If your parser is using the one-arg URL constructor to create the URL 
> then it will be parsed again, so you may already have duplicate 
> parsing.? That said, there may be an argument that libraries should be 
> able to do their own parsing and continue to construct a URL from its 
> components with the non-validating constructors.

You are right, it was over 10 years ago when I originally wrote it, I'm 
a little rusty on the reason why I chose the single argument 
constructor, it's possible I would do it differently if implementing it 
today.? I might have been worried about what might break at the time.? 
We did have a developer in a downstream project who used a URN and a 
custom URLHandler, made possible by the change to RFC3986.

I think today we could safely change it to a non parsing constructor.

>
> As I'm sure you know, changing URI to strictly implement RFC 3986 is 
> not a compatible move. It was attempted in JDK 6 but had to backed out 
> quickly as it caused widespread breakage. Hierarchical URIs using 
> registry based authority components was one of significant issues. 
> There has been exploration and prototypes since then to try to find a 
> direction but there isn't a proposal right now.

The performance cost of retaining compatibility was a problem as we had 
to rely on DNS and file system access to determine equality as 
java.net.URI wasn't suitable, we wanted a normalized form, with 
guaranteed equality without network or file system access, so we decided 
to break compatibility, as the tradeoff was significantly in 
performance's favour.

It's used throughout our software, there's a URI3986ClassLoader, which 
extends SecureClassLoader, it's also used in unicast discovery of 
services (over network) and it's also used for Policy decisions...

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/RFC3986URLClassLoader.java

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/discovery/LookupLocator.java

In Policy to replace CodeSource#implies functionality:

https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/URIGrant.java#L132

Historically our software was horribly impacted by URL#equals and 
URL#hashCode and we went to a great deal of trouble to eliminate all 
such calls and replace them with Uri.?? Which is why Uri is immutable, 
normalized and not Serializable.

We utilised bitshift operations for case conversion, after String 
methods became hotspots.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/URIEncoderDecoder.java

I suspect the best solution might be to leave java.net.URI alone and 
write a new implementation that isn't compatible, then eventually 
deprecate and remove java.net.URI.?? Tip: Don't make it Serializable, 
let people Serialize the string form instead.

Regards,

Peter.


From michaelm at openjdk.org  Thu Oct 27 09:21:35 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 27 Oct 2022 09:21:35 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
Message-ID: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>

On Thu, 27 Oct 2022 05:14:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
>> 
>>> 175:         @SuppressWarnings("deprecation")
>>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>>> 177: 
>> 
>> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?
>
> Having?unnamed local?variables[^1] would?probably be?best for?this.
> 
> [^1]: https://openjdk.org/jeps/8294349

How about `_unused` or `_unused1`, `_unused2` then in the meantime?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From jbhateja at openjdk.org  Thu Oct 27 09:39:32 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 27 Oct 2022 09:39:32 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
Message-ID: <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>

On Mon, 24 Oct 2022 22:09:29 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s
>
> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra whitespace character

Few other non-algorithm change set comments.

src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 22:

> 20:  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> 21:  * or visit www.oracle.com if you need additional information or have any
> 22:  * questions.

Of late  stub code has been re-organized, to comply with it you may want to remove this file and merge macro-assembly code into a new file stubGenerator_x86_64_poly.cpp on the lines of src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp

src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 849:

> 847:   jcc(Assembler::less, L_process16Loop);
> 848: 
> 849:   poly1305_process_blocks_avx512(input, length,

Since entire code is based on 512 bit encoding misalignment penalty may be costly here. A scalar peel handling (as done in tail) for input portion before a 64 byte aligned address  could further improve the performance for large block sizes.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2040:

> 2038: 
> 2039: address StubGenerator::generate_poly1305_processBlocks() {
> 2040:   __ align64();

This can be replaced by  __ align(CodeEntryAlignment);

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 175:

> 173:             // Choice of 1024 is arbitrary, need enough data blocks to amortize conversion overhead
> 174:             // and not affect platforms without intrinsic support
> 175:             int blockMultipleLength = (len/BLOCK_LENGTH) * BLOCK_LENGTH;

Since Poly processes 16 byte chunks, a strength reduced version of above expression could be len & (~(BLOCK_LEN-1)

test/micro/org/openjdk/bench/javax/crypto/full/Poly1305DigestBench.java line 94:

> 92:             throw new RuntimeException(ex);
> 93:         }
> 94:     }

On CLX patch shows performance regression of about 10% for block size 1024-2048+.

CLX (Non-IFMA target)

Baseline (JDK-20):-

Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score   Error  Units
Poly1305DigestBench.digest          64              thrpt    2  3128928.978          ops/s
Poly1305DigestBench.digest         256              thrpt    2  1526452.083          ops/s
Poly1305DigestBench.digest        1024              thrpt    2   509267.401          ops/s
Poly1305DigestBench.digest        2048              thrpt    2   305784.922          ops/s
Poly1305DigestBench.digest        4096              thrpt    2   142175.885          ops/s
Poly1305DigestBench.digest        8192              thrpt    2    72142.906          ops/s
Poly1305DigestBench.digest       16384              thrpt    2    36357.000          ops/s
Poly1305DigestBench.digest     1048576              thrpt    2      676.142          ops/s


Withopt:
Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score   Error  Units
Poly1305DigestBench.digest          64              thrpt    2  3136204.416          ops/s
Poly1305DigestBench.digest         256              thrpt    2  1683221.124          ops/s
Poly1305DigestBench.digest        1024              thrpt    2   457432.172          ops/s
Poly1305DigestBench.digest        2048              thrpt    2   277563.817          ops/s
Poly1305DigestBench.digest        4096              thrpt    2   149393.357          ops/s
Poly1305DigestBench.digest        8192              thrpt    2    79463.734          ops/s
Poly1305DigestBench.digest       16384              thrpt    2    41083.730          ops/s
Poly1305DigestBench.digest     1048576              thrpt    2      705.419          ops/s

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From jbhateja at openjdk.org  Thu Oct 27 09:39:33 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 27 Oct 2022 09:39:33 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <SajtNyPTRfsIaMh_o-fFN0Q1HYmehmUl-V5QCWm5jp4=.56a900ad-c725-4577-89d1-8ea860776d88@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
 <KwT1ejhy7yvVIpMPCpkT2E87-bwwXRvVhZ-fy_Bm8po=.d71506cf-3e0c-4eb8-a008-390ab2ff4e02@github.com>
 <cjsKh51GqdfZ4GnIcniUrJfX7McnzDOz_cSf3BSR4FA=.4181923c-e89d-4e1d-902a-0b390b515472@github.com>
 <SajtNyPTRfsIaMh_o-fFN0Q1HYmehmUl-V5QCWm5jp4=.56a900ad-c725-4577-89d1-8ea860776d88@github.com>
Message-ID: <SHVra8SjH-iWXZ-s-f4cWtbylOAg8rlGNQc3cVxTFRI=.c2d808b3-e5cb-4131-8c0b-e1c873aa5b3c@github.com>

On Wed, 26 Oct 2022 21:11:33 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> 10% is not a negligible impact.  I see your point about AVX512 reaping the rewards of this change, but there are plenty of x86_64 systems without AVX512 that will be impacted, not to mention other platforms like aarch64 which (for this change at least) will never see the benefits from the intrinsic.
>> 
>> I don't have any suggestions right at this moment for how this could be streamlined at all to help reduce the pain for non-AVX512 systems.  Worth looking into though.
>
> One small thing maybe: It doesn't look like R in `processMultipleBlocks` and `rbytes` ever changes, so maybe there's no need to repeatedly serialize/deserialize them on every call to engineUpdate?  There is already an `r` that is attached to the object that is an IntegerModuloP.  Could that be used in `processMultipleBlocks` and perhaps a private byte[] for a serialized r is also a field in Poly1305 that can be passed into the intrinsic method rather than creating it every time?  It could be set in `setRSVals`.  Perhaps we can recover a little performance there?

> 10% is not a negligible impact. I see your point about AVX512 reaping the rewards of this change, but there are plenty of x86_64 systems without AVX512 that will be impacted, not to mention other platforms like aarch64 which (for this change at least) will never see the benefits from the intrinsic.
> 
> I don't have any suggestions right at this moment for how this could be streamlined at all to help reduce the pain for non-AVX512 systems. Worth looking into though.

Do you suggest using white box APIs for CPU feature query during poly static initialization and perform multi block partitioning only for relevant platforms and keep the original implementation sacrosanct for other targets. VM does offer native white box primitives and currently its being used by tests infrastructure.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From coffeys at openjdk.org  Thu Oct 27 10:06:24 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 27 Oct 2022 10:06:24 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v3]
In-Reply-To: <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
Message-ID: <trudxaHDBPwC6dzxGz2FtsgoUpY8om5fJATF3ftmBXU=.3b198720-348c-4f21-b5c6-8939c7b286a3@github.com>

On Tue, 25 Oct 2022 14:56:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)
>> 
>> test case also updated to capture new logic
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use X500Principal#toString()

Thanks for the feedback Sean. Yes - this event should also cater for the internal `new X509CertImpl` type calls that are sprinkled through some of the security libraries.

Some look a bit suspicious perhaps ? I see OCSP/CertPath type calls to `new X509CertImpl`  --- given that CertPath and CertificateFactory are viewed as two different services at the JCA level, I wonder if they should be routing calls back to `java.security.cert.CertificateFactory#generateCertificate` when generating certs ?

I'll study further and see if we can maximize the number of X509Certificate JFR events that are captured.

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From dfuchs at openjdk.org  Thu Oct 27 11:28:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 11:28:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
Message-ID: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>

On Thu, 27 Oct 2022 09:17:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Having?unnamed local?variables[^1] would?probably be?best for?this.
>> 
>> [^1]: https://openjdk.org/jeps/8294349
>
> How about `_unused` or `_unused1`, `_unused2` then in the meantime?

I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From daniel.fuchs at oracle.com  Thu Oct 27 11:29:45 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 27 Oct 2022 12:29:45 +0100
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
 <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
Message-ID: <a341387b-e932-02fe-be32-b5ceaaaeb6c7@oracle.com>

On 27/10/2022 07:26, Alan Bateman wrote:
>> We have a strict URI 3986 implementation, which we use to create all 
>> URL instances from.

Note also that though this change proposes to deprecate these
constructors in order to provide a stronger warning against their
potential misuse, it does not deprecate them for removal.

If you are confident in your parsing/validation you can of course
still provide a `URL toURL(org.apache.river.api.net.URI)` method that
calls a constructor, and annotate that one place with 
`@SuppressWarnings("deprecation")`.

best regards,

-- dabniel


From peter.firmstone at zeus.net.au  Thu Oct 27 11:48:34 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 21:48:34 +1000
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <a341387b-e932-02fe-be32-b5ceaaaeb6c7@oracle.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
 <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
 <a341387b-e932-02fe-be32-b5ceaaaeb6c7@oracle.com>
Message-ID: <0448a3f6-2dbb-f809-ba1f-2503999dbb18@zeus.net.au>

I'm considering using one of the non parsing constructors, as Alan 
points out we're currently double parsing.? By the time the constructor 
is removed, I'm guessing there will be a RFC3986 URI implementation in 
the JDK, so we'll change to that when it happens.?? Or if you decide to 
not deprecate one of the non parsing constructors, I'm good with that also.

Regards,

Peter.

On 27/10/2022 9:29 pm, Daniel Fuchs wrote:
> On 27/10/2022 07:26, Alan Bateman wrote:
>>> We have a strict URI 3986 implementation, which we use to create all 
>>> URL instances from.
>
> Note also that though this change proposes to deprecate these
> constructors in order to provide a stronger warning against their
> potential misuse, it does not deprecate them for removal.
>
> If you are confident in your parsing/validation you can of course
> still provide a `URL toURL(org.apache.river.api.net.URI)` method that
> calls a constructor, and annotate that one place with 
> `@SuppressWarnings("deprecation")`.
>
> best regards,
>
> -- dabniel
>

From ckozak at ckozak.net  Thu Oct 27 12:25:37 2022
From: ckozak at ckozak.net (Carter Kozak)
Date: Thu, 27 Oct 2022 08:25:37 -0400
Subject: Clogged pipes: 50x throughput degradation with large Cipher writes
In-Reply-To: <13A4235D-8D69-8A4F-9CFC-AEC1ADB95C86@hxcore.ol>
References: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
 <13A4235D-8D69-8A4F-9CFC-AEC1ADB95C86@hxcore.ol>
Message-ID: <46204306-d64c-4e60-b0e6-eeaaf8ab8415@app.fastmail.com>

Thanks for your interest in the topic.

> While it might not be a problem in practice (large buffers are ok, but larger than 1mb seems seldom, especially in multi threaded apps) it is still a condition which can be handled. But with AE ciphers becoming the norm, such large cipher chunks seems to be legacy as well?

The linked benchmark is a good representation of the problem as we encountered it in a production instance. A compute job (as opposed to a typical multi-threaded server) took data that was already buffered (relatively large byte-array on heap), and attempted to store it (either to disk, S3, etc), encrypting the data first. The filesystem is likely attached via a network, however the encryption in this case is a separate concern. We use a CipherOutputStream to encrypt data as we write it to storage. The client code only sees an OutputStream, so it's not clear to the caller that inputs should be segmented into smaller chunks -- it's often best to provide fewer, larger writes to a disk. The cipher interactions in this case are the result of the way other JDK components (namely CipherOutputStream) work. BufferedOutputStream is generally used to reduce interactions with Ciphers to avoid inefficient small operations, but it passes through large buffers to the delegate, allowing multi-megabyte cipher operations.

I could see an argument for CipherOutputStream becoming responsible for chunking, although that may not be ideal for native Cipher implementations which aren't constrained in the same ways, where perhaps a Cipher instance should have the ability to recommend a maximum segment size to callers (e.g. CipherOutputStream would segment based on a recommendation from cipher instances).
 
> Can you clarify. You said JSSE, does this actually happen in TLS usage  - how big are your TLS Records? Isn?t there a 16k limit anyway? 

I'm sorry, I confused initialisms, I believe JCE is more accurate. I can test TLS, but that's not the scenario where this was problematic in production.

Carter Kozak

From mbaesken at openjdk.org  Thu Oct 27 12:28:29 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Oct 2022 12:28:29 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v2]
In-Reply-To: <Zl4GY2OsoxhAu6TQJRHJRQzUaz807qCWkN66HJXXuxY=.f3d327a7-f508-4c93-b1da-924f52662c1a@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <Sjht4b5jyA8COUCiwszhe8IaP_FYBkdMbZulTgB9UfE=.a5e4d913-db01-4b61-8a27-5f7e1e269ec3@github.com>
 <fY-Sd5Dr02MYyZ3HaihTUXvVyiHsUB0wpvqwWmKd49A=.c70450f8-03dc-449b-932e-fb58567a04c1@github.com>
 <J2vpPxehluL2lHJePd3VElIwhzwSo_7LNG1JfFo4LW0=.8e228d78-8b31-48e2-819f-e37be0c4161c@github.com>
 <Zl4GY2OsoxhAu6TQJRHJRQzUaz807qCWkN66HJXXuxY=.f3d327a7-f508-4c93-b1da-924f52662c1a@github.com>
Message-ID: <KxrXNxHp48wmstTcBasWcl4kYRXpn0oZPGXMU9ICQ5M=.d25e0c78-601a-4ebe-b34d-d893d1efdfbb@github.com>

On Wed, 26 Oct 2022 15:18:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I think you mean InvalidParameterException. InvalidAlgorithmParameterException has a ctor that takes a cause. Can you file an RFE?

Sorry I meant indeed InvalidParameterException .
But I plan to propose this in another JBS issue not this one.

Thanks, Matthias

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From ecki at zusammenkunft.net  Thu Oct 27 13:15:00 2022
From: ecki at zusammenkunft.net (Bernd)
Date: Thu, 27 Oct 2022 15:15:00 +0200
Subject: Clogged pipes: 50x throughput degradation with large Cipher writes
In-Reply-To: <46204306-d64c-4e60-b0e6-eeaaf8ab8415@app.fastmail.com>
References: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
 <13A4235D-8D69-8A4F-9CFC-AEC1ADB95C86@hxcore.ol>,
 <46204306-d64c-4e60-b0e6-eeaaf8ab8415@app.fastmail.com>
Message-ID: <7A8E90BE-A262-724E-AC6A-36831638AF5D@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221027/0dd81f05/attachment-0001.htm>

From weijun at openjdk.org  Thu Oct 27 14:20:30 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Oct 2022 14:20:30 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v3]
In-Reply-To: <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
Message-ID: <J8tJ1t4jRlvwb2C1-1uHAkEfHWtu6By9i9XmN22M1AM=.29765c54-fcb5-4b98-b8ae-d1c835093ebd@github.com>

On Tue, 25 Oct 2022 14:56:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)
>> 
>> test case also updated to capture new logic
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use X500Principal#toString()

If this event is mainly for public access through the `CertificateFactory` API, then there is no need to care about internal creation of `X509CertImpl` directly.

-------------

PR: https://git.openjdk.org/jdk/pull/10422

From mullan at openjdk.org  Thu Oct 27 14:29:28 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Oct 2022 14:29:28 GMT
Subject: RFR: 8293858: Change PKCS7 code to use default SecureRandom impl
 instead of SHA1PRNG
Message-ID: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>

For timestamp nonces, change the PKCS7 code to use the default SecureRandom PRNG (which varies depending on the OS), instead of SHA1PRNG.

-------------

Commit messages:
 - Change PKCS7 code to use default SecureRandom impl instead of SHA1PRNG.

Changes: https://git.openjdk.org/jdk/pull/10883/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10883&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293858
  Stats: 23 lines in 1 file changed: 1 ins; 19 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10883.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10883/head:pull/10883

PR: https://git.openjdk.org/jdk/pull/10883

From ferenc.r.rakoczi at oracle.com  Thu Oct 27 14:40:42 2022
From: ferenc.r.rakoczi at oracle.com (Ferenc Rakoczi)
Date: Thu, 27 Oct 2022 14:40:42 +0000
Subject: Clogged pipes: 50x throughput degradation with large Cipher writes
In-Reply-To: <46204306-d64c-4e60-b0e6-eeaaf8ab8415@app.fastmail.com>
References: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
 <13A4235D-8D69-8A4F-9CFC-AEC1ADB95C86@hxcore.ol>
 <46204306-d64c-4e60-b0e6-eeaaf8ab8415@app.fastmail.com>
Message-ID: <PH0PR10MB4504A919C9916129AF0EB064AF339@PH0PR10MB4504.namprd10.prod.outlook.com>

The fragmentation can be done within the update(?) functions that call the intrinsified processBlocks(?) (in this case there are only 2 of those, with 3 call sites altogether), but a more general solution would be if somehow we could tell the JIT compiler (with an annotation similar to @IntrinsicCandidate): ?use the intrinsic if there is one, from the first call, I am pretty sure it will be worth it even if we use this function only once?.

Ferenc

From: security-dev <security-dev-retn at openjdk.org> on behalf of Carter Kozak <ckozak at ckozak.net>
Date: Thursday, 2022. October 27. 14:26
To: security-dev at openjdk.org <security-dev at openjdk.org>
Subject: Re: Clogged pipes: 50x throughput degradation with large Cipher writes
Thanks for your interest in the topic.

> While it might not be a problem in practice (large buffers are ok, but larger than 1mb seems seldom, especially in multi threaded apps) it is still a condition which can be handled. But with AE ciphers becoming the norm, such large cipher chunks seems to be legacy as well?

The linked benchmark is a good representation of the problem as we encountered it in a production instance. A compute job (as opposed to a typical multi-threaded server) took data that was already buffered (relatively large byte-array on heap), and attempted to store it (either to disk, S3, etc), encrypting the data first. The filesystem is likely attached via a network, however the encryption in this case is a separate concern. We use a CipherOutputStream to encrypt data as we write it to storage. The client code only sees an OutputStream, so it's not clear to the caller that inputs should be segmented into smaller chunks -- it's often best to provide fewer, larger writes to a disk. The cipher interactions in this case are the result of the way other JDK components (namely CipherOutputStream) work. BufferedOutputStream is generally used to reduce interactions with Ciphers to avoid inefficient small operations, but it passes through large buffers to the delegate, allowing multi-megabyte cipher operations.

I could see an argument for CipherOutputStream becoming responsible for chunking, although that may not be ideal for native Cipher implementations which aren't constrained in the same ways, where perhaps a Cipher instance should have the ability to recommend a maximum segment size to callers (e.g. CipherOutputStream would segment based on a recommendation from cipher instances).

> Can you clarify. You said JSSE, does this actually happen in TLS usage  - how big are your TLS Records? Isn?t there a 16k limit anyway?

I'm sorry, I confused initialisms, I believe JCE is more accurate. I can test TLS, but that's not the scenario where this was problematic in production.

Carter Kozak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221027/f2ea3d6b/attachment-0001.htm>

From mpowers at openjdk.org  Thu Oct 27 15:17:21 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 27 Oct 2022 15:17:21 GMT
Subject: RFR: 8293858: Change PKCS7 code to use default SecureRandom impl
 instead of SHA1PRNG
In-Reply-To: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
References: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
Message-ID: <RjEOka8K_nVHKPMlIDD-ox-v_dnydiGp6v3gEH3bZtc=.99e276da-9ed0-4350-a843-9c70a9ce6f80@github.com>

On Thu, 27 Oct 2022 14:21:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> For timestamp nonces, change the PKCS7 code to use the default SecureRandom PRNG (which varies depending on the OS), instead of SHA1PRNG.

LGTM

-------------

PR: https://git.openjdk.org/jdk/pull/10883

From weijun at openjdk.org  Thu Oct 27 15:36:25 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Oct 2022 15:36:25 GMT
Subject: RFR: 8293858: Change PKCS7 code to use default SecureRandom impl
 instead of SHA1PRNG
In-Reply-To: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
References: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
Message-ID: <WbkM0Ovv6vXkkHSB64bOXq5OI2Xj7LePLwfpHwXY03c=.14da0049-ed40-4b14-ae20-ae832abc1850@github.com>

On Thu, 27 Oct 2022 14:21:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> For timestamp nonces, change the PKCS7 code to use the default SecureRandom PRNG (which varies depending on the OS), instead of SHA1PRNG.

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10883

From xuelei at openjdk.org  Thu Oct 27 15:57:23 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 27 Oct 2022 15:57:23 GMT
Subject: RFR: 8293858: Change PKCS7 code to use default SecureRandom impl
 instead of SHA1PRNG
In-Reply-To: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
References: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
Message-ID: <4xXhR7aozBKYLbaCez42yXxs0LxN1Fih2QU-cjFX2W4=.6885eedb-7735-4755-8de7-ce355d005223@github.com>

On Thu, 27 Oct 2022 14:21:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> For timestamp nonces, change the PKCS7 code to use the default SecureRandom PRNG (which varies depending on the OS), instead of SHA1PRNG.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10883

From anthony.scarpino at oracle.com  Thu Oct 27 16:00:21 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 27 Oct 2022 09:00:21 -0700
Subject: Clogged pipes: 50x throughput degradation with large Cipher writes
In-Reply-To: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
References: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
Message-ID: <2f7c9be7-45d4-0768-513d-dde5324def1b@oracle.com>

Hi Carter,

CTR doesn't have the same splitting up of the input data to speed the 
triggering of the intrinsic that GCM has.  The need to split data is 
such as narrow situation as users don't typically use 1, 10 or 100MB 
data sizes.

Are you using a particular application where you are seeing the 
performance drop off clearly, besides a benchmark?

thanks

Tony


On 10/26/22 8:01 AM, Carter Kozak wrote:
> Continuing a conversation I had with Sean Mullan at Java One, for a 
> broader audience.
> 
> We tend to believe that bulk operations are good. Large bulk operations 
> give the system the most information at once, allowing it to make more 
> informed decisions. Understanding the hotspot compiler on some level and 
> how the security components interact with it, the observed performance 
> degradation makes sense as a result, but I don?t think it?s obvious or 
> desirable most of those using the JDK. As the industry shifts toward 
> shorter lived and horizontally scalable instances, it becomes more 
> important than ever to deliver cryptography performance consistently and 
> early.
> 
> Encryption in Java is usually fast, around 2-3 GiB/second per core using 
> the default OpenJDK JSSE provider on my test system. However, when 
> developers use larger buffers (~10 MiB, perhaps large for 
> networking/TLS, but reasonable for local data), I can observe throughput 
> drop to 60 MiB/second (between 2 and 3 percent of the expected throughput!).
> 
> Results from 
> https://github.com/carterkozak/java-crypto-buffer-performance 
> <https://github.com/carterkozak/java-crypto-buffer-performance>:
> 
> Benchmark (cipher) (numBytes) (writeStrategy) Mode Cnt Score Error Units
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 1048576 ENTIRE_BUFFER 
> thrpt 4 2215.898 ? 185.661 ops/s
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 10485760 ENTIRE_BUFFER 
> thrpt 4 6.427 ? 0.475 ops/s
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 104857600 ENTIRE_BUFFER 
> thrpt 4 0.620 ? 0.096 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 1048576 ENTIRE_BUFFER 
> thrpt 4 2933.808 ? 17.538 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 10485760 ENTIRE_BUFFER 
> thrpt 4 31.775 ? 1.898 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 104857600 ENTIRE_BUFFER 
> thrpt 4 3.174 ? 0.171 ops/s
> 
> 
> Using |AES/GCM/NoPadding|, large buffers result in a great deal of work 
> withinGHASH.processBlocks 
> <https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/java.base/share/classes/com/sun/crypto/provider/GHASH.java#L272-L286>which is intrinsified <https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/hotspot/share/classfile/vmIntrinsics.hpp#L462-L466>, however the intrinsic isn?t used because the method is called infrequently, and a tremendous amount of work occurs within the default implementation. You can find notes from my initial investigation are here (with flame graphs) <https://github.com/palantir/hadoop-crypto/pull/586#issuecomment-964394587>. When I introduce a wrapper to chunk input buffers into 16 KiB segments (other sizes tested here <https://github.com/palantir/hadoop-crypto/pull/586#issue-1047810949>), we can effectively force the method to warm up, and perform nearly two orders of magnitude better:
> 
> https://github.com/carterkozak/java-crypto-buffer-performance#jdk-17 
> <https://github.com/carterkozak/java-crypto-buffer-performance#jdk-17>
> 
> Benchmark (cipher) (numBytes) (writeStrategy) Mode Cnt Score Error Units
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 1048576 ENTIRE_BUFFER 
> thrpt 4 2215.898 ? 185.661 ops/s
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 1048576 CHUNKED thrpt 4 
> 2516.770 ? 193.009 ops/s
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 10485760 ENTIRE_BUFFER 
> thrpt 4 6.427 ? 0.475 ops/s
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 10485760 CHUNKED thrpt 4 
> 246.956 ? 51.193 ops/s
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 104857600 ENTIRE_BUFFER 
> thrpt 4 0.620 ? 0.096 ops/s
> EncryptionBenchmark.encrypt AES/GCM/NoPadding 104857600 CHUNKED thrpt 4 
> 24.633 ? 2.784 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 1048576 ENTIRE_BUFFER 
> thrpt 4 2933.808 ? 17.538 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 1048576 CHUNKED thrpt 4 
> 3277.374 ? 569.573 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 10485760 ENTIRE_BUFFER 
> thrpt 4 31.775 ? 1.898 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 10485760 CHUNKED thrpt 4 
> 332.873 ? 55.589 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 104857600 ENTIRE_BUFFER 
> thrpt 4 3.174 ? 0.171 ops/s
> EncryptionBenchmark.encrypt AES/CTR/NoPadding 104857600 CHUNKED thrpt 4 
> 33.909 ? 1.675 ops/s
> 
> The 10 MiB full-buffer benchmark is eventually partially optimized after 
> ~3 minutes of encryption on ~10 GiB of data, however in practice this 
> takes much longer because the encrypted data must also be put somewhere, 
> potentially leading to rubber-banding over a network.
> 
> While writing this up I re-ran my investigation using JDK-19 
> <https://github.com/carterkozak/java-crypto-buffer-performance#jdk-19> 
> and found, to my surprise, that AES/GCM performed substantially better, 
> warming up quickly, while AES/CTR performance was largely equivalent! It 
> turns out that JDK-8273297 
> <https://bugs.openjdk.org/browse/JDK-8273297>, which aimed to improve 
> performance of an intrinsic, has the side-effect of allowing the 
> intrinsic to be used much faster by segmenting inputs to 1mb chunks 
> <https://github.com/openjdk/jdk/commit/13e9ea9e922030927775345b1abde1313a6ec03f#diff-a533e78f757a3ad64a8d2453bea64a0d426890ef85031452bf74070776ad8be0R575-R596>.
> 
> I?ve intentionally avoided suggesting specific solutions, as a layperson 
> I don?t feel confident making explicit recommendations, but my goal is 
> reliably high throughput based on the amount of work done rather than 
> the size of individual operations. As a user, native implementations 
> like tcnative <https://tomcat.apache.org/native-doc/> and Conscrypt 
> <https://github.com/google/conscrypt> provide the performance 
> characteristics I?m looking for, but without the reliability or 
> flexibility of OpenJDK JSSE. Is there a solution which allows us to get 
> the best of both worlds?
> 
> Thanks,
> Carter Kozak

From joehw at openjdk.org  Thu Oct 27 17:22:26 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Oct 2022 17:22:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From mullan at openjdk.org  Thu Oct 27 17:34:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Oct 2022 17:34:29 GMT
Subject: Integrated: 8293858: Change PKCS7 code to use default SecureRandom
 impl instead of SHA1PRNG
In-Reply-To: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
References: <9G-U92cH9qKt1S5UYXGLWmPc7ZAIkw83De01yBknpS4=.fd47c2ab-b675-4abd-ac11-c01ec0c17baf@github.com>
Message-ID: <gGbQuFPRsOOLWL8YwGOcn2JZf1li1Kw9G-NFZ5dCEI0=.d946428a-cfd0-4aa6-bab9-f326356195ca@github.com>

On Thu, 27 Oct 2022 14:21:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> For timestamp nonces, change the PKCS7 code to use the default SecureRandom PRNG (which varies depending on the OS), instead of SHA1PRNG.

This pull request has now been integrated.

Changeset: 21571457
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2157145766f9789ade0940e9ae1715a3b74d508b
Stats:     23 lines in 1 file changed: 1 ins; 19 del; 3 mod

8293858: Change PKCS7 code to use default SecureRandom impl instead of SHA1PRNG

Reviewed-by: weijun, xuelei

-------------

PR: https://git.openjdk.org/jdk/pull/10883

From dfuchs at openjdk.org  Thu Oct 27 17:38:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 17:38:24 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
Message-ID: <9IeUomzE_jMjeWk2jrzY5-1W8n2JhijVyCPO2mQJrtI=.82a69e23-ccae-43a4-988c-5de54e4aad07@github.com>

On Thu, 27 Oct 2022 17:20:04 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

No problem - I will make this change when we have settled on a name for the variable `tmp` vs `_unused` (proposed by Michael).

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From mullan at openjdk.org  Thu Oct 27 17:46:26 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Oct 2022 17:46:26 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v3]
In-Reply-To: <HiUuGNxlJwtn8CpUChQ2V1t-NsKxpbGeufyiaPpHiyI=.896b054a-ea99-4e65-8ed3-67cc9517e95d@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <HiUuGNxlJwtn8CpUChQ2V1t-NsKxpbGeufyiaPpHiyI=.896b054a-ea99-4e65-8ed3-67cc9517e95d@github.com>
Message-ID: <EfIUBDWVPL6AHT2dcDwNErC4t7ThHW_sJlaa4M-nIuk=.1ca3c22b-035e-46a3-8c5d-8cc1f86e0a7d@github.com>

On Thu, 27 Oct 2022 08:03:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
>> 
>> https://bugs.openjdk.org/browse/JDK-8295343
>> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
>> 
>> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From aturbanov at openjdk.org  Thu Oct 27 17:54:31 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Oct 2022 17:54:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

test/jdk/java/net/URL/URLFromURITest.java line 268:

> 266:             // - URL authority is null or empty depending on the protocol
> 267:             //   and on whether the URL is hierarchical or not.
> 268:             if (isFileBased  && authority == null) {

Suggestion:

            if (isFileBased && authority == null) {

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Thu Oct 27 18:08:34 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 18:08:34 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
Message-ID: <VjAEpSLjpUPyUQcaxoONq7Y6zCqP7glgi8QikqXkakI=.689b7ff2-596a-4a87-ba02-b9c1f1c15c64@github.com>

On Thu, 27 Oct 2022 17:50:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> test/jdk/java/net/URL/URLFromURITest.java line 268:
> 
>> 266:             // - URL authority is null or empty depending on the protocol
>> 267:             //   and on whether the URL is hierarchical or not.
>> 268:             if (isFileBased  && authority == null) {
> 
> Suggestion:
> 
>             if (isFileBased && authority == null) {

Thanks - I will apply this suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From ckozak at ckozak.net  Thu Oct 27 18:14:16 2022
From: ckozak at ckozak.net (Carter Kozak)
Date: Thu, 27 Oct 2022 14:14:16 -0400
Subject: Clogged pipes: 50x throughput degradation with large Cipher writes
In-Reply-To: <2f7c9be7-45d4-0768-513d-dde5324def1b@oracle.com>
References: <16c1a167-7701-403e-b7f6-eb264f6e22d0@app.fastmail.com>
 <2f7c9be7-45d4-0768-513d-dde5324def1b@oracle.com>
Message-ID: <062c06b5-8ff5-40fa-af74-ed9ccd017683@app.fastmail.com>

> CTR doesn't have the same splitting up of the input data to speed the
> triggering of the intrinsic that GCM has. The need to split data is
> such as narrow situation as users don't typically use 1, 10 or 100MB
> data sizes.

In the case of Cipher usage outside of TLS, users may not know that they're interacting with a system that uses cryptography at all. My use-case is a library which stores data into one of several backends, and depending on whether the feature is enabled (based on the level of trust of the systems involved), guarantees that the data is encrypted before it's sent. Users provide a byte-producer along the lines of "interface Content { void writeTo(OutputStream out) throws IOException; }". This interface may be used elsewhere to write unencrypted bytes to a filesystem, for example, but the idea is that it stores arbitrary data. It's entirely reasonable that an implementation may get an InputStream in some way, and invoke inputStream.transferTo(out). In most cases, InputStream.transferTo isn't overridden, and produces nice 8KiB chunks. However, it's also reasonable for the inputstream to be a ByteArrayInputStream in cases where the bytes are readily available, and already buffered on heap. In that case, the 'transferTo' function will invoke a single write including the full content. To be clear, the primary use-case isn't copying from one stream to another. In most cases the caller will transform the input before storing it, which often requires the full contents to be buffered, for instance reading CSV and converting to excel before storing the result.

> Are you using a particular application where you are seeing the
> performance drop off clearly, besides a benchmark?

Yes! The benchmark is the result of investigation into a performance problem in production, where we confirmed our profiling results, implemented a fix, and confirmed the benchmarking improvements were relevant in the original production scenario.

Carter Kozak

From jnimeh at openjdk.org  Thu Oct 27 21:21:33 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 27 Oct 2022 21:21:33 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <SHVra8SjH-iWXZ-s-f4cWtbylOAg8rlGNQc3cVxTFRI=.c2d808b3-e5cb-4131-8c0b-e1c873aa5b3c@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
 <KwT1ejhy7yvVIpMPCpkT2E87-bwwXRvVhZ-fy_Bm8po=.d71506cf-3e0c-4eb8-a008-390ab2ff4e02@github.com>
 <cjsKh51GqdfZ4GnIcniUrJfX7McnzDOz_cSf3BSR4FA=.4181923c-e89d-4e1d-902a-0b390b515472@github.com>
 <SajtNyPTRfsIaMh_o-fFN0Q1HYmehmUl-V5QCWm5jp4=.56a900ad-c725-4577-89d1-8ea860776d88@github.com>
 <SHVra8SjH-iWXZ-s-f4cWtbylOAg8rlGNQc3cVxTFRI=.c2d808b3-e5cb-4131-8c0b-e1c873aa5b3c@github.com>
Message-ID: <ncjUr-Adsj7uaO29FWJ6k0umBrEXfv7fDg0x8cnE6n0=.4dee4a46-c702-44b3-a5bf-187263e9ac2d@github.com>

On Thu, 27 Oct 2022 09:22:03 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> One small thing maybe: It doesn't look like R in `processMultipleBlocks` and `rbytes` ever changes, so maybe there's no need to repeatedly serialize/deserialize them on every call to engineUpdate?  There is already an `r` that is attached to the object that is an IntegerModuloP.  Could that be used in `processMultipleBlocks` and perhaps a private byte[] for a serialized r is also a field in Poly1305 that can be passed into the intrinsic method rather than creating it every time?  It could be set in `setRSVals`.  Perhaps we can recover a little performance there?
>
>> 10% is not a negligible impact. I see your point about AVX512 reaping the rewards of this change, but there are plenty of x86_64 systems without AVX512 that will be impacted, not to mention other platforms like aarch64 which (for this change at least) will never see the benefits from the intrinsic.
>> 
>> I don't have any suggestions right at this moment for how this could be streamlined at all to help reduce the pain for non-AVX512 systems. Worth looking into though.
> 
> Do you suggest using white box APIs for CPU feature query during poly static initialization and perform multi block processing only for relevant platforms and keep the original implementation sacrosanct for other targets. VM does offer native white box primitives and currently its being used by tests infrastructure.

No, going the WhiteBox  route was not something I was thinking of.  I sought feedback from a couple hotspot-knowledgable people about the use of WhiteBox APIs and both felt that it was not the right way to go.  One said that WhiteBox is really for VM testing and not for these kinds of java classes.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Thu Oct 27 22:19:26 2022
From: duke at openjdk.org (Rob Leland)
Date: Thu, 27 Oct 2022 22:19:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <RaFx3blIdoBXwF7RjK7TFIuqHSxTNk9-C94QaPKmEeg=.118063ff-f956-427a-a2f6-a87fc85dc601@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Why not go ahead and replace all the usages with fromURI(} to start  with.where possible ?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From jlaskey at openjdk.org  Thu Oct 27 22:27:47 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Oct 2022 22:27:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview)
Message-ID: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>

Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

-------------

Commit messages:
 - Tabs to spaces
 - Force processor before template string expression
 - Correct implNote
 - Add valueGetters method
 - Added RAW template processor
 - Merge branch 'master' into 8285932
 - Rename to ValidatingProcessor
 - Javadoc mistakes
 - Rename TemplateProcessor
 - Clean up tests
 - ... and 4 more: https://git.openjdk.org/jdk/compare/0c13d666...7b2011ac

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285932
  Stats: 7452 lines in 74 files changed: 7263 ins; 45 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Thu Oct 27 22:47:26 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 22:47:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:

> 113:      * we do not use all those slots, to let the strategies with MethodHandle
> 114:      * combinators to use some arguments.
> 115:      */

Suggestion:

     *
     * @since 20
     */

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:

> 1056:          * @throws Throwable if fails to prepend value (unusual).
> 1057:          */
> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;

This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.

--------------------------------------------------------------------------------

The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From xuelei at openjdk.org  Thu Oct 27 23:44:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 27 Oct 2022 23:44:19 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
Message-ID: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>

Hi,

May I have this update reviewed?

The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.

The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**

## SSLHandshake.java benchmark
### Use secp256r1 as the named group
The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:

Benchmark with this patch:

Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s


Benchmark before this patch applied:

Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s


Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.

**When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**

### Use default TLS named groups
The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 

Benchmark with this patch:

Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s


Benchmark before this patch applied:

Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s


Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.

**When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**

## KeyPairGenerators.java benchmark
The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.

Benchmark with this patch:

Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s


Benchmark before this patch applied:

Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s


**Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

## Signatures.java benchmark
The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.

Benchmark with this patch:

Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s



Benchmark before this patch applied:

Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s


**Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

-------------

Commit messages:
 - Merge
 - add test and missed files
 - 8295011: EC point multiplication improvement for secp256r1

Changes: https://git.openjdk.org/jdk/pull/10893/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295011
  Stats: 522 lines in 5 files changed: 436 ins; 82 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10893.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10893/head:pull/10893

PR: https://git.openjdk.org/jdk/pull/10893

From xuelei at openjdk.org  Thu Oct 27 23:44:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 27 Oct 2022 23:44:19 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <9k9Z5yevU8YPZUi8Rf6B1FEPmTNIxH41jA7ByzUDoAE=.9a38f334-91a7-4a82-8a17-8f3e0800f319@github.com>

On Thu, 27 Oct 2022 22:10:15 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
> 
> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
> 
> ## SSLHandshake.java benchmark
> ### Use secp256r1 as the named group
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
> 
> ### Use default TLS named groups
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
> 
> ## KeyPairGenerators.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
> 
> 
> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
> 
> ## Signatures.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
> 
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
> 
> 
> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

test/micro/org/openjdk/bench/java/security/SSLHandshake.java line 80:

> 78:     @Setup(Level.Trial)
> 79:     public void init() throws Exception {
> 80:         // System.setProperty("jdk.tls.namedGroups", "secp256r1");

This update will be removed in a next update.

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From cjplummer at openjdk.org  Fri Oct 28 00:55:44 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Oct 2022 00:55:44 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
Message-ID: <DIScQIcbKFsercPkoaABYXSmJznKrSSnJwhL-kJDSDU=.5be8456a-ce87-4b56-83f9-b397e2785402@github.com>

On Fri, 7 Oct 2022 12:51:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> src/java.se/share/data/jdwp/jdwp.spec line 101:
> 
>> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
>> 100:         "in the target VM. This includes platform threads created with the Thread "
>> 101:         "API and all native threads attached to the target VM with JNI code."
> 
> The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

Since this PR has gone stale, I'll be fixing this typo in jdwp.spec via [JDK-8294672](https://bugs.openjdk.org/browse/JDK-8294672).

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From mbaesken at openjdk.org  Fri Oct 28 07:07:08 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Oct 2022 07:07:08 GMT
Subject: RFR: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests [v3]
In-Reply-To: <HiUuGNxlJwtn8CpUChQ2V1t-NsKxpbGeufyiaPpHiyI=.896b054a-ea99-4e65-8ed3-67cc9517e95d@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
 <HiUuGNxlJwtn8CpUChQ2V1t-NsKxpbGeufyiaPpHiyI=.896b054a-ea99-4e65-8ed3-67cc9517e95d@github.com>
Message-ID: <7tzmevyry87al6pQjL3P3gV0jEplZakaOhtoNPQQno0=.508479fb-16fa-4b4d-8eed-ae7a8c0488e6@github.com>

On Thu, 27 Oct 2022 08:03:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
>> 
>> https://bugs.openjdk.org/browse/JDK-8295343
>> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
>> 
>> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

Hi Martin and Sean, thanks for the reviews !

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From mbaesken at openjdk.org  Fri Oct 28 07:07:09 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Oct 2022 07:07:09 GMT
Subject: Integrated: JDK-8295405 : Add cause in a couple of
 IllegalArgumentException and InvalidParameterException shown by
 sun/security/pkcs11 tests
In-Reply-To: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
References: <imSKFXmnh7oE3vnuZHf_0hy-g9042WZnQ-_vYjkWlOw=.30068ce0-d5b9-43bf-b136-40cfeb6c772e@github.com>
Message-ID: <zY42HZse8ME7TZoa3RvKeEgwI1OdJdTy_aEaIYaVVlc=.0dd60768-f473-4caf-b3eb-93db4c475913@github.com>

On Mon, 17 Oct 2022 10:42:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
> 
> https://bugs.openjdk.org/browse/JDK-8295343
> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
> 
> The exceptions generated by these tests sometimes miss the cause (causing exception), it would be nice to have this added to get the complete exception backtrace.

This pull request has now been integrated.

Changeset: d5d34241
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5d34241e21305379f1858556f225e7645cd294e
Stats:     24 lines in 7 files changed: 8 ins; 0 del; 16 mod

8295405: Add cause in a couple of IllegalArgumentException and InvalidParameterException shown by sun/security/pkcs11 tests

Reviewed-by: mdoerr, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/10726

From djelinski at openjdk.org  Fri Oct 28 10:34:27 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 28 Oct 2022 10:34:27 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <C2qMC1uj1m8abXZsPAHRxpqFHM39sN_hIf6D2Nkuzko=.8a193705-285d-4de4-a56f-5b2cda7da212@github.com>

On Thu, 27 Oct 2022 22:10:15 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
> 
> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
> 
> ## SSLHandshake.java benchmark
> ### Use secp256r1 as the named group
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
> 
> ### Use default TLS named groups
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
> 
> ## KeyPairGenerators.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
> 
> 
> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
> 
> ## Signatures.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
> 
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
> 
> 
> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

Very nice improvement!

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 209:

> 207:     }
> 208: 
> 209:     public MutablePoint multiply(ECPoint ecPoint, byte[] s) {

Unused

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 414:

> 412: 
> 413:     static final class Secp256R1Ops extends ECOperations {
> 414:         private static final ECOperations instance = new Secp256R1Ops();

I'd make it an instance field in ECOperations and drop this class

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 437:

> 435:         }
> 436: 
> 437:         static PointMultiplier of(ECOperations ecOps, ECPoint ecPoint) {

Unused

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 538:

> 536:         }
> 537: 
> 538:         final class Secp256R1 implements PointMultiplier {

Given that this class can only multiply the generator of SecP256R1, maybe rename it to something like Secp256R1GeneratorMultiplier?

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 547:

> 545: 
> 546:             @Override
> 547:             public ProjectivePoint.Mutable pointMultiply(byte[] s) {

This method (or class) should really have a comment describing what it does

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 628:

> 626:                             ProjectivePoint.Mutable m =
> 627:                                     multiplier.pointMultiply(s);
> 628:                             points[d][w] = m.setValue(m.asAffine()).fixed();

Did you try using AffinePoints instead of ProjectivePoints? Sum with AffinePoints is supposed to be a bit faster, wonder if the improvement is worthwhile.

Also, unless you switch to affine points, just use `m.fixed()`.

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 634:

> 632: 
> 633:                 // Check that the tables are correctly generated.
> 634:                 for (int d = 0; d < 4; d++) {

Since this part of code is for runtime verification only, maybe guard it with something like:
`if (ECOperations.class.desiredAssertionStatus())`
this way it will only execute if assertions are enabled

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From weijun at openjdk.org  Fri Oct 28 13:41:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Oct 2022 13:41:27 GMT
Subject: RFR: 8295953: Use enhanced-for cycle instead of Enumeration in
 sun.security
In-Reply-To: <N-bQ5FdBX42mOCwt9TikxXOO25NsrgwuMiHDCpa5eyg=.ca9865ca-467a-433d-9e70-0b376df2b15b@github.com>
References: <N-bQ5FdBX42mOCwt9TikxXOO25NsrgwuMiHDCpa5eyg=.ca9865ca-467a-433d-9e70-0b376df2b15b@github.com>
Message-ID: <igOfZAECxCLR4eHgWngWc44XIgT-EqjVygYzZWlTYFs=.531e1b76-6c98-4e0e-8733-75b2172ab7a5@github.com>

On Mon, 17 Oct 2022 21:50:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> java.util.Enumeration is a legacy interface from java 1.0.
> There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

LGTM.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10734

From dfuchs at openjdk.org  Fri Oct 28 14:54:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Oct 2022 14:54:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Daniel Fuchs 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 four additional commits since the last revision:

 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/25a0188c..fd4ca287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00-01

  Stats: 25761 lines in 392 files changed: 1581 ins; 23649 del; 531 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

PR: https://git.openjdk.org/jdk/pull/10874

From jlaskey at openjdk.org  Fri Oct 28 14:55:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Move StringConcatItem to FormatConcatItem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/7b2011ac..26485968

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00-01

  Stats: 239 lines in 6 files changed: 93 ins; 109 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 14:55:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
Message-ID: <8KVfwqrbnCSF-80frLIKExvp7jih3Ltp-UY3eaHuTco=.2f87479c-39d9-4eda-87f4-832b6ac8b9cb@github.com>

On Thu, 27 Oct 2022 21:21:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:
> 
>> 113:      * we do not use all those slots, to let the strategies with MethodHandle
>> 114:      * combinators to use some arguments.
>> 115:      */
> 
> Suggestion:
> 
>      *
>      * @since 20
>      */

Updated along with a couple @since 19

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:
> 
>> 1056:          * @throws Throwable if fails to prepend value (unusual).
>> 1057:          */
>> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;
> 
> This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.
> 
> --------------------------------------------------------------------------------
> 
> The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

Went the sealed class route. Unfortunately, the permitted classes are all package private otherwise I would have moved to an internal package.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 16:12:50 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 16:12:50 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:

> 363:         Objects.requireNonNull(sts, "sts must not be null");
> 364:         if (sts.length == 0) {
> 365:             StringTemplate.of("");

Missing return?

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:

> 365:             StringTemplate.of("");
> 366:         } else if (sts.length == 1) {
> 367:             return sts[0];

Check for null?

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From joehw at openjdk.org  Fri Oct 28 16:43:23 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Oct 2022 16:43:23 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <4ThJRTvihtvhX_xBjaCTHOL4w-VHDJuXTUkvtfRVPvY=.ad69332e-e7a2-43fc-9893-3a27f7ca4d5c@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs 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 four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Thanks Daniel. The java.xml part looks good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10874

From mullan at openjdk.org  Fri Oct 28 17:11:28 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 28 Oct 2022 17:11:28 GMT
Subject: RFR: 8256660: Disable DTLS 1.0
Message-ID: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>

Disable DTLS 1.0 by default. This version of DTLS has weakened over time and lacks support for stronger cipher suites. DTLS 1.0 correlates with version 1.1 of TLS which has already been disabled by default in JDK 16. The IETF has deprecated this version of DTLS (along with TLS 1.0 and 1.1) in RFC 8996: https://www.rfc-editor.org/rfc/rfc8996.html.

CSR: https://bugs.openjdk.org/browse/JDK-8280507

-------------

Commit messages:
 - More test changes.
 - Merge
 - Merge branch 'master' into JDK-8256660
 - Fix code so that DTLSv1.0 is removed from the enabled list of
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/10905/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8256660
  Stats: 56 lines in 3 files changed: 27 ins; 5 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/10905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10905/head:pull/10905

PR: https://git.openjdk.org/jdk/pull/10905

From xuelei at openjdk.org  Fri Oct 28 17:31:26 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 28 Oct 2022 17:31:26 GMT
Subject: RFR: 8256660: Disable DTLS 1.0
In-Reply-To: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
References: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
Message-ID: <wU3HktWRSiTuHrDhA_MeieqFd5kBlWXOkOfwkzw9zws=.81b42e44-e80d-4fac-8d4b-34fa3ecd29f8@github.com>

On Fri, 28 Oct 2022 17:00:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Disable DTLS 1.0 by default. This version of DTLS has weakened over time and lacks support for stronger cipher suites. DTLS 1.0 correlates with version 1.1 of TLS which has already been disabled by default in JDK 16. The IETF has deprecated this version of DTLS (along with TLS 1.0 and 1.1) in RFC 8996: https://www.rfc-editor.org/rfc/rfc8996.html.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8280507

Looks good to me.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10905

From jlaskey at openjdk.org  Fri Oct 28 17:57:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 17:57:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update TemplateRuntime::combine

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/26485968..20f54dec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From xuelei at openjdk.org  Fri Oct 28 18:00:55 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 28 Oct 2022 18:00:55 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v2]
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <MZQHmMp6y8dTD_rkMrzXWH5YZ5KFHgQRcH1x6Cm8f_g=.4c8934ee-0937-4112-a78e-49495bb66d01@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
> 
> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
> 
> ## SSLHandshake.java benchmark
> ### Use secp256r1 as the named group
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
> 
> ### Use default TLS named groups
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
> 
> ## KeyPairGenerators.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
> 
> 
> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
> 
> ## Signatures.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
> 
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
> 
> 
> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  add missed update to use ECPoint directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10893/files
  - new: https://git.openjdk.org/jdk/pull/10893/files/99f3f130..c644b6be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10893&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10893&range=00-01

  Stats: 156 lines in 5 files changed: 49 ins; 29 del; 78 mod
  Patch: https://git.openjdk.org/jdk/pull/10893.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10893/head:pull/10893

PR: https://git.openjdk.org/jdk/pull/10893

From xuelei at openjdk.org  Fri Oct 28 18:01:03 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 28 Oct 2022 18:01:03 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v2]
In-Reply-To: <C2qMC1uj1m8abXZsPAHRxpqFHM39sN_hIf6D2Nkuzko=.8a193705-285d-4de4-a56f-5b2cda7da212@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <C2qMC1uj1m8abXZsPAHRxpqFHM39sN_hIf6D2Nkuzko=.8a193705-285d-4de4-a56f-5b2cda7da212@github.com>
Message-ID: <oVNznPr2qo1Dyc8_44VDAvKJULkij_QuVWgq_VdmvN0=.4fa73e25-1cbd-4017-89d6-36e5c2c9c998@github.com>

On Fri, 28 Oct 2022 09:53:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missed update to use ECPoint directly
>
> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 209:
> 
>> 207:     }
>> 208: 
>> 209:     public MutablePoint multiply(ECPoint ecPoint, byte[] s) {
> 
> Unused

Ooops, I missed a few update in the commit.  This is used to remove unnecessary conversion from ECPoint to AffinePoint in the caller side.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 414:
> 
>> 412: 
>> 413:     static final class Secp256R1Ops extends ECOperations {
>> 414:         private static final ECOperations instance = new Secp256R1Ops();
> 
> I'd make it an instance field in ECOperations and drop this class

Hm, it looks like a better choice.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 437:
> 
>> 435:         }
>> 436: 
>> 437:         static PointMultiplier of(ECOperations ecOps, ECPoint ecPoint) {
> 
> Unused

Hm, the code that use this method will be added.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 538:
> 
>> 536:         }
>> 537: 
>> 538:         final class Secp256R1 implements PointMultiplier {
> 
> Given that this class can only multiply the generator of SecP256R1, maybe rename it to something like Secp256R1GeneratorMultiplier?

Good point.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 547:
> 
>> 545: 
>> 546:             @Override
>> 547:             public ProjectivePoint.Mutable pointMultiply(byte[] s) {
> 
> This method (or class) should really have a comment describing what it does

Yes.  I added comment in the interface method.

> Did you try using AffinePoints instead of ProjectivePoints?

Yes.  See [JDK-8295763](https://bugs.openjdk.org/browse/JDK-8295763).  Unfortunately, the mixed point addition formulas used in JDK implementation does not support additional of neutral point. It may be doable again if the formulas get changed in the future.

> Also, unless you switch to affine points, just use m.fixed().

Yes, the change to AffinePoints is mainly for checking in the following block.  BTW, the class loading is slow, hard-coded tables should be used in a coming update very soon.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 634:
> 
>> 632: 
>> 633:                 // Check that the tables are correctly generated.
>> 634:                 for (int d = 0; d < 4; d++) {
> 
> Since this part of code is for runtime verification only, maybe guard it with something like:
> `if (ECOperations.class.desiredAssertionStatus())`
> this way it will only execute if assertions are enabled

Good point.

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From jlaskey at openjdk.org  Fri Oct 28 18:01:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 18:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
Message-ID: <HhGc5V1_nIfnkwUhoR0KXdaqK12XDy4UdCwfQpYIHoM=.07435759-8a04-4f58-b244-30d81576cc56@github.com>

On Fri, 28 Oct 2022 16:09:51 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:
> 
>> 363:         Objects.requireNonNull(sts, "sts must not be null");
>> 364:         if (sts.length == 0) {
>> 365:             StringTemplate.of("");
> 
> Missing return?

Yep - updated

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:
> 
>> 365:             StringTemplate.of("");
>> 366:         } else if (sts.length == 1) {
>> 367:             return sts[0];
> 
> Check for null?

Added null checks

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From xuelei at openjdk.org  Fri Oct 28 18:05:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 28 Oct 2022 18:05:30 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
> 
> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
> 
> ## SSLHandshake.java benchmark
> ### Use secp256r1 as the named group
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
> 
> ### Use default TLS named groups
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
> 
> ## KeyPairGenerators.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
> 
> 
> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
> 
> ## Signatures.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
> 
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
> 
> 
> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  remove tailing whitespaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10893/files
  - new: https://git.openjdk.org/jdk/pull/10893/files/c644b6be..aa224efc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10893&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10893&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10893.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10893/head:pull/10893

PR: https://git.openjdk.org/jdk/pull/10893

From weijun at openjdk.org  Fri Oct 28 18:29:15 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Oct 2022 18:29:15 GMT
Subject: RFR: 8296072: CertAttrSet::encode should write into DerOutputStream
Message-ID: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>

The argument of the `CertAttrSet::encode` interface method is modified from `OutputStream` to `DerOutputStream`. All its implementations are modified the same way.

`OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.

In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/10906/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296072
  Stats: 198 lines in 36 files changed: 8 ins; 100 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/10906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10906/head:pull/10906

PR: https://git.openjdk.org/jdk/pull/10906

From mcimadamore at openjdk.org  Fri Oct 28 18:38:20 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <qXjmvDvCAAHmElOuzn4nEUEG3d9bBXRHzmJJZHpGt1o=.9d9eb47e-e661-468b-b1ef-658b3d62cf25@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

Added some comments - will probably have some more at a later point

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:26 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:

> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");

Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:

> 104:     private final Attr attr;
> 105:     private final Symtab syms;
> 106:     private final Types types;

Why this change?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:

> 4972:         if (processor != null) {
> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);

It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:

> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
> 4138: 
> 4139:             if (typeArguments.size() == 2) {

Is this code correct? TemplateProcessor seems to have just one type argument.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1:

> 1: /*

This file shouldn't be here

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:

> 346:                 try {
> 347:                     chk.disablePreviewCheck = true;
> 348:                     String autoImports = """

I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.

What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.

As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:27 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>

On Fri, 28 Oct 2022 16:09:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
> 
>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>> 4138: 
>> 4139:             if (typeArguments.size() == 2) {
> 
> Is this code correct? TemplateProcessor seems to have just one type argument.

Ah - `templateProcessorType` is not what it seems :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From hchao at openjdk.org  Fri Oct 28 18:49:22 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 28 Oct 2022 18:49:22 GMT
Subject: RFR: 8256660: Disable DTLS 1.0
In-Reply-To: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
References: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
Message-ID: <uDmuGBndnkknaKK_vOf-woGrbBDvK2r34vR4xcIro_M=.4a86d669-244d-4c1d-97a8-974e10331c59@github.com>

On Fri, 28 Oct 2022 17:00:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Disable DTLS 1.0 by default. This version of DTLS has weakened over time and lacks support for stronger cipher suites. DTLS 1.0 correlates with version 1.1 of TLS which has already been disabled by default in JDK 16. The IETF has deprecated this version of DTLS (along with TLS 1.0 and 1.1) in RFC 8996: https://www.rfc-editor.org/rfc/rfc8996.html.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8280507

Marked as reviewed by hchao (Committer).

Looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/10905

From forax at openjdk.org  Fri Oct 28 18:50:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 18:50:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:

> 30: 
> 31: import java.io.IOException;
> 32: import java.util.*;

Please do not use import *.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:

> 34: import java.lang.invoke.MethodHandles.Lookup;
> 35: import java.lang.template.StringTemplate;
> 36: import java.util.*;

Another import * here

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:

> 116:      * @since 20
> 117:      */
> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;

I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:

> 997:      * Promote integral types to int.
> 998:      */
> 999:     private static Class<?> promoteIntType(Class<?> t) {

promoteToIntType ?

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:02:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:02:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:

> 1040:      * The number of fragments must be one more that the number of ptypes.
> 1041:      * The total number of slots used by the ptypes must be less than or equal
> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.

see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:

> 1058:             throws StringConcatException
> 1059:     {
> 1060:         Objects.requireNonNull(fragments, "fragments is null");

I think you need to do some defensive copy here

  ptypes = List.copyOf(pTypes);

to avoid the types and fragments to be changed at the same time they are checked.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:

> 1175:      */
> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(

I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:

> 49:     /**
> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
> 51:      * bootstrap method information.

This comment is quite obscure if you have no idea how it works.
And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:

> 36: record SimpleStringTemplate(List<String> fragments,
> 37:                              List<Object> values
> 38: ) implements StringTemplate {}

A compact constructor doing defensive copies is missing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:11:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:11:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:

> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 44: @FunctionalInterface
> 45: public interface StringProcessor extends TemplateProcessor<String> {}

The name should be `StringTemplateProcessor`.
And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:

> 27: 
> 28: import java.lang.invoke.MethodHandle;
> 29: import java.util.*;

Please fix.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:

> 147:      * {@return the interpolation of the StringTemplate}
> 148:      */
> 149:     default String interpolate() {

I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:

> 173:      * method {@code processor.process(this)}.
> 174:      */
> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {

signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:

> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
> 203:      */
> 204:     default public List<MethodHandle> valueGetters() {

I think i prefer the term accessors instead of getters

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:31:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:31:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:

> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
> 306:         }
> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));

I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().

src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:

> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 322:      */
> 323:     public static String interpolate(List<String> fragments, List<Object> values) {

This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:

> 352:      * @implNote The result of interpolation is not interned.
> 353:      */
> 354:     public static final StringProcessor STR = st -> st.interpolate();

Should be `StringTemplate::interpolate`.

src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:

> 36:  * that do not throw checked exceptions. For example:
> 37:  * {@snippet :
> 38:  * TemplateProcessor<String> processor = st -> {

This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:

> 43:  */
> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 45: public final class TemplateRuntime {

Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:

> 63:      * @throws Throwable            if linkage fails
> 64:      */
> 65:     public static CallSite stringTemplateBSM(

I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:

> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();

`ValidatingProcessor<?, ?>` should be enough ? No ?
Not using a "? extends Throwable" here make the type unchecked.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:

> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
> 87:      */
> 88:     private static class TemplateBootstrap {

This class should be `final`

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:

> 115:          * Static final processor.
> 116:          */
> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;

Use `ValidatingProcessor<?, ?>` here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:

> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
> 144:                                   List<String> fragments,
> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {

Use ValidatingProcessor<?, ?> here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:

> 209:     @SuppressWarnings("unchecked")
> 210:     public static <E> List<E> toList(E... elements) {
> 211:         return Collections.unmodifiableList(Arrays.asList(elements));

This is List.of(), please use List.of() instead

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:31:37 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@github.com>

On Fri, 28 Oct 2022 16:33:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:
> 
>> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
>> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
>> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");
> 
> Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

Renaming.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:
> 
>> 104:     private final Attr attr;
>> 105:     private final Symtab syms;
>> 106:     private final Types types;
> 
> Why this change?

Renaming. Was residual to some context based typing (StringTemplate vs String) Jan and I experimented with.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:
> 
>> 4972:         if (processor != null) {
>> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
>> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);
> 
> It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

Not sure where you get `StringTemplate`.  If you specify `TemplateProcessor<String>` the `resultType` will be `String`.  For example:


public class Processor implements TemplateProcessor<String> {
    @Override
    public String process(StringTemplate st) {
        return st.interpolate();
    }
}

and

public class Main {
    public static void main(String... args) throws Throwable {
        Processor processor = new Processor();
        System.out.println(processor."1234");
    }
}

works with "1234" as a result.

If you later change to


public class Processor implements TemplateProcessor<Integer> {
    @Override
    public Integer process(StringTemplate st) {
        return Integer.valueOf(st.interpolate());
    }
}


Then you get a `java.lang.ClassCastException` as you would expect.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1:
> 
>> 1: /*
> 
> This file shouldn't be here

oops - We should change the `.gitignore` to include `.orig` and `.rej`

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:
> 
>> 346:                 try {
>> 347:                     chk.disablePreviewCheck = true;
>> 348:                     String autoImports = """
> 
> I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.
> 
> What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.
> 
> As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

This was recommended by Jan and the procedure used in other parts of the code.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:31:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
 <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
Message-ID: <Bk1GNLr8K1rN6d6Puz8wVQKeOEUaWvVeK7jiM7wICTY=.fb15a02b-82ec-4c08-9e17-233dfa4fee79@github.com>

On Fri, 28 Oct 2022 16:33:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
>> 
>>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>>> 4138: 
>>> 4139:             if (typeArguments.size() == 2) {
>> 
>> Is this code correct? TemplateProcessor seems to have just one type argument.
>
> Ah - `templateProcessorType` is not what it seems :-)

Renaming. I held off assuming that bike shedding would change it once again.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:41:33 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:41:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
Message-ID: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>

On Fri, 28 Oct 2022 18:45:05 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:
> 
>> 30: 
>> 31: import java.io.IOException;
>> 32: import java.util.*;
> 
> Please do not use import *.

Changing.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:
> 
>> 34: import java.lang.invoke.MethodHandles.Lookup;
>> 35: import java.lang.template.StringTemplate;
>> 36: import java.util.*;
> 
> Another import * here

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
> 
>> 116:      * @since 20
>> 117:      */
>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
> 
> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:
> 
>> 997:      * Promote integral types to int.
>> 998:      */
>> 999:     private static Class<?> promoteIntType(Class<?> t) {
> 
> promoteToIntType ?

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:
> 
>> 1058:             throws StringConcatException
>> 1059:     {
>> 1060:         Objects.requireNonNull(fragments, "fragments is null");
> 
> I think you need to do some defensive copy here
> 
>   ptypes = List.copyOf(pTypes);
> 
> to avoid the types and fragments to be changed at the same time they are checked.

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:41:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:41:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:

> 287:         try {
> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",

This should be a constant (using the class holder idiom or not)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:

> 300: 
> 301:     /**
> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}

Private "method"

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:

> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 324:      */
> 325:     static String interpolate(List<String> fragments, List<Object> values) {

I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:

> 387:             }
> 388:         }
> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));

It seems that IntelliJ was lot when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:51:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove .orig file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/20f54dec..347df715

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02-03

  Stats: 4223 lines in 1 file changed: 0 ins; 4223 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:51:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/util/FormatProcessor.java line 198:

> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
> 197:      */
> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);

`Locale.US` or `Locale.ROOT` ??
see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 19:52:03 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 19:52:03 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>
Message-ID: <T_pU0eAoFldEh9BE4pHU2pAGfLpot70nrKyVJR2_ZKI=.647f346e-e7f9-4ef2-a606-1148f424699f@github.com>

On Thu, 27 Oct 2022 05:10:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extra whitespace character
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 175:
> 
>> 173:             // Choice of 1024 is arbitrary, need enough data blocks to amortize conversion overhead
>> 174:             // and not affect platforms without intrinsic support
>> 175:             int blockMultipleLength = (len/BLOCK_LENGTH) * BLOCK_LENGTH;
> 
> Since Poly processes 16 byte chunks, a strength reduced version of above expression could be len & (~(BLOCK_LEN-1)

I guess I got no issue with either version.. I was mostly thinking about code clarity? I think your version is 'more reliable' so just gonna switch it, thanks.

> test/micro/org/openjdk/bench/javax/crypto/full/Poly1305DigestBench.java line 94:
> 
>> 92:             throw new RuntimeException(ex);
>> 93:         }
>> 94:     }
> 
> On CLX patch shows performance regression of about 10% for block size 1024-2048+.
> 
> CLX (Non-IFMA target)
> 
> Baseline (JDK-20):-
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score   Error  Units
> Poly1305DigestBench.digest          64              thrpt    2  3128928.978          ops/s
> Poly1305DigestBench.digest         256              thrpt    2  1526452.083          ops/s
> Poly1305DigestBench.digest        1024              thrpt    2   509267.401          ops/s
> Poly1305DigestBench.digest        2048              thrpt    2   305784.922          ops/s
> Poly1305DigestBench.digest        4096              thrpt    2   142175.885          ops/s
> Poly1305DigestBench.digest        8192              thrpt    2    72142.906          ops/s
> Poly1305DigestBench.digest       16384              thrpt    2    36357.000          ops/s
> Poly1305DigestBench.digest     1048576              thrpt    2      676.142          ops/s
> 
> 
> Withopt:
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score   Error  Units
> Poly1305DigestBench.digest          64              thrpt    2  3136204.416          ops/s
> Poly1305DigestBench.digest         256              thrpt    2  1683221.124          ops/s
> Poly1305DigestBench.digest        1024              thrpt    2   457432.172          ops/s
> Poly1305DigestBench.digest        2048              thrpt    2   277563.817          ops/s
> Poly1305DigestBench.digest        4096              thrpt    2   149393.357          ops/s
> Poly1305DigestBench.digest        8192              thrpt    2    79463.734          ops/s
> Poly1305DigestBench.digest       16384              thrpt    2    41083.730          ops/s
> Poly1305DigestBench.digest     1048576              thrpt    2      705.419          ops/s

Odd, I measured it on `11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz`, will go again

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From forax at openjdk.org  Fri Oct 28 19:55:07 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:55:07 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
Message-ID: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>

On Fri, 28 Oct 2022 19:34:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
>> 
>>> 116:      * @since 20
>>> 117:      */
>>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
>> 
>> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.
>
> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 20:01:29 2022
From: duke at openjdk.org (Franz =?UTF-8?B?V2lsaGVsbXN0w7Z0dGVy?=)
Date: Fri, 28 Oct 2022 20:01:29 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>

On Fri, 28 Oct 2022 19:21:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
> 
>> 209:     @SuppressWarnings("unchecked")
>> 210:     public static <E> List<E> toList(E... elements) {
>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
> 
> This is List.of(), please use List.of() instead

`List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:

public static <E> List<E> toList(E... elements) {
	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
}

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:01:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
Message-ID: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>

On Fri, 28 Oct 2022 19:51:21 GMT, Franz Wilhelmst?tter <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
>> 
>>> 209:     @SuppressWarnings("unchecked")
>>> 210:     public static <E> List<E> toList(E... elements) {
>>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
>> 
>> This is List.of(), please use List.of() instead
>
> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
> 
> public static <E> List<E> toList(E... elements) {
> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
> }

Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
Using that implementation will avoid a bunch of indirection

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 20:23:41 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 20:23:41 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>
Message-ID: <Cju0XRYyqdeVeZZEpttxF9eUX02aQ0UM3CfD5uIe0OI=.6057ecb9-c80f-4eef-8aae-9f8748bc8f6c@github.com>

On Thu, 27 Oct 2022 09:33:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extra whitespace character
>
> src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 849:
> 
>> 847:   jcc(Assembler::less, L_process16Loop);
>> 848: 
>> 849:   poly1305_process_blocks_avx512(input, length,
> 
> Since entire code is based on 512 bit encoding misalignment penalty may be costly here. A scalar peel handling (as done in tail) for input portion before a 64 byte aligned address  could further improve the performance for large block sizes.

Hmm.. interesting. Is this for loading? `evmovdquq` vs `evmovdqaq`? I was actually looking at using evmovdqaq but there is no encoding for it yet (And just looking now on uops.info, they seem to have identical timings? perhaps their measurements are off..). There are quite a few optimizations I tried (and removed) here, but not this one..

Perhaps to have a record, while its relatively fresh in my mind.. since there is a 8-block (I deleted a 16-block vector multiply), one can have a peeled off version for just 256 as the minimum payload.. In that case we only need R^1..R^8, (not R^1..R^16). I also tried loop stride of 8 blocks instead of 16, but that gets quite bit slower (20ish%?).. There was also a version that did a much better interleaving of multiplication and loading of next message block into limbs.. There is potentially a better way to 'devolve' the vector loop at tail; ie. when 15-blocks are left, just do one more 8-block multiply, all the constants are already available..

I removed all of those eventually. Even then, the assembler code currently is already fairly complex. The extra pre-, post-processing and if cases, I was struggling to keep up myself. Maybe code cleanup would have helped, so it _is_ possible to bring some of that back in for extra 10+%? (There is a branch on my fork with that code)

I guess that's my long way of saying 'I don't want to complicate the assembler loop'?

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From forax at openjdk.org  Fri Oct 28 20:25:35 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
 <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
Message-ID: <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>

On Fri, 28 Oct 2022 19:52:14 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.
>
> But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

Anyway, i think you are right, this can be public

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 20:25:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
Message-ID: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>

On Fri, 28 Oct 2022 18:52:28 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
> 
>> 1040:      * The number of fragments must be one more that the number of ptypes.
>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
> 
> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

Disagree.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
> 
>> 1175:      */
>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
> 
> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:
> 
>> 49:     /**
>> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
>> 51:      * bootstrap method information.
> 
> This comment is quite obscure if you have no idea how it works.
> And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

Deliberate obscure for preview. Once we sort out the functional space you have been looking for, this will likely go away. ProcessorFactory and ProcessorBuilder are a couple of the possibilities.

> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
> 
>> 36: record SimpleStringTemplate(List<String> fragments,
>> 37:                              List<Object> values
>> 38: ) implements StringTemplate {}
> 
> A compact constructor doing defensive copies is missing

The defensive copies are done by the callers.

> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
> 
>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 44: @FunctionalInterface
>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
> 
> The name should be `StringTemplateProcessor`.
> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
> 
> see TemplateProcessor

Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:25:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
Message-ID: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>

On Fri, 28 Oct 2022 20:01:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
>> 
>>> 1040:      * The number of fragments must be one more that the number of ptypes.
>>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
>> 
>> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public
>
> Disagree.

As i said above, i consider this thread as resolved

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
>> 
>>> 1175:      */
>>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
>> 
>> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not
>
> Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

yes, sorry for the noise.

>> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
>> 
>>> 36: record SimpleStringTemplate(List<String> fragments,
>>> 37:                              List<Object> values
>>> 38: ) implements StringTemplate {}
>> 
>> A compact constructor doing defensive copies is missing
>
> The defensive copies are done by the callers.

In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

>> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
>> 
>>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 44: @FunctionalInterface
>>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
>> 
>> The name should be `StringTemplateProcessor`.
>> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
>> 
>> see TemplateProcessor
>
> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?

People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 20:39:44 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 20:39:44 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>

> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
> 
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
> - Added a JMH perf test.
>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
> 
> Perf before:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ? 110554.162  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ?  86696.037  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ?  14074.655  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ?    390.921  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ?      1.402  ops/s
> 
> and after:
> 
> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ? 154528.057  ops/s
> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ?  95253.445  ops/s
> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ? 100847.766  ops/s
> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ?  25883.825  ops/s
> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ?     56.147  ops/s

vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:

  invalidkeyexception and some review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/883be106..78fd8fd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=04-05

  Stats: 33 lines in 7 files changed: 5 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/10582.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10582/head:pull/10582

PR: https://git.openjdk.org/jdk/pull/10582

From weijun at openjdk.org  Fri Oct 28 20:56:58 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Oct 2022 20:56:58 GMT
Subject: RFR: 8296072: CertAttrSet::encode should write into
 DerOutputStream [v2]
In-Reply-To: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
Message-ID: <nKGuJKvB_cE1K6xf3njoDfVK5m8Pns7YA8p6blqqnNU=.6ff3bcff-f769-416b-8fb4-8da423ae0830@github.com>

> The argument of the `CertAttrSet::encode` interface method is modified from `OutputStream` to `DerOutputStream`. All its implementations are modified the same way.
> 
> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
> 
> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  @Override, used imports, copyright years, and a test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10906/files
  - new: https://git.openjdk.org/jdk/pull/10906/files/237dc8dc..05f129b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=00-01

  Stats: 81 lines in 36 files changed: 25 ins; 35 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10906/head:pull/10906

PR: https://git.openjdk.org/jdk/pull/10906

From duke at openjdk.org  Fri Oct 28 21:06:18 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 21:06:18 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <Kc1IpZcXV95qbdzVNsLaTKt4VRdafGSxXd1sqVSpsPc=.ba9f3752-817b-4cc1-82b8-edb09c6a0ce8@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <Kc1IpZcXV95qbdzVNsLaTKt4VRdafGSxXd1sqVSpsPc=.ba9f3752-817b-4cc1-82b8-edb09c6a0ce8@github.com>
Message-ID: <aVgn-q6aaKgkPR_HxdKjJm4m9jsxe9sjbbpGDpvSoOU=.720a8c98-6ceb-4306-9212-1b3d580119e6@github.com>

On Mon, 24 Oct 2022 23:38:16 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extra whitespace character
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 8306:
> 
>> 8304:   assert(dst != xnoreg, "sanity");
>> 8305:   InstructionMark im(this);
>> 8306:   InstructionAttr attributes(vector_len, /* vex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true);
> 
> no_mask_reg should be set to true here as we are not setting the mask register here.

done

> src/hotspot/cpu/x86/stubRoutines_x86.cpp line 83:
> 
>> 81: address StubRoutines::x86::_join_2_3_base64 = NULL;
>> 82: address StubRoutines::x86::_decoding_table_base64 = NULL;
>> 83: address StubRoutines::x86::_poly1305_mask_addr = NULL;
> 
> Please also update the copyright year to 2022 for stubRoutines_x86.cpp and hpp files.

done. (hpp seemed ok)

> src/hotspot/cpu/x86/vm_version_x86.cpp line 925:
> 
>> 923:     _features &= ~CPU_AVX512_VBMI2;
>> 924:     _features &= ~CPU_AVX512_BITALG;
>> 925:     _features &= ~CPU_AVX512_IFMA;
> 
> This should also be done under is_knights_family().

done

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 28 21:06:19 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 21:06:19 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <4FY4SEodgFcdxFXvGWFJWHYCr1GD4nAktLa5SiyPcxM=.384b2818-b6c5-4523-8682-5b730d9ad036@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <K1uON7wj2Hf6mMIWYPfAIUiUieiJ3AOPD6xE3rnHlT0=.45d87614-875f-4ba0-9e03-2a0b94ae17f5@github.com>
 <4FY4SEodgFcdxFXvGWFJWHYCr1GD4nAktLa5SiyPcxM=.384b2818-b6c5-4523-8682-5b730d9ad036@github.com>
Message-ID: <qhGvmU7FABv_2_lCdOp71Ub5NXVOZ8xofuVV2ZTfgK4=.d3e345ee-4a56-4955-8cab-ff8de535efb4@github.com>

On Wed, 26 Oct 2022 15:47:28 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 806:
>> 
>>> 804:   evmovdquq(A0, Address(rsp, 64*0), Assembler::AVX_512bit);
>>> 805:   evmovdquq(A0, Address(rsp, 64*1), Assembler::AVX_512bit);
>>> 806:   evmovdquq(A0, Address(rsp, 64*2), Assembler::AVX_512bit);
>> 
>> This is load from stack into A0. Did you intend to store A0 (cleanup) into stack local area here? I think the source and destination are mixed up here.
>
> Wow! Thank you for spotting this

done

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 28 21:06:21 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 21:06:21 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>
Message-ID: <NLmVF6MclxpeIVcSGcHLWBJW8iPKbq4f_GXjt8Qj4rs=.72f994ca-8bf3-4745-9acc-31f87b967175@github.com>

On Thu, 27 Oct 2022 09:29:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extra whitespace character
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2040:
> 
>> 2038: 
>> 2039: address StubGenerator::generate_poly1305_processBlocks() {
>> 2040:   __ align64();
> 
> This can be replaced by  __ align(CodeEntryAlignment);

done

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 28 21:06:21 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 21:06:21 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <ncjUr-Adsj7uaO29FWJ6k0umBrEXfv7fDg0x8cnE6n0=.4dee4a46-c702-44b3-a5bf-187263e9ac2d@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
 <KwT1ejhy7yvVIpMPCpkT2E87-bwwXRvVhZ-fy_Bm8po=.d71506cf-3e0c-4eb8-a008-390ab2ff4e02@github.com>
 <cjsKh51GqdfZ4GnIcniUrJfX7McnzDOz_cSf3BSR4FA=.4181923c-e89d-4e1d-902a-0b390b515472@github.com>
 <SajtNyPTRfsIaMh_o-fFN0Q1HYmehmUl-V5QCWm5jp4=.56a900ad-c725-4577-89d1-8ea860776d88@github.com>
 <SHVra8SjH-iWXZ-s-f4cWtbylOAg8rlGNQc3cVxTFRI=.c2d808b3-e5cb-4131-8c0b-e1c873aa5b3c@github.com>
 <ncjUr-Adsj7uaO29FWJ6k0umBrEXfv7fDg0x8cnE6n0=.4dee4a46-c702-44b3-a5bf-187263e9ac2d@github.com>
Message-ID: <4AB7TAZwydDonBwfxasMLmgVIQuaLgMUxck7eCbzYxw=.a9062602-90d4-4bde-baff-629bea466527@github.com>

On Thu, 27 Oct 2022 21:19:06 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>>> 10% is not a negligible impact. I see your point about AVX512 reaping the rewards of this change, but there are plenty of x86_64 systems without AVX512 that will be impacted, not to mention other platforms like aarch64 which (for this change at least) will never see the benefits from the intrinsic.
>>> 
>>> I don't have any suggestions right at this moment for how this could be streamlined at all to help reduce the pain for non-AVX512 systems. Worth looking into though.
>> 
>> Do you suggest using white box APIs for CPU feature query during poly static initialization and perform multi block processing only for relevant platforms and keep the original implementation sacrosanct for other targets. VM does offer native white box primitives and currently its being used by tests infrastructure.
>
> No, going the WhiteBox  route was not something I was thinking of.  I sought feedback from a couple hotspot-knowledgable people about the use of WhiteBox APIs and both felt that it was not the right way to go.  One said that WhiteBox is really for VM testing and not for these kinds of java classes.

One idea I was trying to measure was to make the intrinsic (i.e. the while loop remains exactly the same, just moved to different =non-static= function):

private void processMultipleBlocks(byte[] input, int offset, int length) { //, MutableIntegerModuloP A, IntegerModuloP R) {
    while (length >= BLOCK_LENGTH) {
        n.setValue(input, offset, BLOCK_LENGTH, (byte)0x01);
        a.setSum(n);                    // A += (temp | 0x01)
        a.setProduct(r);                // A =  (A * R) % p
        offset += BLOCK_LENGTH;
        length -= BLOCK_LENGTH;
    }
}


In principle, the java version would not get any slower (i.e. there is only one extra function jump). At the expense of the C++ glue getting more complex. In C++ I need to dig out using IR `(sun.security.util.math.intpoly.IntegerPolynomial.MutableElement)(this.a).limbs` then convert 5*26bit limbs into 3*44-bit limbs. The IR is very new to me so will take some time. (I think I found some AES code that does something similar).

That said.. I thought this idea would had been perhaps a separate PR, if needed at all.. Digging limbs out is one thing, but also need to add asserts and safety. Mostly would be happy to just measure if its worth it.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 28 21:06:23 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 21:06:23 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <T_pU0eAoFldEh9BE4pHU2pAGfLpot70nrKyVJR2_ZKI=.647f346e-e7f9-4ef2-a606-1148f424699f@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <BKHPNZFMR60W5dFzqO3sps0PKpxX2ggEjnK6yqKT_RE=.e531ff46-43cb-4ed3-b3f9-103ab0c7a8e5@github.com>
 <T_pU0eAoFldEh9BE4pHU2pAGfLpot70nrKyVJR2_ZKI=.647f346e-e7f9-4ef2-a606-1148f424699f@github.com>
Message-ID: <zX9l4tnbNyF-LDSm_G_kUs8IuwH14uyf_GDPe7gSb9Y=.d5ed49a4-b360-4840-be9e-ad0a623f28dd@github.com>

On Fri, 28 Oct 2022 19:46:33 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 175:
>> 
>>> 173:             // Choice of 1024 is arbitrary, need enough data blocks to amortize conversion overhead
>>> 174:             // and not affect platforms without intrinsic support
>>> 175:             int blockMultipleLength = (len/BLOCK_LENGTH) * BLOCK_LENGTH;
>> 
>> Since Poly processes 16 byte chunks, a strength reduced version of above expression could be len & (~(BLOCK_LEN-1)
>
> I guess I got no issue with either version.. I was mostly thinking about code clarity? I think your version is 'more reliable' so just gonna switch it, thanks.

done

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From duke at openjdk.org  Fri Oct 28 21:06:26 2022
From: duke at openjdk.org (vpaprotsk)
Date: Fri, 28 Oct 2022 21:06:26 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <ciNkfW7vps_NlMo48k2iiEF-n3eODjTkMXBnh5E6UOs=.d01b33ec-3807-4738-a155-4d8dad3bd67a@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
 <ciNkfW7vps_NlMo48k2iiEF-n3eODjTkMXBnh5E6UOs=.d01b33ec-3807-4738-a155-4d8dad3bd67a@github.com>
Message-ID: <ho1jejeOhwvS4iR99KyneWiWr_2a9OZCNfQb-3itkV8=.bb6ecc9c-5dfa-450f-b886-a33118c40db4@github.com>

On Wed, 26 Oct 2022 15:27:55 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 296:
>> 
>>> 294:         keyBytes[12] &= (byte)252;
>>> 295: 
>>> 296:         // This should be enabled, but Poly1305KAT would fail
>> 
>> I'm on the fence about this change.  I have no problem with it in basic terms.  If we ever decided to make this a general purpose Mac in JCE then this would definitely be good to do.  As of right now, the only consumer is ChaCha20 and it would submit a key through the process in the RFC.  Seems really unlikely to run afoul of these checks, but admittedly not impossible.
>> 
>> I would agree with @sviswa7 that we could examine this in a separate change and we could look at other approaches to getting around the KAT issue, perhaps some package-private based way to disable the check.  As long as Poly1305 remains with package-private visibility, one could make another form of the constructor with a boolean that would disable this check and that is the constructor that the KAT would use.  This is just an off-the-cuff idea, but one way we might get the best of both worlds.
>> 
>> If we move this down the road then we should remove the commenting.  We can refer back to this PR later.
>
> I think I will remove the check for now, dont want to hold up reviews. I wasn't sure how to 'inject a backdoor' to the commented out check either, or at least how to do it in an acceptable way. Your ideas do sound plausible, and if anyone does want this check, I can implement one of the ideas (package private boolean flag? turn it on in the test) while waiting for more reviews to come in.
> 
> The comment about ChaCha being the only way in is also relevant, thanks. i.e. this is a private class today.

I flipped-flopped on this.. I already had the code for the exception.. and already described the potential fix. So rather then remove the code, pushed the described fix. Its always easier to remove the extra field I added. Let me know what you think about the 'backdoor' field.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From jnimeh at openjdk.org  Fri Oct 28 21:58:30 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 28 Oct 2022 21:58:30 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <ho1jejeOhwvS4iR99KyneWiWr_2a9OZCNfQb-3itkV8=.bb6ecc9c-5dfa-450f-b886-a33118c40db4@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <9h52z_DWFvTWWwasN7vzl9-7C0-Tj50Cis4fgRNuId8=.65de1f73-f5f3-4326-b9e0-6211861452ea@github.com>
 <rWyVuKzBYxwlH2VD7NTEhn3RmEkPD7Y1xZxLdzRC9PU=.afb331b2-0940-46ff-8801-2debf135cdc9@github.com>
 <ciNkfW7vps_NlMo48k2iiEF-n3eODjTkMXBnh5E6UOs=.d01b33ec-3807-4738-a155-4d8dad3bd67a@github.com>
 <ho1jejeOhwvS4iR99KyneWiWr_2a9OZCNfQb-3itkV8=.bb6ecc9c-5dfa-450f-b886-a33118c40db4@github.com>
Message-ID: <0xJMPRdK0h3UJBYxqeLMfp1baL8xoaUpNcAZOtrFLKo=.d5c1020e-9e61-4800-bb52-9adbdd17e19f@github.com>

On Fri, 28 Oct 2022 21:03:32 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> I think I will remove the check for now, dont want to hold up reviews. I wasn't sure how to 'inject a backdoor' to the commented out check either, or at least how to do it in an acceptable way. Your ideas do sound plausible, and if anyone does want this check, I can implement one of the ideas (package private boolean flag? turn it on in the test) while waiting for more reviews to come in.
>> 
>> The comment about ChaCha being the only way in is also relevant, thanks. i.e. this is a private class today.
>
> I flipped-flopped on this.. I already had the code for the exception.. and already described the potential fix. So rather then remove the code, pushed the described fix. Its always easier to remove the extra field I added. Let me know what you think about the 'backdoor' field.

Well, what you're doing achieves what we're looking for, thanks for making that change.  I think I'd like to see that value set on construction and not be mutable from outside the object.  Something like this:

- place a `private final boolean checkWeakKey` up near where all the other fields are defined.
- the no-args Poly1305 is implemented as `this(true)`
- an additional constructor is created `Poly1305(boolean checkKey)` which sets `checkWeakKey` true or false as provided by the parameter.
- in setRSVals you should be able to wrap lines 296-310 inside a single `if (checkWeakKey)` block.
- In the Poly1305KAT the `new Poly1305()`  becomes `new Poly1305(false)`.

-------------

PR: https://git.openjdk.org/jdk/pull/10582

From weijun at openjdk.org  Fri Oct 28 22:04:39 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Oct 2022 22:04:39 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v3]
In-Reply-To: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
Message-ID: <A1MygtrtKoMOKoDqXX0JUjPBSNNhZ6kB9K4Z7N8zIRE=.d1752a5e-49c7-4460-8377-4e63c5a82867@github.com>

> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode` interface methods are modified from `OutputStream` to `DerOutputStream`. All implementations are modified the same way.
> 
> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
> 
> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  same for DerEncoder::derEncode
  
  only in patch2:
  unchanged:

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10906/files
  - new: https://git.openjdk.org/jdk/pull/10906/files/05f129b2..da7221f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=01-02

  Stats: 50 lines in 13 files changed: 1 ins; 23 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/10906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10906/head:pull/10906

PR: https://git.openjdk.org/jdk/pull/10906

From wetmore at openjdk.org  Fri Oct 28 22:34:19 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 28 Oct 2022 22:34:19 GMT
Subject: RFR: 8256660: Disable DTLS 1.0
In-Reply-To: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
References: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
Message-ID: <QDKmApSlwOh3kzyCktoVCSM2li8zHskMEEDG1AL27Do=.c2946311-8646-4008-828d-772e531d3b32@github.com>

On Fri, 28 Oct 2022 17:00:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Disable DTLS 1.0 by default. This version of DTLS has weakened over time and lacks support for stronger cipher suites. DTLS 1.0 correlates with version 1.1 of TLS which has already been disabled by default in JDK 16. The IETF has deprecated this version of DTLS (along with TLS 1.0 and 1.1) in RFC 8996: https://www.rfc-editor.org/rfc/rfc8996.html.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8280507

LGTM, also.

Took a bit to figure out 1352, but got it now.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10905

From duke at openjdk.org  Fri Oct 28 23:54:22 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 23:54:22 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
Message-ID: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>

On Fri, 28 Oct 2022 19:51:49 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove .orig file

src/java.base/share/classes/java/util/FormatterBuilder.java line 470:

> 468:      */
> 469:     MethodHandle build() {
> 470:         Formatter.parse(format);

`Formatter.parse` is called here, and then again a few lines down.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jjg at openjdk.org  Sat Oct 29 00:05:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 29 Oct 2022 00:05:32 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <r_58JHoKmjUmSoO1PboxKdQoV8yJ3nwjDn_KIIr5o7k=.13c13918-f42e-4f5b-9557-6894e2b301fb@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs 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 four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

The changes in `jdk.compiler` and `jdk.javadoc` seem innocuous enough.  Because of the bootstrap issue/latency, we'll have to wait before we can update to non-deprecated code.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From duke at openjdk.org  Sat Oct 29 01:03:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Sat, 29 Oct 2022 01:03:23 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>

On Fri, 28 Oct 2022 19:13:54 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
> 
>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 322:      */
>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
> 
> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.

The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mpowers at openjdk.org  Sat Oct 29 02:11:06 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 29 Oct 2022 02:11:06 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
Message-ID: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>

https://bugs.openjdk.org/browse/JDK-8293412

-------------

Commit messages:
 - Merge
 - second iteration
 - Merge
 - first iteration

Changes: https://git.openjdk.org/jdk/pull/10716/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10716&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293412
  Stats: 31 lines in 10 files changed: 2 ins; 17 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10716.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10716/head:pull/10716

PR: https://git.openjdk.org/jdk/pull/10716

From mpowers at openjdk.org  Sat Oct 29 02:11:06 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 29 Oct 2022 02:11:06 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <fbj4q2Tf-m4Bzf6D1BebNCUonpzi3m34-C12ytaKakQ=.5c2d10dd-2b65-4434-b4a5-0529228b629b@github.com>

On Fri, 14 Oct 2022 21:49:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293412

No failures were noticed during mach5 and jtreg testing.

-------------

PR: https://git.openjdk.org/jdk/pull/10716

From xuelei at openjdk.org  Sat Oct 29 04:22:15 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 29 Oct 2022 04:22:15 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <iUYqoCVP_PXYF6BLYtwpaYIqOSgxRbSOXkJvv75fhgE=.4dd85e6b-a439-463e-bb7a-f915749fa58b@github.com>

On Fri, 14 Oct 2022 21:49:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293412

I think it is a good clean up so that the default one get used in testing.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10716

From jpai at openjdk.org  Sat Oct 29 11:58:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 11:58:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
 <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
Message-ID: <FfQ1_F-GP2tNy3JiwtPN-BLBK6E8b636tX8T1Vfl_5U=.a3f9410a-72fd-4dc2-87d8-35bf91897af9@github.com>

On Thu, 27 Oct 2022 11:24:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> How about `_unused` or `_unused1`, `_unused2` then in the meantime?
>
> I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

Hello Daniel, I think calling it `unused` is fine. I did a quick search in the JDK code and we already have places where we use such a variable name for similar usecase. I don't see the need for using an underscore as a prefix, but it is OK with me if you and others prefer to use it.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From jpai at openjdk.org  Sat Oct 29 12:05:07 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 12:05:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
Message-ID: <zzbb3oae_BJ3Xn5x5xJB3tfugG41Om9Mv6LhbXOKH1c=.9ac9052a-8d9f-4450-95df-599ebabc6476@github.com>

On Wed, 26 Oct 2022 17:51:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
>> 
>> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
>> 
>> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.
>
> One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

I think `URL.of(URI, URLStreamHandler)` is fine.

As for `URL.of(URI)`, whose implementation I suspect will just do `uri.toURL()` on the passed `URI`, I don't think we need it. It might add to unnecesary confusion on whether/when to use `URL.of(URI)` and when to use `URI.toURL()`

In the case of `URL.of(URI, URLStreamHandler)` it's pretty clear that you use it (only) when you have a specific `URLStreamHandler` to use for the constructed `URL`.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From aivanov at openjdk.org  Sat Oct 29 12:14:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 12:14:25 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <rzIw7fkMmSiQ4HJygtWh3SxVIIZg4QY0nvByxOYUyGs=.b878366e-a60f-410f-94ae-47b486f4e7b5@github.com>

On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:
> 
>> 132: 
>> 133: #SyncResolverImpl exceptions
>> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020
> 
> prob. unnecessary

This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From aivanov at openjdk.org  Sat Oct 29 13:22:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 13:22:09 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Trailing spaces in `LocaleNames_*` are only in two files:

- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties`
- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties`

It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one.

src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238:

> 236: cpp=Kreolisch-Portugiesische Sprache
> 237: crh=Krimtatarisch
> 238: crp=Kreolische Sprache\u0020

I'm pretty sure locale names shouldn't contain trailing spaces.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From alanb at openjdk.org  Sat Oct 29 14:28:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Oct 2022 14:28:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs 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 four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

src/java.base/share/classes/java/net/URL.java line 133:

> 131:  * specified. The optional fragment is not inherited.
> 132:  *
> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>

Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?

src/java.base/share/classes/java/net/URL.java line 157:

> 155:  * The URL constructors are specified to throw
> 156:  * {@link MalformedURLException} but the actual parsing/validation
> 157:  * that are performed is implementation dependent. Some parsing/validation

"the ... are performed" -> "the ... is performed".

src/java.base/share/classes/java/net/URL.java line 166:

> 164:  * The {@code java.net.URL} constructors are deprecated.
> 165:  * Developers are encouraged to use {@link URI java.net.URI} to parse
> 166:  * or construct any {@code URL}. In cases where an instance of {@code

"any URL" -> "a URL" or "all URLs".

src/java.base/share/classes/java/net/URL.java line 168:

> 166:  * or construct any {@code URL}. In cases where an instance of {@code
> 167:  * java.net.URL} is needed to open a connection, {@link URI} can be used
> 168:  * to construct or parse the URL string, possibly calling {@link

I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString.

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL of(URI uri, URLStreamHandler streamHandler)

The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion.

src/java.base/share/classes/java/net/URL.java line 885:

> 883: 
> 884:             @SuppressWarnings("deprecation")
> 885:             var result = new URL("jrt", host, port, file, null);

The URL scheme for jrt does have a port so we should look at that some time.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From djelinski at openjdk.org  Mon Oct 31 06:58:32 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 31 Oct 2022 06:58:32 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <oVNznPr2qo1Dyc8_44VDAvKJULkij_QuVWgq_VdmvN0=.4fa73e25-1cbd-4017-89d6-36e5c2c9c998@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <C2qMC1uj1m8abXZsPAHRxpqFHM39sN_hIf6D2Nkuzko=.8a193705-285d-4de4-a56f-5b2cda7da212@github.com>
 <oVNznPr2qo1Dyc8_44VDAvKJULkij_QuVWgq_VdmvN0=.4fa73e25-1cbd-4017-89d6-36e5c2c9c998@github.com>
Message-ID: <XN3YvIIgDvi8LD9vmnKHh0pjc4uvRb810KoRUpdrcEo=.e65ebd1f-5271-4718-8297-204094863718@github.com>

On Fri, 28 Oct 2022 14:39:34 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 628:
>> 
>>> 626:                             ProjectivePoint.Mutable m =
>>> 627:                                     multiplier.pointMultiply(s);
>>> 628:                             points[d][w] = m.setValue(m.asAffine()).fixed();
>> 
>> Did you try using AffinePoints instead of ProjectivePoints? Sum with AffinePoints is supposed to be a bit faster, wonder if the improvement is worthwhile.
>> 
>> Also, unless you switch to affine points, just use `m.fixed()`.
>
>> Did you try using AffinePoints instead of ProjectivePoints?
> 
> Yes.  See [JDK-8295763](https://bugs.openjdk.org/browse/JDK-8295763).  Unfortunately, the mixed point addition formulas used in JDK implementation does not support additional of neutral point. It may be doable again if the formulas get changed in the future.
> 
>> Also, unless you switch to affine points, just use m.fixed().
> 
> Yes, the change to AffinePoints is mainly for checking in the following block.  BTW, the class loading is slow, hard-coded tables should be used in a coming update very soon.

ah... right. The neutral point, aka point at infinity (0:1:0) cannot be represented in affine space. Thanks for checking.

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From djelinski at openjdk.org  Mon Oct 31 07:12:19 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 31 Oct 2022 07:12:19 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
Message-ID: <ZndSeYiFxbuwtnDoQPjJsNhjIbNHTq0PyDbsT4vhvyQ=.cd6cbef0-1e0f-4356-b6be-e421d502e8ac@github.com>

On Fri, 28 Oct 2022 18:05:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
>> 
>> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
>> 
>> ## SSLHandshake.java benchmark
>> ### Use secp256r1 as the named group
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
>> 
>> ### Use default TLS named groups
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
>> 
>> ## KeyPairGenerators.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>> 
>> ## Signatures.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
>> 
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tailing whitespaces

Looks good to me.

It would be nice to add a test / consistency check, verifying that:
- all values in the precomputed table are correct,
- the multiplication results from the generator multiplier are consistent with the results from the default multiplier

something like:

var n = 00ff00ff00ff00ff 0f0f0f0f0f0f0f0f 3333333333333333 5555555555555555
assert that (2n)G = 2(nG) = n(2G) = (known good result)

but if you choose to add it in the follow-up change that hardcodes the precomputed values, that's fine by me

-------------

Marked as reviewed by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/10893

From forax at openjdk.org  Mon Oct 31 07:17:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 07:17:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
Message-ID: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>

On Sat, 29 Oct 2022 00:56:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
>> 
>>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>>> 322:      */
>>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
>> 
>> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.
>
> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
> 
> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

Ok, get it.
I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.

The less methods in the API, the better.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From djelinski at openjdk.org  Mon Oct 31 09:39:54 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 31 Oct 2022 09:39:54 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <SNE_8TXNUBXglCojrEvU0VW4SA3Dp7JkmFXBrS7YESE=.cef7eab7-d034-4c76-8d5b-7b19594c2d61@github.com>

On Fri, 14 Oct 2022 21:49:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293412

I'm still verifying the jarsigner and the SecurityTools changes, but all of the other files actually need the EGD override.

test/jdk/java/security/SecureRandom/ApiTest.java line 56:

> 54: 
> 55:     public static void main(String[] args) throws Exception {
> 56:         System.setProperty("java.security.egd", "file:/dev/urandom");

This test uses generateSeed and needs egd.

test/jdk/java/security/SecureRandom/EnoughSeedTest.java line 43:

> 41: 
> 42:     public static void main(String[] args) {
> 43:         System.setProperty("java.security.egd", "file:/dev/urandom");

This test uses generateSeed and needs egd to avoid reading from /dev/random

test/jdk/java/security/SecureRandom/MacNativePRNGSetSeed.java line 30:

> 28:  * @summary Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom
> 29:  * @requires os.name == "Mac OS X"
> 30:  * @run main/othervm -Djava.security.egd=file:/dev/urandom MacNativePRNGSetSeed

this change makes this test pointless, see summary 2 lines above

test/jdk/java/security/SecureRandom/MultiThreadTest.java line 44:

> 42:  * @summary Test behavior of a shared SecureRandom object when it is operated
> 43:  *          by multiple threads concurrently.
> 44:  * @run main/othervm -Djava.security.egd=file:/dev/urandom MultiThreadTest

This uses generateSeed and needs egd to avoid using dev/random

test/jdk/java/security/SecureRandom/Serialize.java line 36:

> 34: 
> 35:     public static void main(String args[]) throws Exception {
> 36:         System.setProperty("java.security.egd", "file:/dev/urandom");

This uses generateSeed and needs egd to avoid using dev/random

test/jdk/java/security/SecureRandom/SerializedSeedTest.java line 32:

> 30:  *          generated random numbers should be different when one or both are
> 31:  *          reseeded.
> 32:  * @run main/othervm -Djava.security.egd=file:/dev/urandom SerializedSeedTest

This uses generateSeed and needs egd to avoid using dev/random

test/jdk/sun/security/provider/SecureRandom/AutoReseed.java line 31:

> 29:  * @bug 8051408
> 30:  * @summary make sure nextBytes etc can be called before setSeed
> 31:  * @run main/othervm -Djava.security.egd=file:/dev/urandom AutoReseed

This test uses generateSeed and needs egd to avoid reading from /dev/random

test/jdk/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java line 29:

> 27:  * @summary NativeSeedGenerator is making 8192 byte read requests from
> 28:  *             entropy pool on each init.
> 29:  * @run main/othervm -Djava.security.egd=file:/dev/random SeedGeneratorChoice

This test uses generateSeed and should be run with egd pointing to /dev/urandom to avoid reading from /dev/random

-------------

Changes requested by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/10716

From jlaskey at openjdk.org  Mon Oct 31 12:39:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:39:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <EQVJmKVbtnwEXTfgghVb4mU5BE4xtbqoLDTOgwCmqDU=.73928cc8-ed53-4da1-81dd-a5b847aa9595@github.com>

On Fri, 28 Oct 2022 20:23:26 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`
>
> Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?
> 
> People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

Noted

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:53:29 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:29 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <OIUDXCNftOdGHiKS44vTdCuDosKklkect9B3NrfkNNk=.2a399201-95dd-4f7c-a768-14da71da6c41@github.com>

On Fri, 28 Oct 2022 20:07:35 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> The defensive copies are done by the callers.
>
> In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

Moving to TemplateRuntime

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:53:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <hEQTvtQgMLQMCZHJWaVzJzCGo_H7PAYWpR_X8Vs3Hcw=.c9102791-3f62-4222-afea-3aba32323325@github.com>

On Fri, 28 Oct 2022 19:05:10 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:
> 
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
>> 29: import java.util.*;
> 
> Please fix.

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:59:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:59:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <ZE2vcmQWISh2duTMkVFwVLUj4JfRFSR5ZQ9gz8AWhgk=.e9946cbe-e5a4-4a9c-a2c6-f309bd536142@github.com>

On Fri, 28 Oct 2022 19:06:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:
> 
>> 173:      * method {@code processor.process(this)}.
>> 174:      */
>> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {
> 
> signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:
> 
>> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
>> 203:      */
>> 204:     default public List<MethodHandle> valueGetters() {
> 
> I think i prefer the term accessors instead of getters

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:04:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:04:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>

On Fri, 28 Oct 2022 19:08:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
> 
>> 147:      * {@return the interpolation of the StringTemplate}
>> 148:      */
>> 149:     default String interpolate() {
> 
> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <n5D2AKUK150bLdl1X1PAp8RZQ9Oo4EOJh863F8tMSMQ=.078b48c3-59bb-40c1-a3df-660242f8ae74@github.com>

On Fri, 28 Oct 2022 19:12:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:
> 
>> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
>> 306:         }
>> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));
> 
> I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().
> 
> Edit:
> fragments should use List.copyOf() but i suppose that a value inside values can be null, so you can not use List.copyOf() for the values.
> 
> There a little secret, the ImmutableList  has a special flag to represent an unmodifiable list that can access null, this implementation is used by `stream.toList()`, i think you should use a shared secret access to have have access to this implementation instead of relying on `Collections.unmodifiableList(new ArrayList<>(...))`.
> 
> @stuart-marks, do you think it's a good idea to use the null allowed ImmutableList here ?

Changing as recommended

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:
> 
>> 352:      * @implNote The result of interpolation is not interned.
>> 353:      */
>> 354:     public static final StringProcessor STR = st -> st.interpolate();
> 
> Should be `StringTemplate::interpolate`.

Yep

> src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:
> 
>> 36:  * that do not throw checked exceptions. For example:
>> 37:  * {@snippet :
>> 38:  * TemplateProcessor<String> processor = st -> {
> 
> This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

Noted

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
 <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
Message-ID: <IQ1cw48hyO6eHZumI9fehaIEPEFhx4GHZaRtexHoW7k=.b9cb907b-f4f7-4bbb-ace7-32c86b86fdfe@github.com>

On Mon, 31 Oct 2022 07:14:45 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
>> 
>> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.
>
> Ok, get it.
> I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.
> 
> The less methods in the API, the better.

Noted

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:49:18 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com>

On Fri, 28 Oct 2022 19:20:40 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:
> 
>> 43:  */
>> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 45: public final class TemplateRuntime {
> 
> Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

Purely because of the BSM and BSMs access to internals of `java.lang.template`. I'll work on moving the BSM to `jdk.internal`. and access through `SharedSecrets`.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:
> 
>> 63:      * @throws Throwable            if linkage fails
>> 64:      */
>> 65:     public static CallSite stringTemplateBSM(
> 
> I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

Will work on it.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:49:20 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
 <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
Message-ID: <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@github.com>

On Fri, 28 Oct 2022 19:57:41 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
>> 
>> public static <E> List<E> toList(E... elements) {
>> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
>> }
>
> Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
> Using that implementation will avoid a bunch of indirection

Changing to use `JUCA`.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:54:44 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:54:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <Z7QI2E1zswpmzuoUkBJzlEYAh1l9iOcTYwe82y4X2Uw=.0056169c-283a-4012-a943-c7223b67485e@github.com>

On Fri, 28 Oct 2022 19:26:20 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:
> 
>> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
>> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
>> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();
> 
> `ValidatingProcessor<?, ?>` should be enough ? No ?
> Using a "? extends Throwable" here make the type unchecked.

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:
> 
>> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
>> 87:      */
>> 88:     private static class TemplateBootstrap {
> 
> This class should be `final`

Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:
> 
>> 115:          * Static final processor.
>> 116:          */
>> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;
> 
> Use `ValidatingProcessor<?, ?>` here

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:
> 
>> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
>> 144:                                   List<String> fragments,
>> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {
> 
> Use ValidatingProcessor&lt;?, ?&gt; here

That works. Changing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:30:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:30:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <K46-FD72Mtz3zFIhWwj9_0QI100Sy4_XE2q34hxNyMU=.9e66b1d0-5031-4564-8404-e1b545f2fafa@github.com>

On Fri, 28 Oct 2022 19:33:38 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:
> 
>> 287:         try {
>> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
>> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",
> 
> This should be a constant (using the class holder idiom or not)

Changing

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:
> 
>> 300: 
>> 301:     /**
>> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}
> 
> Private "method"

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:39:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:39:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <EprEHey_-RlxTSqSiEgb7upgHtblKqAQO6mM_Exgqjs=.eaf0be7b-85d2-4179-847c-da5d07c80eb7@github.com>

On Fri, 28 Oct 2022 19:39:01 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:
> 
>> 387:             }
>> 388:         }
>> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));
> 
> It seems that IntelliJ was lost when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:49:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:49:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <hJKj6jjb0I6mnmYZW8CO7T_AfPDBzbz1B4xuG8mZ9Gc=.b156b047-8839-4447-b21f-fbe7b3b4eb8f@github.com>

On Fri, 28 Oct 2022 19:36:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:
> 
>> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 324:      */
>> 325:     static String interpolate(List<String> fragments, List<Object> values) {
> 
> I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From xuelei at openjdk.org  Mon Oct 31 14:59:02 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 14:59:02 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <ZndSeYiFxbuwtnDoQPjJsNhjIbNHTq0PyDbsT4vhvyQ=.cd6cbef0-1e0f-4356-b6be-e421d502e8ac@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
 <ZndSeYiFxbuwtnDoQPjJsNhjIbNHTq0PyDbsT4vhvyQ=.cd6cbef0-1e0f-4356-b6be-e421d502e8ac@github.com>
Message-ID: <aPQsgU9aCcqBasHJNL3fs64ceC5VsOjRFJVSJNFGLYM=.21b78c47-9bab-46d6-ac3f-15971d262242@github.com>

On Mon, 31 Oct 2022 07:08:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> It would be nice to add a test / consistency check, verifying that:

The current tests could be used to verify the tables.  As the fields are private, it is not easy to add a test.  But I will try in the follow-up change that hardcodes the precomputed values.

Thank you for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From xuelei at openjdk.org  Mon Oct 31 14:59:05 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 14:59:05 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
Message-ID: <ji-YLksle6fu2bpqSfmS_eaNnBNC-xPH4yLcuJzodmE=.b71d6473-617f-403c-a788-69baebb1b896@github.com>

On Fri, 28 Oct 2022 18:05:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
>> 
>> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
>> 
>> ## SSLHandshake.java benchmark
>> ### Use secp256r1 as the named group
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
>> 
>> ### Use default TLS named groups
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
>> 
>> ## KeyPairGenerators.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>> 
>> ## Signatures.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
>> 
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tailing whitespaces

I still need a Reviewer approve.  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From xuelei at openjdk.org  Mon Oct 31 15:00:35 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 15:00:35 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v3]
In-Reply-To: <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
Message-ID: <NR_HolazhlMqFrMP35cHezTE8wgEHLVwe5cY9SvEH0k=.3d03dd4e-a7e1-4bbb-81f2-5328bf41df4d@github.com>

On Sat, 8 Oct 2022 15:34:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 13 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 43 multiplication.
>> 
>> In EC operations, square operation is much faster than multiplication.  Decreasing multiplication numbers could speed up the multiplicative inverse significantly.
>> 
>> The benchmark for ECDSA Signature is checked in order to see if the performance improvement is visible.  Here are the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Signatures.sign               64  thrpt   15  1484.404 ? 10.705  ops/s
>> Signatures.sign              512  thrpt   15  1486.563 ?  7.514  ops/s
>> Signatures.sign             2048  thrpt   15  1479.866 ? 15.028  ops/s
>> Signatures.sign            16384  thrpt   15  1469.789 ?  3.844  ops/s
>> 
>> 
>> The performance improvement of the patch is about 5% for ECDSA signature.  It looks like the improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> For comparing, here is the benchmarking numbers by using BigInteger.modInverse();
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.sign               64  thrpt   15  1395.628 ? 180.649  ops/s
>> Signatures.sign              512  thrpt   15  1510.590 ?   9.826  ops/s
>> Signatures.sign             2048  thrpt   15  1514.282 ?   3.382  ops/s
>> Signatures.sign            16384  thrpt   15  1497.325 ?   6.854  ops/s
>> 
>> and numbers for using BigInteger.modPow():
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1486.764 ? 17.908  ops/s
>> Signatures.sign              512  thrpt   15  1494.801 ? 14.072  ops/s
>> Signatures.sign             2048  thrpt   15  1500.170 ?  6.998  ops/s
>> Signatures.sign            16384  thrpt   15  1434.192 ? 49.269  ops/s
>> 
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more improvement

Reviewer approval is required.  Anyone has cycle?  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From jlaskey at openjdk.org  Mon Oct 31 15:01:31 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
Message-ID: <YUiKJ6MKELuPwEDxpmhH3AEsMk8mG7vLANniLjwaGuM=.d88e51b7-a807-4892-8dd0-977ab9fa8037@github.com>

On Fri, 28 Oct 2022 19:45:55 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 198:
> 
>> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
>> 197:      */
>> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);
> 
> `Locale.US` or `Locale.ROOT` ??
> see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

There was a bug in DecimalFormatSymbols when I started this work and Locale.ROOT was problematic. I didn't circle around to check later. Changing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 15:01:35 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
 <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
Message-ID: <HhniXeb1FMUt_2zLv1ioKD232wB4uGp6wNf06Lym3KI=.977dc53f-abe0-47dc-b06b-9475f919308c@github.com>

On Fri, 28 Oct 2022 23:50:11 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove .orig file
>
> src/java.base/share/classes/java/util/FormatterBuilder.java line 470:
> 
>> 468:      */
>> 469:     MethodHandle build() {
>> 470:         Formatter.parse(format);
> 
> `Formatter.parse` is called here, and then again a few lines down.

Residue cruft. Thanks. Changing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mpowers at openjdk.org  Mon Oct 31 15:02:30 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 31 Oct 2022 15:02:30 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v4]
In-Reply-To: <sk38waNY2ZLD6EZ1k5th5T6lElJ5CVI3Q_ckpFO3gPE=.e5df5177-bcfc-4d75-89d2-484e3ede54d9@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <yYldUK0r3k2qibXIpTMZFR_vFDQ37CuiPcJ0ZH0_SuM=.4c4c5cc7-aa49-417c-872d-250554ba2553@github.com>
 <sk38waNY2ZLD6EZ1k5th5T6lElJ5CVI3Q_ckpFO3gPE=.e5df5177-bcfc-4d75-89d2-484e3ede54d9@github.com>
Message-ID: <aj4bT6iojg-kU0Ed6M-f55B_5EoHw4yf3GyFrLIIZjg=.4c1c2105-7d1a-4486-ac01-b6927b6c2851@github.com>

On Mon, 10 Oct 2022 21:04:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 35:
> 
>> 33: import java.util.*;
>> 34: 
>> 35: public class Serial2 implements java.io.Serializable {
> 
> I don't see why this needs to implement `Serializable` (I see you probably used the other `Serial.java` test in this directory as a template. I don't think that needs it either, but you can leave that as is for now).

I read your sentence as "leave both for now". Sorry. You mean fix in this PR and leave the other alone.

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From jjiang at openjdk.org  Mon Oct 31 15:11:29 2022
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 31 Oct 2022 15:11:29 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
Message-ID: <_bWbOVeajaYQ_7SL1-4-KKiodnoyhXGsawBpqACaEzY=.f21f00ca-0c9e-4e4c-9568-7f930bfadaa2@github.com>

On Fri, 28 Oct 2022 18:05:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
>> 
>> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
>> 
>> ## SSLHandshake.java benchmark
>> ### Use secp256r1 as the named group
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
>> 
>> ### Use default TLS named groups
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
>> 
>> ## KeyPairGenerators.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>> 
>> ## Signatures.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
>> 
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tailing whitespaces

Marked as reviewed by jjiang (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From jjiang at openjdk.org  Mon Oct 31 15:12:26 2022
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 31 Oct 2022 15:12:26 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v3]
In-Reply-To: <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
Message-ID: <siDT8LfaBtzWGZP6o-UFVsBbkIQz2qYfPLZmXKW1d_E=.5e405fc9-015b-49d1-aa21-94a5bbabf2d7@github.com>

On Sat, 8 Oct 2022 15:34:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this patch reviewed?
>> 
>> This is one of a few steps to improve the EC performance. The multiplicative inverse implementation could be improved for better performance. 
>> 
>> For secp256r1 prime p, the current  multiplicative inverse impl needs 256 square and 128 multiplication.  With the path, the operation needs 256 square and 13 multiplication.
>> 
>> For secp256r1 order n, the current  multiplicative inverse impl needs 256 square and 169 multiplication. With the patch, the operation needs  256 square and 43 multiplication.
>> 
>> In EC operations, square operation is much faster than multiplication.  Decreasing multiplication numbers could speed up the multiplicative inverse significantly.
>> 
>> The benchmark for ECDSA Signature is checked in order to see if the performance improvement is visible.  Here are the benchmark numbers before the patch applied:
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1412.644 ?  5.529  ops/s
>> Signatures.sign              512  thrpt   15  1407.711 ? 14.118  ops/s
>> Signatures.sign             2048  thrpt   15  1415.674 ?  6.965  ops/s
>> Signatures.sign            16384  thrpt   15  1395.582 ? 12.689  ops/s
>> 
>> 
>> And the following are the benchmarking after the patch applied.
>> 
>> Signatures.sign               64  thrpt   15  1484.404 ? 10.705  ops/s
>> Signatures.sign              512  thrpt   15  1486.563 ?  7.514  ops/s
>> Signatures.sign             2048  thrpt   15  1479.866 ? 15.028  ops/s
>> Signatures.sign            16384  thrpt   15  1469.789 ?  3.844  ops/s
>> 
>> 
>> The performance improvement of the patch is about 5% for ECDSA signature.  It looks like the improvement is no significant enough for now.  But it may be 2+ times more in numbers when the scalar multiplication implementation is improved in a follow-up enhancement in another pull request.
>> 
>> For comparing, here is the benchmarking numbers by using BigInteger.modInverse();
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.sign               64  thrpt   15  1395.628 ? 180.649  ops/s
>> Signatures.sign              512  thrpt   15  1510.590 ?   9.826  ops/s
>> Signatures.sign             2048  thrpt   15  1514.282 ?   3.382  ops/s
>> Signatures.sign            16384  thrpt   15  1497.325 ?   6.854  ops/s
>> 
>> and numbers for using BigInteger.modPow():
>> 
>> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign               64  thrpt   15  1486.764 ? 17.908  ops/s
>> Signatures.sign              512  thrpt   15  1494.801 ? 14.072  ops/s
>> Signatures.sign             2048  thrpt   15  1500.170 ?  6.998  ops/s
>> Signatures.sign            16384  thrpt   15  1434.192 ? 49.269  ops/s
>> 
>> 
>> Enhancement for other curves will be considered in separate pull requests.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more improvement

Marked as reviewed by jjiang (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From sean.mullan at oracle.com  Mon Oct 31 15:16:42 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 31 Oct 2022 11:16:42 -0400
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v4]
In-Reply-To: <aj4bT6iojg-kU0Ed6M-f55B_5EoHw4yf3GyFrLIIZjg=.4c1c2105-7d1a-4486-ac01-b6927b6c2851@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <yYldUK0r3k2qibXIpTMZFR_vFDQ37CuiPcJ0ZH0_SuM=.4c4c5cc7-aa49-417c-872d-250554ba2553@github.com>
 <sk38waNY2ZLD6EZ1k5th5T6lElJ5CVI3Q_ckpFO3gPE=.e5df5177-bcfc-4d75-89d2-484e3ede54d9@github.com>
 <aj4bT6iojg-kU0Ed6M-f55B_5EoHw4yf3GyFrLIIZjg=.4c1c2105-7d1a-4486-ac01-b6927b6c2851@github.com>
Message-ID: <ebcbb6be-49a3-d401-19ae-1ba54d6ae0dc@oracle.com>



On 10/31/22 11:02 AM, Mark Powers wrote:
> On Mon, 10 Oct 2022 21:04:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:
> 
>>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Sean comments
>>
>> test/jdk/javax/security/auth/PrivateCredentialPermission/Serial2.java line 35:
>>
>>> 33: import java.util.*;
>>> 34:
>>> 35: public class Serial2 implements java.io.Serializable {
>>
>> I don't see why this needs to implement `Serializable` (I see you probably used the other `Serial.java` test in this directory as a template. I don't think that needs it either, but you can leave that as is for now).
> 
> I read your sentence as "leave both for now". Sorry. You mean fix in this PR and leave the other alone.

Yes, I meant remove it from this test if it isn't needed. I think you 
can fix the other one, if you like, but since it hasn't caused any 
issues, feel free to leave it for now.

--Sean

From weijun at openjdk.org  Mon Oct 31 15:18:24 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 31 Oct 2022 15:18:24 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v3]
In-Reply-To: <NR_HolazhlMqFrMP35cHezTE8wgEHLVwe5cY9SvEH0k=.3d03dd4e-a7e1-4bbb-81f2-5328bf41df4d@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
 <NR_HolazhlMqFrMP35cHezTE8wgEHLVwe5cY9SvEH0k=.3d03dd4e-a7e1-4bbb-81f2-5328bf41df4d@github.com>
Message-ID: <ZWiRwMLW6b-AVEKbg70ZTz8zA_qz18WFi4Mt3wotc5c=.7932af86-668b-4cf7-8dcb-797cb6548fcf@github.com>

On Mon, 31 Oct 2022 14:58:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more improvement
>
> Reviewer approval is required.  Anyone has cycle?  Thanks!

Hi @XueleiFan, can you wait for approval from @ferakocz? Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From jlaskey at openjdk.org  Mon Oct 31 15:38:42 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:38:42 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v5]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <UEq7NU7NgwbZA9fmIW88hdE8TtJfMV1xgTUoyT9UUGQ=.9fa69424-0a2f-4909-8f77-8b1109f407d0@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Requested changes #2
 - Requested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/347df715..d30e6eff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03-04

  Stats: 168 lines in 15 files changed: 60 ins; 60 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Mon Oct 31 15:55:28 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 15:55:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
 <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
Message-ID: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com>

On Mon, 31 Oct 2022 13:02:18 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
>> 
>>> 147:      * {@return the interpolation of the StringTemplate}
>>> 148:      */
>>> 149:     default String interpolate() {
>> 
>> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy
>
> Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

Interesting !
I believe the javadoc should mention that.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mpowers at openjdk.org  Mon Oct 31 15:59:28 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 31 Oct 2022 15:59:28 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v5]
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <-itDGBpKgVEYd9ZryHAeyV21AC4KDf4YPV4WcalMefg=.c0fe28c3-9c2b-4048-852c-7646f97f55fd@github.com>

> https://bugs.openjdk.org/browse/JDK-8291974

Mark Powers 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 seven additional commits since the last revision:

 - Merge
 - implements Serializable
 - Sean comments
 - Text Blocks
 - long line
 - added test
 - first iteration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10206/files
  - new: https://git.openjdk.org/jdk/pull/10206/files/b3698128..ce27a083

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10206&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10206&range=03-04

  Stats: 306390 lines in 4313 files changed: 166247 ins; 89978 del; 50165 mod
  Patch: https://git.openjdk.org/jdk/pull/10206.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10206/head:pull/10206

PR: https://git.openjdk.org/jdk/pull/10206

From mullan at openjdk.org  Mon Oct 31 16:47:28 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 16:47:28 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v5]
In-Reply-To: <-itDGBpKgVEYd9ZryHAeyV21AC4KDf4YPV4WcalMefg=.c0fe28c3-9c2b-4048-852c-7646f97f55fd@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <-itDGBpKgVEYd9ZryHAeyV21AC4KDf4YPV4WcalMefg=.c0fe28c3-9c2b-4048-852c-7646f97f55fd@github.com>
Message-ID: <CjgTbFs5HwX37BbzcX4A565bcSrsyXJSa1cTPV5wLk8=.05b49a4e-1922-4232-a2b2-e364f7f1fa62@github.com>

On Mon, 31 Oct 2022 15:59:28 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers 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 seven additional commits since the last revision:
> 
>  - Merge
>  - implements Serializable
>  - Sean comments
>  - Text Blocks
>  - long line
>  - added test
>  - first iteration

Looks good. Go ahead an integrate and I will sponsor.

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From mullan at openjdk.org  Mon Oct 31 16:49:54 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 16:49:54 GMT
Subject: Integrated: 8256660: Disable DTLS 1.0
In-Reply-To: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
References: <hZdhvcKNj5vqAv-prRG_6E4jsJir00hy8yoUr3GbEfs=.f16c835e-5c2c-41f5-abe9-9219234f398e@github.com>
Message-ID: <wMYOcB90AxPWeNwggH181oRJTIxaqJRP_076uoyxDyo=.9fd13889-4f3a-4540-8d07-fcf8ab7adb76@github.com>

On Fri, 28 Oct 2022 17:00:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Disable DTLS 1.0 by default. This version of DTLS has weakened over time and lacks support for stronger cipher suites. DTLS 1.0 correlates with version 1.1 of TLS which has already been disabled by default in JDK 16. The IETF has deprecated this version of DTLS (along with TLS 1.0 and 1.1) in RFC 8996: https://www.rfc-editor.org/rfc/rfc8996.html.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8280507

This pull request has now been integrated.

Changeset: 16744b34
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16744b34498e7aac59caef8c9b1a3d4d15f8c22e
Stats:     56 lines in 3 files changed: 27 ins; 5 del; 24 mod

8256660: Disable DTLS 1.0

Reviewed-by: xuelei, hchao, wetmore

-------------

PR: https://git.openjdk.org/jdk/pull/10905

From xuelei at openjdk.org  Mon Oct 31 17:18:26 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 17:18:26 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v3]
In-Reply-To: <A1MygtrtKoMOKoDqXX0JUjPBSNNhZ6kB9K4Z7N8zIRE=.d1752a5e-49c7-4460-8377-4e63c5a82867@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
 <A1MygtrtKoMOKoDqXX0JUjPBSNNhZ6kB9K4Z7N8zIRE=.d1752a5e-49c7-4460-8377-4e63c5a82867@github.com>
Message-ID: <D4zkBW_9if8-dYnplnsk9QRztlqpEcS7Voy0hOTlVik=.c0d25bab-b972-4aac-ae5c-86feef7a33ac@github.com>

On Fri, 28 Oct 2022 22:04:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode` interface methods are modified from `OutputStream` to `DerOutputStream`. All implementations are modified the same way.
>> 
>> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
>> 
>> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   same for DerEncoder::derEncode
>   
>   only in patch2:
>   unchanged:

Looks good to me.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10906

From xuelei at openjdk.org  Mon Oct 31 17:29:37 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 17:29:37 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <otS0I5wK1DTeFCqeYsIbMFuUDeo4h0e3fKuMZXMhVi0=.1b695976-fc09-42a1-b3e2-7941eb703216@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <MTeDBg6HHh1CZUAu6f6-SCfP22YvnYzSlxfulVCNRhU=.83c4898f-9ad3-4f82-9eb0-9190258de465@github.com>
 <otS0I5wK1DTeFCqeYsIbMFuUDeo4h0e3fKuMZXMhVi0=.1b695976-fc09-42a1-b3e2-7941eb703216@github.com>
Message-ID: <7ANjQIUTPk6GhJM2ytYDO_bK0VAterLv37BQuCZYeY8=.3bc8f221-d97f-4e56-8989-6bd83d8c31f7@github.com>

On Mon, 10 Oct 2022 08:21:57 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> ... you only have one chance to measure, so cannot average out noise ...

There are cases that one chance is enough to place an attack.  We normally don't discuss vulnerability details in public, please send me an email in private if more details is required.

>  ... than again, you probably have better methods to get to the key than trying to measure time.

I may have to agree that better methods may exist.  But better methods do not imply that we can let this method go.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From xuelei at openjdk.org  Mon Oct 31 17:29:38 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 17:29:38 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <7ANjQIUTPk6GhJM2ytYDO_bK0VAterLv37BQuCZYeY8=.3bc8f221-d97f-4e56-8989-6bd83d8c31f7@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <JdkGCTtBKl9M-p1bXHTBmbpICscm8FuN3VRerluSCX8=.9679d8cf-b021-4f0b-8c95-a05c38f19606@github.com>
 <MTeDBg6HHh1CZUAu6f6-SCfP22YvnYzSlxfulVCNRhU=.83c4898f-9ad3-4f82-9eb0-9190258de465@github.com>
 <otS0I5wK1DTeFCqeYsIbMFuUDeo4h0e3fKuMZXMhVi0=.1b695976-fc09-42a1-b3e2-7941eb703216@github.com>
 <7ANjQIUTPk6GhJM2ytYDO_bK0VAterLv37BQuCZYeY8=.3bc8f221-d97f-4e56-8989-6bd83d8c31f7@github.com>
Message-ID: <90ysMYr5UGqZ9ixc_EPucoXpzrO8UBskXd1VLxGTOCM=.6e9b88c6-7a27-4471-9ae2-58bea2522d15@github.com>

On Mon, 31 Oct 2022 17:19:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> BigInteger exponentiation time also depends on also depends on the base; quick benchmark: `BigInteger.ONE.modPow(mod.subtract(BigInteger.TWO), mod)` vs `BigInteger.TWO.modPow(mod.subtract(BigInteger.TWO), mod)`:
>>> 
>>> ```
>>> Benchmark        (messageLength)   Mode  Cnt         Score         Error  Units
>>> Signatures.pow1               64  thrpt   15  67352286,115 ? 1281517,907  ops/s
>>> Signatures.pow2               64  thrpt   15     62431,716 ?    1056,398  ops/s
>>> ```
>>> 
>>> for IntegerModuloP the result should not depend on base, and if it does, we should fix that.
>> 
>> Well, if you ever encounter the special cased "ONE" during ECDSA signature, you have a bigger problem than that the exponentiation is not exactly constant time. Also, if you can get close enough to the system doing the signing to be able to measure the time of the exponentiation precisely enough to differentiate one really occurring base from another -- you only have one chance to measure, so cannot average out noise -- than again, you probably have better methods to get to the key than trying to measure time.
>
>> ... you only have one chance to measure, so cannot average out noise ...
> 
> There are cases that one chance is enough to place an attack.  We normally don't discuss vulnerability details in public, please send me an email in private if more details is required.
> 
>>  ... than again, you probably have better methods to get to the key than trying to measure time.
> 
> I may have to agree that better methods may exist.  But better methods do not imply that we can let this method go.

> Hi @XueleiFan, can you wait for approval from @ferakocz? Thanks.

I will see if I can get it by the end of this Tuesday.

-------------

PR: https://git.openjdk.org/jdk/pull/10544

From xuelei at openjdk.org  Mon Oct 31 17:36:35 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 17:36:35 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
Message-ID: <dTz0jfrguiXfoR7QKt9gbDySZvM2t1nn-GQmHOZPi7o=.e731410f-9a54-4cfc-b14b-3a5467c9461d@github.com>

On Fri, 28 Oct 2022 18:05:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
>> 
>> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
>> 
>> ## SSLHandshake.java benchmark
>> ### Use secp256r1 as the named group
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
>> 
>> ### Use default TLS named groups
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
>> 
>> ## KeyPairGenerators.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>> 
>> ## Signatures.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
>> 
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tailing whitespaces

Anyone from Oracle can help me to run Mach5 testing, just in case I missed something?

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From jlaskey at openjdk.org  Mon Oct 31 17:39:58 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 17:39:58 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v6]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <DJB8X-GwBxtqwAX0Rv_zRn_GhLXHyCF2-1RszcbcVtc=.532ca016-1d04-40f1-8523-399e24d59d75@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Move template bootstrap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/d30e6eff..75fcc49a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04-05

  Stats: 364 lines in 4 files changed: 210 ins; 147 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From mullan at openjdk.org  Mon Oct 31 18:32:18 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 18:32:18 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v3]
In-Reply-To: <A1MygtrtKoMOKoDqXX0JUjPBSNNhZ6kB9K4Z7N8zIRE=.d1752a5e-49c7-4460-8377-4e63c5a82867@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
 <A1MygtrtKoMOKoDqXX0JUjPBSNNhZ6kB9K4Z7N8zIRE=.d1752a5e-49c7-4460-8377-4e63c5a82867@github.com>
Message-ID: <si3LsHAJf-R-8TLeHtYkVGfMYGmgAb9QNLjlWIFt6fM=.7b0310aa-e498-48c7-afb9-5b77a17ec821@github.com>

On Fri, 28 Oct 2022 22:04:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode` interface methods are modified from `OutputStream` to `DerOutputStream`. All implementations are modified the same way.
>> 
>> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
>> 
>> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   same for DerEncoder::derEncode
>   
>   only in patch2:
>   unchanged:

A few minor comments.

src/java.base/share/classes/sun/security/pkcs10/PKCS10Attribute.java line 110:

> 108:      * @exception IOException on encoding errors.
> 109:      */
> 110:     public void derEncode(DerOutputStream out) throws IOException {

Add @Override

src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 96:

> 94:      * @exception IOException on encoding errors.
> 95:      */
> 96:     public void encode(DerOutputStream out) throws IOException {

Add @Override

src/java.base/share/classes/sun/security/x509/CertAttrSet.java line 67:

> 65:      * @exception IOException on other errors.
> 66:      */
> 67:     void encode(DerOutputStream out)

A bit of a nit, but on line 62, change `OutputStream` to `DerOutputStream` since it is referring to a type. Check the javadoc of all other classes for the same change.

-------------

PR: https://git.openjdk.org/jdk/pull/10906

From mullan at openjdk.org  Mon Oct 31 18:37:21 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 18:37:21 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v3]
In-Reply-To: <si3LsHAJf-R-8TLeHtYkVGfMYGmgAb9QNLjlWIFt6fM=.7b0310aa-e498-48c7-afb9-5b77a17ec821@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
 <A1MygtrtKoMOKoDqXX0JUjPBSNNhZ6kB9K4Z7N8zIRE=.d1752a5e-49c7-4460-8377-4e63c5a82867@github.com>
 <si3LsHAJf-R-8TLeHtYkVGfMYGmgAb9QNLjlWIFt6fM=.7b0310aa-e498-48c7-afb9-5b77a17ec821@github.com>
Message-ID: <xDdiNyEDeWbV7lYo8gThjgtb8qk6kBI32Hs_uYFsjrM=.edcd2671-65dc-4d76-82c2-b53a6d3315e8@github.com>

On Mon, 31 Oct 2022 18:26:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   same for DerEncoder::derEncode
>>   
>>   only in patch2:
>>   unchanged:
>
> src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 96:
> 
>> 94:      * @exception IOException on encoding errors.
>> 95:      */
>> 96:     public void encode(DerOutputStream out) throws IOException {
> 
> Add `@Override`.

I think you are missing `@Override` on some of the other `encode` and `derEncode` methods.

-------------

PR: https://git.openjdk.org/jdk/pull/10906

From weijun at openjdk.org  Mon Oct 31 19:06:39 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 31 Oct 2022 19:06:39 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v4]
In-Reply-To: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
Message-ID: <1vN2pDOQxTpPZyTQuaEm5vUgJrZDtvXtZVFyX86r90g=.f1dc3bc9-bd00-4b80-a622-539e7b682367@github.com>

> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode` interface methods are modified from `OutputStream` to `DerOutputStream`. All implementations are modified the same way.
> 
> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
> 
> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  param and override

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10906/files
  - new: https://git.openjdk.org/jdk/pull/10906/files/da7221f2..c4f17f73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=02-03

  Stats: 21 lines in 18 files changed: 9 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10906/head:pull/10906

PR: https://git.openjdk.org/jdk/pull/10906

From mullan at openjdk.org  Mon Oct 31 19:40:48 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 19:40:48 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v4]
In-Reply-To: <1vN2pDOQxTpPZyTQuaEm5vUgJrZDtvXtZVFyX86r90g=.f1dc3bc9-bd00-4b80-a622-539e7b682367@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
 <1vN2pDOQxTpPZyTQuaEm5vUgJrZDtvXtZVFyX86r90g=.f1dc3bc9-bd00-4b80-a622-539e7b682367@github.com>
Message-ID: <H1_G5NXIBtmlVx698m2wAZiwi1XTiR3SkgMmeWPxlPM=.4be8c16c-7871-482b-80e9-d12fc9bbd2be@github.com>

On Mon, 31 Oct 2022 19:06:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode` interface methods are modified from `OutputStream` to `DerOutputStream`. All implementations are modified the same way.
>> 
>> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
>> 
>> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   param and override

src/java.base/share/classes/sun/security/x509/Extension.java line 143:

> 141:     }
> 142: 
> 143:     public final void encode(OutputStream out) throws IOException {

Can you also add `@Override` here?

test/jdk/sun/security/pkcs/pkcs9/UnknownAttribute.java line 60:

> 58:             throw new Exception();
> 59:         }
> 60:         DerOutputStream bout = new DerOutputStream();

Nit: change variable name to `dout`. Also on line 78.

test/jdk/sun/security/tools/keytool/ExtOptionCamelCase.java line 206:

> 204:             // extensions (not of a subtype) and we need to store and reload
> 205:             // it to resolve them to subtypes.
> 206:             DerOutputStream bout = new DerOutputStream();

Nit: change variable name to dout.

-------------

PR: https://git.openjdk.org/jdk/pull/10906

From mullan at openjdk.org  Mon Oct 31 19:41:36 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 19:41:36 GMT
Subject: RFR: JDK-8291974 PrivateCredentialPermission should not use local
 variable to enable debugging [v5]
In-Reply-To: <-itDGBpKgVEYd9ZryHAeyV21AC4KDf4YPV4WcalMefg=.c0fe28c3-9c2b-4048-852c-7646f97f55fd@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
 <-itDGBpKgVEYd9ZryHAeyV21AC4KDf4YPV4WcalMefg=.c0fe28c3-9c2b-4048-852c-7646f97f55fd@github.com>
Message-ID: <m3pchi5n17rnWxGJ0s2wF5AyOui3w4WHQ3Ql5GDBjME=.be90d36d-6f1a-44ee-a4cc-5b61a469d54a@github.com>

On Mon, 31 Oct 2022 15:59:28 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers 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 seven additional commits since the last revision:
> 
>  - Merge
>  - implements Serializable
>  - Sean comments
>  - Text Blocks
>  - long line
>  - added test
>  - first iteration

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From weijun at openjdk.org  Mon Oct 31 19:53:32 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 31 Oct 2022 19:53:32 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v5]
In-Reply-To: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
Message-ID: <i-dWsQyaQJ5WQtq5Ic5TElYDZX1CpXKiAXPyzGNLGo8=.f4aee34d-3f38-4780-87cd-7ea62f7c45e3@github.com>

> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode` interface methods are modified from `OutputStream` to `DerOutputStream`. All implementations are modified the same way.
> 
> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
> 
> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  another override and dout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10906/files
  - new: https://git.openjdk.org/jdk/pull/10906/files/c4f17f73..974edb7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10906&range=03-04

  Stats: 20 lines in 3 files changed: 10 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10906.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10906/head:pull/10906

PR: https://git.openjdk.org/jdk/pull/10906

From mullan at openjdk.org  Mon Oct 31 19:58:19 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 19:58:19 GMT
Subject: RFR: 8296072: CertAttrSet::encode and DerEncoder::derEncode should
 write into DerOutputStream [v5]
In-Reply-To: <i-dWsQyaQJ5WQtq5Ic5TElYDZX1CpXKiAXPyzGNLGo8=.f4aee34d-3f38-4780-87cd-7ea62f7c45e3@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
 <i-dWsQyaQJ5WQtq5Ic5TElYDZX1CpXKiAXPyzGNLGo8=.f4aee34d-3f38-4780-87cd-7ea62f7c45e3@github.com>
Message-ID: <PdI9i7Jg4307Wm7GYW_V5vFZuD5nsbELxhGhhfDcbEM=.00a87707-09e8-4c1a-9477-4fc742e86ff0@github.com>

On Mon, 31 Oct 2022 19:53:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The argument of the `CertAttrSet::encode` and `DerEncoder::derEncode` interface methods are modified from `OutputStream` to `DerOutputStream`. All implementations are modified the same way.
>> 
>> `OutputStream` is still used by `sun.security.x509.Extension::encode(OutputStream os)` because it's inherited from `java.security.cert.Extension`. The method is now marked final to avoid accidental override.
>> 
>> In `CertificateExtensions` and `CRLExtensions`, only `Extension::encode(DerOutputStream out)` is called. It used to call `CertAttrSet::encode` for a known extension and `Extension::encode(DerOutputStream out)` for an unknown one. This makes sure the overridden `encode` methods in known extensions are always called. Now that they have the same argument, there is no need for this check.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another override and dout

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10906

From mpowers at openjdk.org  Mon Oct 31 20:00:34 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 31 Oct 2022 20:00:34 GMT
Subject: Integrated: JDK-8291974 PrivateCredentialPermission should not use
 local variable to enable debugging
In-Reply-To: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
References: <3ixdvWKy4Eau-YIe61Z8rEgub32MXI3C_GPBdU5nWpw=.efda1bbf-bfd9-42ee-8f97-fe274512baf0@github.com>
Message-ID: <MVDJkIgNwRcLRwg3yh_XqzyXCnb2WNTU_IzqdCcNzxY=.5ebd1eb2-48de-4d3a-9d7e-f0410d1afb97@github.com>

On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8291974

This pull request has now been integrated.

Changeset: 8480f870
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8480f87044f72e0312add190e75ee27030b7e10a
Stats:     101 lines in 2 files changed: 79 ins; 22 del; 0 mod

8291974: PrivateCredentialPermission should not use local variable to enable debugging

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/10206

From jlaskey at openjdk.org  Mon Oct 31 20:11:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 20:11:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add @SafeVarargs declarations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/75fcc49a..6d1d902e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05-06

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From mullan at openjdk.org  Mon Oct 31 20:31:39 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Oct 2022 20:31:39 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
Message-ID: <QwPK3D8enJxuaRoC_0vXPi2Cjn6mG5ZaFNAikzuXfr4=.3a183696-438e-467b-b987-4090213afc8c@github.com>

On Fri, 28 Oct 2022 18:05:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
>> 
>> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
>> 
>> ## SSLHandshake.java benchmark
>> ### Use secp256r1 as the named group
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
>> 
>> ### Use default TLS named groups
>> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
>> 
>> 
>> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
>> 
>> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
>> 
>> ## KeyPairGenerators.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
>> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
>> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
>> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
>> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
>> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>> 
>> ## Signatures.java benchmark
>> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
>> 
>> Benchmark with this patch:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
>> 
>> 
>> 
>> Benchmark before this patch applied:
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
>> 
>> 
>> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tailing whitespaces

Can you please wait a few days on integrating this? I would like @ferakocz and/or @mcpowers to also look at this.

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From forax at openjdk.org  Mon Oct 31 20:49:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:49:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <ZMO73T5DijZRuY1syZG_RLF5MAYKZP6ExGtpTxCeToo=.a9194cfa-96f0-4a5d-af04-040b692f4842@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 132:

> 130:             return result;
> 131:         }
> 132:         for (Object value : st.values()) {

I think that valueTypes() should return the types of the values not the dynamic classes of the values.
Here there is no type information so it should be Object for all values.

It has also the nice property that the return type of the accessors returned by valueAccessors are the same as valueTypes() which is i believe more coherent.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From xuelei at openjdk.org  Mon Oct 31 20:50:39 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 31 Oct 2022 20:50:39 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <QwPK3D8enJxuaRoC_0vXPi2Cjn6mG5ZaFNAikzuXfr4=.3a183696-438e-467b-b987-4090213afc8c@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
 <QwPK3D8enJxuaRoC_0vXPi2Cjn6mG5ZaFNAikzuXfr4=.3a183696-438e-467b-b987-4090213afc8c@github.com>
Message-ID: <_K8l7N42YxMk-ESgI8dQCs8fGienw8dBnFqDYj2qCpw=.6697fcb9-d2cf-45bf-b73e-d282ec644c7f@github.com>

On Mon, 31 Oct 2022 20:29:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Can you please wait a few days on integrating this? I would like @ferakocz and/or @mcpowers to also look at this.

Sure.  I'd appreciate if the review could be done by the end of this week.

-------------

PR: https://git.openjdk.org/jdk/pull/10893

From forax at openjdk.org  Mon Oct 31 20:54:33 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:54:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 119:

> 117:         Class<?> tsClass = st.getClass();
> 118:         if (tsClass.isSynthetic()) {
> 119:             try {

I do not know if this code is worth of optimizing but the way to avoid to recompute the List<Class<?>> each time is to use a java.lang.ClassValue and store the classes inside an unmodifiable List. (Field[] -> Class<?>[] -> List<Class<?>>) The last leg can be done just by calling List.of(), there is no need for an ArrayList here

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From smarks at openjdk.org  Mon Oct 31 21:25:41 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 31 Oct 2022 21:25:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 99:

> 97:     private static <E> List<E> toList(E... elements) {
> 98:         return JUCA.listFromTrustedArrayNullsAllowed(elements);
> 99:     }

I'm ok with using JUCA to create an unmodifiable list that can contain nulls.

However, it "trusts" the argument array, meaning that the array is assumed to be referenced exclusively and so the array reference is used directly in the resulting List object. That implies that one needs to be very careful about the array that gets passed in, otherwise, the resulting List might not actually be unmodifiable.

In particular, the call site in StringTemplate.of()

https://github.com/openjdk/jdk/pull/10889/files#diff-d4e02e5ead5ad4f2cfe509c58d1145f599285cd6736bbf37e4116045b2fd50bcR309

passes the array obtained from a List parameter that comes directly from a public call, meaning that malicious code could keep a reference to the array returned by `toArray` and modify it later. You could clone the array, or just revert back to the slow path.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From prr at openjdk.org  Mon Oct 31 22:02:15 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 31 Oct 2022 22:02:15 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs 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 four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Deprecate URL constructors.
Developers are encouraged to use java.net.URI to parse or construct any URL.
...
To construct a URL, using URI::toURL should be preferred.

You have jumped through some refactoring hoops to be able to apply the deprecation suppression
to as little code as possible .. having made such changes, then why didn't you just make the
recommended change instead ?

Should I presume that the recommended route will have some nasty little incompatibilities
we will need to be careful of first ?

And what about Peter Firmstone's comment
"We stopped using java.net.URI some years ago as it's obsolete.?"

I can't reconcile that with the recommendation to use it ..

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From ckozak at ckozak.net  Mon Oct 31 23:51:45 2022
From: ckozak at ckozak.net (Carter Kozak)
Date: Mon, 31 Oct 2022 19:51:45 -0400
Subject: TLS Performance Regression in JDK18+
Message-ID: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>

Hello,

TLS performance has appreciably regressed in JDK-18 and JDK-19 from earlier releases using TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 ciphers. I suspect the throughput reduction is in part related to the substantial increase in allocation per operation by roughly the size of the content transferred, even in cases where the contents are provided using direct byte-buffers.

I've created a simple JMH benchmark using the socket API here:
https://github.com/carterkozak/java-crypto-allocation-performance#java-cryptography-allocations

JMH JSON results across JDK releases are located here:
https://github.com/carterkozak/java-crypto-allocation-performance/tree/develop/jmh-results

I'm sorry if this has already been reported or is otherwise already being tracked. Please let me know if additional information would be helpful.

Best,
Carter Kozak