From duke at openjdk.org  Tue Nov  1 00:06:35 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 1 Nov 2022 00:06:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@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>
 <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>
Message-ID: <QTuXZCQBCHnfr-n7W3F7K3vEr88fCuQVsvRcikoTbOM=.020347ed-48ee-4beb-97e6-60ab0f5f4da9@github.com>

On Fri, 28 Oct 2022 20:04:18 GMT, R?mi Forax <forax at openjdk.org> wrote:

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

If this is a public int field, it will be inlined to class file byte code at compile time, which may not be what you want if this value needs to change in the future. If this needs to be exposed, should it be as a public method?

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

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


From duke at openjdk.org  Tue Nov  1 00:25:35 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 1 Nov 2022 00:25:35 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: <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@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/runtime/TemplateSupport.java line 201:

> 199:     @SuppressWarnings("unchecked")
> 200:     public static <E> List<E> toList(E... elements) {
> 201:         return JUCA.listFromTrustedArrayNullsAllowed(elements);

Is this public method leaking access to the JUCA shared secrets method here?

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

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


From peter.firmstone at zeus.net.au  Tue Nov  1 00:50:59 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 1 Nov 2022 10:50:59 +1000
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
Message-ID: <3483f95b-8b2d-7cbd-5cbd-b959dda2eaf8@zeus.net.au>

Some additional information that may be helpful:

org.apache.river.api.net.Uri has method signatures in common with 
java.net.URI, due to its development history.

    The implementation was originally part of Apache Harmony which was
    RFC2396 compliant (Harmony's implementation of java.net.URI), it was
    copied and updated to RFC3986 in Apache River, breaking
    compatibility with RFC2396, both projects are now in Apache Attic
    (no longer under development).?? JGDMS (a fork of Apache River, also
    known as Jini donated by Sun Microsystems to Apache) added support
    for RFC5952 and RFC6874. The provenance / development history is known.

    Implementation classes:

    https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/URIEncoderDecoder.java

    https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java

    https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/UriParser.java

org.apache.river.api.net.Uri is not Serializable, however java.net.Uri 
only has one serializable field.

If you wanted to document and understand what RFC3986 breaks in the JDK, 
it would be possible to temporarily copy paste the implementation of 
org.apache.river.api.net.Uri into java.net.URI and run the test suite.

That might assist in deciding whether to update java.net.URI or to 
create a new URI RFC3986 implementation leaving java.net.URI as it is 
and deprecating it.

Regards,

Peter.


On 1/11/2022 8:02 am, Phil Race wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221101/62d4f609/attachment.htm>

From alanb at openjdk.org  Tue Nov  1 06:52:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 06:52:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
Message-ID: <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>

On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:

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

Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think.

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

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


From peter.firmstone at zeus.net.au  Tue Nov  1 08:07:11 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 1 Nov 2022 19:07:11 +1100
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
 <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>
Message-ID: <bdecb2f9-b1a9-332f-58a2-4ff0ce75706c@zeus.net.au>

On 1/11/2022 5:52 pm, Alan Bateman wrote:
> On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:
>
>> 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 ?
> Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think.

We found there were some common cases, we made static convenience 
methods to address them:

Fix MS Windows file URI strings, by converting back slashes to forward 
slashes and inserting a forward slash before the drive letter if missing.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L289

Convert java.io.File to Uri, ensure compatibility with URLClassLoader, 
when trailing directory character is dropped by java.io.File.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L341

Escape illegal characters when string doesn't contain any existing 
escape sequences.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L926

Parse and fix a string that contains escaped sequences, any illegal 
characters are escaped and any that should't be escaped are un-escaped.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L939

Convert java.net.URL to Uri, automatically fixing MS Windows URI syntax.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L324

Cheers,

Peter.


>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10874


From mcimadamore at openjdk.org  Tue Nov  1 11:04:52 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 11:04:52 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@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>
 <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@github.com>
Message-ID: <2vjNyFDHkuJn2pRmWoJcBcUBkAA9IXtpSgkELnAq6zo=.8d159c9e-6779-4ddf-9c9e-f96b7efcfaae@github.com>

On Fri, 28 Oct 2022 19:18:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

I'm looking at this line:

Type resultType = syms.stringTemplateType;

This assumes that the result type of this AST node will be StringTemplate. Now, if a processor is set, we'll call `chk.checkProcessorType` which *might* set a new expected type (e.g. a string processor type). But if any error is found in that routine (e.g. use of raw string processor), we just log an error, and return the same expected type that was passed in - so the expected type stays `StringTemplate`.

Something like this:

public class Processor<X> implements TemplateProcessor<X> { ... }


Processor raw = new Processor();
String s = raw."1234".

This will probably print a spurious error like "expected String, found StringTemplate".

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

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


From mcimadamore at openjdk.org  Tue Nov  1 11:04:53 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 11:04:53 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: <S6-VeYs6tNcuaIQrAhTtdeqKKYWLQrf6uePPW8FcVhs=.47ea1f24-2f75-4919-b506-fd37ab972c71@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/jdk.compiler/share/classes/com/sun/tools/javac/parser/Scanner.java line 100:

> 98:         private void ensureLookahead(int lookahead) {
> 99:             for (int i = savedTokens.size() ; i < lookahead ; i++) {
> 100:                 Token ahead = tokenizer.readToken();

curious - why this change?

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

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


From dfuchs at openjdk.org  Tue Nov  1 12:21:13 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 12:21:13 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: <A4qnEed0y9IwAfcxrUtVyXLkcuaHKUlwps8MVVFUAyw=.042a86fd-8c9c-498d-8172-606712c83849@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 to java (resp sun) .util.logging tests and javax.management tests look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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


From weijun at openjdk.org  Tue Nov  1 12:53:33 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 1 Nov 2022 12:53:33 GMT
Subject: Integrated: 8296072: CertAttrSet::encode and DerEncoder::derEncode
 should write into DerOutputStream
In-Reply-To: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
References: <ESiosDf6pSkK5Ect5SvP7SD1VaXsFvWN7vRsihR-hrg=.fe5e7b54-f0ce-4771-91be-480922c6ecff@github.com>
Message-ID: <uUDcXSOqQA_-967a9A-MgcPglSdqPixCqzIDbnnd0Fo=.caec7fa2-061a-4b55-a1ec-acb721b27599@github.com>

On Fri, 28 Oct 2022 18:20:08 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.

This pull request has now been integrated.

Changeset: 0d0bd7bd
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d0bd7bd409c0caa5edebe3d1eacf8e5bb48f984
Stats:     342 lines in 50 files changed: 28 ins; 133 del; 181 mod

8296072: CertAttrSet::encode and DerEncoder::derEncode should write into DerOutputStream

Reviewed-by: xuelei, mullan

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

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


From mcimadamore at openjdk.org  Tue Nov  1 13:04:27 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 13:04:27 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: <dcLd-zWzGaQVnWjmp11so1ztAQEcqO3MmjAd5ybPUtk=.57e92e67-1d02-42e5-b32d-cde2a2ccd123@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/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 230:

> 228: 
> 229:     class TransStringTemplate {
> 230:         JCStringTemplate tree;

Presumably some of these can be `final` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429:

> 427:         }
> 428: 
> 429:         private JCClassDecl newStringTemplateClass() {

I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 555:

> 553:                 if (varSym.flags() == (PUBLIC | FINAL | STATIC) &&
> 554:                         varSym.name == names.str &&
> 555:                         types.isSameType(varSym.owner.type, syms.stringTemplateType)) {

Are you 100% sure that this test works? When we see a statically imported member in Resolve, which is referred to by unqualified name, we "clone" its symbol into the importing class. That is, Resolve will set STR symbol as a symbol whose owner is the class that did the importing, possibly defeating this check. See Resolve::findVar (near the end):


if (bestSoFar.kind == VAR && bestSoFar.owner.type != origin.type)
            return bestSoFar.clone(origin);

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

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


From mcimadamore at openjdk.org  Tue Nov  1 13:16:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 13:16:40 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: <BHNtvQ5p7s-mcwUoI07O90IT4jSs7tOcAsL2oZx1DfQ=.6bf3bf5d-59ea-4dc0-b0b1-98396a054304@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/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 355:

> 353:         // If first embedded expression.
> 354:         if (!isStringTemplate) {
> 355:             checkSourceLevel(pos, Feature.STRING_TEMPLATES);

If we check source level inside the `if`, we would only issue a preview error/warning once, which seems to be against JEP 12?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244:

> 242:      *     mode |= NOLAMBDA     : lambdas are not allowed
> 243:      */
> 244:     protected static final int EXPR          = 1 << 0;

I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244:

> 242:      *     mode |= NOLAMBDA     : lambdas are not allowed
> 243:      */
> 244:     protected static final int EXPR          = 1 << 0;

I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here (perhaps we should consider factoring it out?)

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

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


From weijun at openjdk.org  Tue Nov  1 13:42:13 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 1 Nov 2022 13:42:13 GMT
Subject: RFR: 8296142: CertAttrSet::(getName|getElements|delete) are mostly
 useless
Message-ID: <gCjGZ3L1xf4n4x9KXpskZ3EZhQdSBCTGN7TeunB1tbo=.764f7164-b96d-4822-a0ef-6333eab308e5@github.com>

This code change removes `getElements()` and `delete()` from `CertAttrSet` and all its subclasses. The `getName()` method is moved to `s.s.x.Extension` since it's only useful there.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/10934/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296142
  Stats: 1191 lines in 41 files changed: 33 ins; 1135 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/10934.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10934/head:pull/10934

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


From dfuchs at openjdk.org  Tue Nov  1 13:53:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 13:53:37 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
Message-ID: <YyjbpXQ4Nu8hejOV6lg2bwd-Hfk3-9MEAIUuyCKS3cM=.9e689d36-46fd-4f84-8da0-85dd682196bf@github.com>

On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:

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

Possibly yes. Using URI where it was not used before might cause some behavioral changes, that would need to be examined and possibly documented through separate CSRs. This is better handled on a case-by-case basis
for each area affected. The changes as currently proposed will not lead to any behavioral difference.

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

URI implements RFC 2396 with some deviations, noted in its API documentation, which make it a crossbreed between RFC 2396 and RFC 3986. As Alan noted earlier, 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. But even if it doesn't implement the latest RFC strictly, it's still a much more modern API and implementation than java.net.URL.

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

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


From dfuchs at openjdk.org  Tue Nov  1 13:53:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 13:53:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <GCXHo9bR0jQRKe-qvdgEDkPzvc0zgS6sIlTQ-PiWzmA=.fd82872c-c1c5-4ffa-b602-a4bc60bedc19@github.com>

On Sat, 29 Oct 2022 14:14:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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 885:
> 
>> 883: 
>> 884:             @SuppressWarnings("deprecation")
>> 885:             var result = new URL("jrt", host, port, file, null);
> 
> The URL scheme for jrt does not have a port so we should look at that some time.

Noted.

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

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


From dfuchs at openjdk.org  Tue Nov  1 14:00:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:00:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <nB3e9AXOx2rm5qSOhYjm7XRQn4wvLkt2y4VckMIziCY=.95686450-68bc-4d3d-9956-ab722063f00d@github.com>

On Sat, 29 Oct 2022 14:16:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

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

done

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

done

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

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


From dfuchs at openjdk.org  Tue Nov  1 14:08:17 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:08:17 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <qCuvc99MQHsNXJh946nVOGlDNWoK-k-iahtS18-I8v4=.ee61f634-b6d1-46c2-9084-2df739c76d9f@github.com>

On Sat, 29 Oct 2022 14:17:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

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

done

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

I don't believe it would be syntactically correct to put it in all lower case since URL is an acronym.  I could replace it with "URI string" instead but I'm not sure it would be better. What do you think?

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

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


From dfuchs at openjdk.org  Tue Nov  1 14:12:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:12:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>

On Sat, 29 Oct 2022 14:24:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

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

To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.

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

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


From dfuchs at openjdk.org  Tue Nov  1 14:26:09 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:26:09 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
Message-ID: <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>

On Tue, 1 Nov 2022 14:10:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> 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?
>
> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.

Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?

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

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


From alanb at openjdk.org  Tue Nov  1 14:44:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 14:44:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@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>
 <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@github.com>
Message-ID: <Q7d2xx2hXPx4tY0Urt542HpC_ELdT16sbXObSrHtiNs=.3519f63e-f70b-4a1f-ba98-feda371c3a8d@github.com>

On Mon, 31 Oct 2022 13:45:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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`.

The change to JUCA means the suppress warnings will need to be extended to @SuppressWarnings({"unchecked", "varargs"}).

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

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


From alanb at openjdk.org  Tue Nov  1 14:51:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 14:51:20 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
 <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
Message-ID: <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>

On Tue, 1 Nov 2022 14:22:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.
>
> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?

Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message.

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

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


From jlahoda at openjdk.org  Tue Nov  1 15:33:38 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 1 Nov 2022 15:33:38 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: <4jrJpr-CNMkKjBDlIVscDNqLmxyt7mh_Oz5cU8vfRWY=.e1310ec2-f363-4016-818c-5c869abb270e@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/util/FormatConcatItem.java line 51:

> 49:  */
> 50: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 51: public sealed interface FormatConcatItem

I wonder why is this a public API - is there some way to use it from the client code?

Note that in named modules, the permitted subtypes don't need to be in the same package, so if this is not needed in the API, it probably can be moved into a non-API package.

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

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


From dfuchs at openjdk.org  Tue Nov  1 16:14:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:14:20 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
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: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@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 six additional commits since the last revision:

 - Integrated review feedback
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - 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/fd4ca287..f6b8a9f9

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

  Stats: 3893 lines in 203 files changed: 2469 ins; 611 del; 813 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 prr at openjdk.org  Tue Nov  1 16:14:21 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 1 Nov 2022 16:14:21 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <aRKJABG81VEtvU3_sEh-c0yfIQ8SDYp0PFm_TSTRV_M=.2f254387-cd5a-4309-81c0-8a240ef8ecc4@github.com>

On Tue, 1 Nov 2022 16:10:47 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - 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

Marked as reviewed by prr (Reviewer).

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

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


From dfuchs at openjdk.org  Tue Nov  1 16:14:22 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:14:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
 <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
 <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>
Message-ID: <2jUuJ4BHyWYygw4wAlZbgMBsxCyVgAOfhNFPl31yKLY=.5c5e0a58-e270-4e95-8cb6-d0c5f7a3bc23@github.com>

On Tue, 1 Nov 2022 14:47:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?
>
> Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message.

Done.

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

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


From mpowers at openjdk.org  Tue Nov  1 17:45:31 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 1 Nov 2022 17:45:31 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: <_ewK0zRhWxQbLDV3_G5c_4_h_-tnu5g1mXaSeTHemgE=.22352f5b-7cc9-461c-af6f-afd769277ec3@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

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 588:

> 586:                 //
> 587:                 // This is a 4 dimensions table, and each dimension contains
> 588:                 // 16 elements. For the 1st demension, each element in it is

s/demension/dimension/

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

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


From mcimadamore at openjdk.org  Tue Nov  1 17:48:49 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Nov 2022 17:48:49 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: <4bgm2-JFThFb9QUw8ysIbkh7V4HX65CC5mInOeLn-dY=.168bd4bd-772f-46a6-920e-4ed616ba714b@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/util/FormatProcessor.java line 118:

> 116: 
> 117:     // %[argument_index$][flags][width][.precision][t]conversion
> 118:     private static final String formatSpecifier

Should this be all upper case?

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

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


From mullan at openjdk.org  Tue Nov  1 18:22:33 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 1 Nov 2022 18:22:33 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v3]
In-Reply-To: <trudxaHDBPwC6dzxGz2FtsgoUpY8om5fJATF3ftmBXU=.3b198720-348c-4f21-b5c6-8939c7b286a3@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <iHPbjDO8P0yefoA4KL3YAnftJDqasDuGmYxCoRJ3Jfg=.b42e45e2-4127-46ff-adc8-89c49633772b@github.com>
 <trudxaHDBPwC6dzxGz2FtsgoUpY8om5fJATF3ftmBXU=.3b198720-348c-4f21-b5c6-8939c7b286a3@github.com>
Message-ID: <Exns5Wyhjc9f9lvhBEwiZTh1Nei0k7PJL2Ekm4nDpKs=.309b9b56-2675-49c7-a79d-26280358762b@github.com>

On Thu, 27 Oct 2022 10:04:07 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

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

Yes, that code should ideally go through `CertificateFactory` and not call `new X509CertImpl` directly.

There's some old code in `sun.security.pkcs.PKCS7` that also calls `new X509CertImpl` if it cannot instantiate an X.509 `CertificateFactory`, but I think that code can be removed since an "X.509" `CertificateFactory` is a requirement.

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

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


From jlaskey at openjdk.org  Tue Nov  1 18:24:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 18:24:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@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>
 <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com>
Message-ID: <qeVWx0O3Uodm8cqI9DsQR-T9W6wtRhf7yDXJg4vSR74=.074252d7-22fb-4a82-bf11-d110eafabfe4@github.com>

On Mon, 31 Oct 2022 15:51:23 GMT, R?mi Forax <forax at openjdk.org> wrote:

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

Will add

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

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


From jlaskey at openjdk.org  Tue Nov  1 18:24:39 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 18:24:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@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>
 <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com>
Message-ID: <d48-KkrDKD1cg9YNiUQFYZD-r659x0GrP3BCMQTB1w0=.32059cf8-4c92-49aa-a53d-a404126f6698@github.com>

On Mon, 31 Oct 2022 13:43:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> 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`.

Moved to internal class.

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

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


From jlaskey at openjdk.org  Tue Nov  1 18:24:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 18:24:40 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>
Message-ID: <sJ_JQLbsGTLg3GpeMd6h205DuElxFynL29KdPIVZdxA=.8f9cfbd5-ca51-48c3-8319-c2e095ba2931@github.com>

On Mon, 31 Oct 2022 20:50:49 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:
>> 
>>   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

Will use List.of. I think use case is raw and caching should be left to the user.

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

Changing

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

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


From jlaskey at openjdk.org  Tue Nov  1 19:09:41 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 1 Nov 2022 19:09:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
 <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>
Message-ID: <Dl3GU7GWMu6NP7rbyVcf40jToUYgB0k0i7lw9WuNR2Q=.ac7cc25b-96dd-4868-b991-132cf4b07cad@github.com>

On Mon, 31 Oct 2022 21:23:19 GMT, Stuart Marks <smarks at openjdk.org> wrote:

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

Changing caller

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

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


From xuelei at openjdk.org  Tue Nov  1 19:10:13 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 1 Nov 2022 19:10:13 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@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:

  typo correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10893/files
  - new: https://git.openjdk.org/jdk/pull/10893/files/aa224efc..37aa43da

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

  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 xuelei at openjdk.org  Tue Nov  1 19:10:15 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 1 Nov 2022 19:10:15 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <_ewK0zRhWxQbLDV3_G5c_4_h_-tnu5g1mXaSeTHemgE=.22352f5b-7cc9-461c-af6f-afd769277ec3@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
 <_ewK0zRhWxQbLDV3_G5c_4_h_-tnu5g1mXaSeTHemgE=.22352f5b-7cc9-461c-af6f-afd769277ec3@github.com>
Message-ID: <hEJIsQVamvKbCgXfqbx58SO3z8Vg82hr58znkVVHT6E=.cb057837-32f4-464d-8434-802d37aad299@github.com>

On Tue, 1 Nov 2022 17:43:22 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove tailing whitespaces
>
> src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 588:
> 
>> 586:                 //
>> 587:                 // This is a 4 dimensions table, and each dimension contains
>> 588:                 // 16 elements. For the 1st demension, each element in it is
> 
> s/demension/dimension/

Thank you for the catch.  Updated in the latest patch.

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

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


From anthony.scarpino at oracle.com  Tue Nov  1 19:19:45 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 1 Nov 2022 12:19:45 -0700
Subject: TLS Performance Regression in JDK18+
In-Reply-To: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
Message-ID: <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>

Hi Carter,

I'll have to review your data more and look into it.

thanks

Tony

On 10/31/22 4:51 PM, Carter Kozak wrote:
> 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


From mpowers at openjdk.org  Tue Nov  1 23:03:19 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 1 Nov 2022 23:03:19 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <dTz0jfrguiXfoR7QKt9gbDySZvM2t1nn-GQmHOZPi7o=.e731410f-9a54-4cfc-b14b-3a5467c9461d@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
 <dTz0jfrguiXfoR7QKt9gbDySZvM2t1nn-GQmHOZPi7o=.e731410f-9a54-4cfc-b14b-3a5467c9461d@github.com>
Message-ID: <KT0fZCxNVH2RXahc1Z1EOZV42_0LGm8aDXSXCQ5D7lw=.ec4534a7-ab0c-461a-9e8c-b3a1e5f1e758@github.com>

On Mon, 31 Oct 2022 17:33:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Anyone from Oracle can help me to run Mach5 testing, just in case I missed something?

Do you have any specific mach5 tests in mind?

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

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


From vlivanov at openjdk.org  Tue Nov  1 23:34:34 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Nov 2022 23:34:34 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
Message-ID: <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>

On Fri, 28 Oct 2022 20:39:44 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:
> 
>   invalidkeyexception and some review comments

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 970:

> 968: 
> 969:   void addmq(int disp, Register r1, Register r2);
> 970: 

All Poly1305-related methods can be moved to `StubGenerator`. They are used solely during stub creation.

src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 32:

> 30: #include "macroAssembler_x86.hpp"
> 31: 
> 32: #ifdef _LP64

You could rename the file to `macroAssembler_x86_64_poly.cpp` and get rid of `#ifdef _LP64`.
Once you move the declarations to `StubGenerator`, it'll be `stubGenerator_x86_64_poly.cpp`.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2002:

> 2000: }
> 2001: 
> 2002: address StubGenerator::generate_poly1305_masksCP() {

I suggest to turn it into a C++ literal constant and move the declaration next to `poly1305_process_blocks_avx512` where they are used. As an example, here's how it is handled in GHASH stubs:
  https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp#L35

That would allow to avoid to simplify the code a bit (no need in `StubRoutines::x86::_poly1305_mask_addr`/`poly1305_mask_addr()` and no need to generate the constants during VM startup).

You could split it into 3 constants, but then using a single base register (`polyCP`) won't work anymore.
Thinking more about it, I'm not sure why you can't just do the split and use address literals instead  to access individual constants (and repurpose `r13` to be used as a scratch register when RIP-relative addressing mode doesn't work).

src/hotspot/share/runtime/globals.hpp line 241:

> 239:           "Use intrinsics for java.util.Base64")                            \
> 240:                                                                             \
> 241:   product(bool, UsePolyIntrinsics, false,                                   \

I'm not a fan of introducing new flags for individual intrinsics (there's already `-XX:DisableIntrinsic=_name` specifically for that), but since we already have many, shouldn't it be declared as a diagnostic flag, at least?

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

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


From vlivanov at openjdk.org  Tue Nov  1 23:34:34 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Nov 2022 23:34:34 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <Cju0XRYyqdeVeZZEpttxF9eUX02aQ0UM3CfD5uIe0OI=.6057ecb9-c80f-4eef-8aae-9f8748bc8f6c@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>
 <Cju0XRYyqdeVeZZEpttxF9eUX02aQ0UM3CfD5uIe0OI=.6057ecb9-c80f-4eef-8aae-9f8748bc8f6c@github.com>
Message-ID: <4HxTb1DtD6KeuYupOKf32GoQ7SV8_EjHcqfhiZhbLHM=.884e631a-1336-454d-aae1-06f85f784381@github.com>

On Fri, 28 Oct 2022 20:19:35 GMT, vpaprotsk <duke at openjdk.org> wrote:

> And just looking now on uops.info, they seem to have identical timings?

Actual instruction being used (aligned vs unaligned versions) doesn't matter much here, because it's a dynamic property of the address being accessed: misaligned accesses that cross cache line boundary incur a penalty. Since the cache line size is 64 byte in size, every misaligned 512-bit access is penalized.

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

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


From vlivanov at openjdk.org  Tue Nov  1 23:51:27 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Nov 2022 23:51:27 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
 <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
Message-ID: <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>

On Tue, 1 Nov 2022 23:17:46 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   invalidkeyexception and some review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2002:
> 
>> 2000: }
>> 2001: 
>> 2002: address StubGenerator::generate_poly1305_masksCP() {
> 
> I suggest to turn it into a C++ literal constant and move the declaration next to `poly1305_process_blocks_avx512` where they are used. As an example, here's how it is handled in GHASH stubs:
>   https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp#L35
> 
> That would allow to avoid to simplify the code a bit (no need in `StubRoutines::x86::_poly1305_mask_addr`/`poly1305_mask_addr()` and no need to generate the constants during VM startup).
> 
> You could split it into 3 constants, but then using a single base register (`polyCP`) won't work anymore.
> Thinking more about it, I'm not sure why you can't just do the split and use address literals instead  to access individual constants (and repurpose `r13` to be used as a scratch register when RIP-relative addressing mode doesn't work).

The case of AES stubs may be even a better fit here:
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp#L47

It doesn't use/introduce any shared constants, so declaring a constant and a local accessor (to save on pointer to address casts at use sites) is enough.

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

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


From xuelei at openjdk.org  Wed Nov  2 00:18:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 2 Nov 2022 00:18:30 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v3]
In-Reply-To: <KT0fZCxNVH2RXahc1Z1EOZV42_0LGm8aDXSXCQ5D7lw=.ec4534a7-ab0c-461a-9e8c-b3a1e5f1e758@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <hO52ozVljTjUZJ8FwOgOpYPKMZ8PjSu8ENnbUc-ZfgE=.6575522f-5730-4bdd-8bad-7eb9af036e4d@github.com>
 <dTz0jfrguiXfoR7QKt9gbDySZvM2t1nn-GQmHOZPi7o=.e731410f-9a54-4cfc-b14b-3a5467c9461d@github.com>
 <KT0fZCxNVH2RXahc1Z1EOZV42_0LGm8aDXSXCQ5D7lw=.ec4534a7-ab0c-461a-9e8c-b3a1e5f1e758@github.com>
Message-ID: <92kSqFoBVp3n_8AJx8xi27g68YiH2hUc3-MwvLKYWbU=.47c0cd1b-c1bd-4935-93fb-74bfb530cabe@github.com>

On Tue, 1 Nov 2022 22:59:14 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> > Anyone from Oracle can help me to run Mach5 testing, just in case I missed something?
> 
> Do you have any specific mach5 tests in mind?

Please have tier 1 and tier2 covered.  Thanks!

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

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


From duke at openjdk.org  Wed Nov  2 02:38:26 2022
From: duke at openjdk.org (vpaprotsk)
Date: Wed, 2 Nov 2022 02:38:26 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
 <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
 <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>
Message-ID: <lCes6gQoLqfh4z11XRcIFER_tou6ul62vcVWjW8bTdY=.fc739f71-b362-4a03-8173-b36161610457@github.com>

On Tue, 1 Nov 2022 23:49:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2002:
>> 
>>> 2000: }
>>> 2001: 
>>> 2002: address StubGenerator::generate_poly1305_masksCP() {
>> 
>> I suggest to turn it into a C++ literal constant and move the declaration next to `poly1305_process_blocks_avx512` where they are used. As an example, here's how it is handled in GHASH stubs:
>>   https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp#L35
>> 
>> That would allow to avoid to simplify the code a bit (no need in `StubRoutines::x86::_poly1305_mask_addr`/`poly1305_mask_addr()` and no need to generate the constants during VM startup).
>> 
>> You could split it into 3 constants, but then using a single base register (`polyCP`) won't work anymore.
>> Thinking more about it, I'm not sure why you can't just do the split and use address literals instead  to access individual constants (and repurpose `r13` to be used as a scratch register when RIP-relative addressing mode doesn't work).
>
> The case of AES stubs may be even a better fit here:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp#L47
> 
> It doesn't use/introduce any shared constants, so declaring a constant and a local accessor (to save on pointer to address casts at use sites) is enough.

I wonder if I can remove that function completely now..

Originally I kept those in memory, because I was rather tight on zmm registers (actually, all registers), and I could use the `Address` version of instructions to save a register.. But I had done a mayor cleanup on register allocation before pushing the PR, maybe there is room now. (But if we do want to bring back any of the optimizations I kept back, we would need those registers again.. but will see)

PS: I am trying to address 10% degradation @jnimeh and I discussed above, will take a few days to implement the latest round. Apologies for the delay and appreciate the review!

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

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


From jbhateja at openjdk.org  Wed Nov  2 03:19:04 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Nov 2022 03:19:04 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <4HxTb1DtD6KeuYupOKf32GoQ7SV8_EjHcqfhiZhbLHM=.884e631a-1336-454d-aae1-06f85f784381@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>
 <Cju0XRYyqdeVeZZEpttxF9eUX02aQ0UM3CfD5uIe0OI=.6057ecb9-c80f-4eef-8aae-9f8748bc8f6c@github.com>
 <4HxTb1DtD6KeuYupOKf32GoQ7SV8_EjHcqfhiZhbLHM=.884e631a-1336-454d-aae1-06f85f784381@github.com>
Message-ID: <mymD7nKP6xLz1XoansrlVbhxo6EK0Zefc5OJ_WFyf3g=.33270ab8-22af-4cc3-b0ca-eb364624925a@github.com>

On Tue, 1 Nov 2022 23:04:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> 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'?
>
>> And just looking now on uops.info, they seem to have identical timings?
> 
> Actual instruction being used (aligned vs unaligned versions) doesn't matter much here, because it's a dynamic property of the address being accessed: misaligned accesses that cross cache line boundary incur a penalty. Since the cache line size is 64 byte in size, every misaligned 512-bit access is penalized.

I collected performance counters for the benchmark included with the patch and its showing around 30% of 64 byte loads were spanning across the cache line.

 Performance counter stats for 'java -jar target/benchmarks.jar -f 1 -wi 1 -i 2 -w 30 -p dataSize=8192':

      122385646614      cycles                                                      
      328096538160      instructions              #    2.68  insn per cycle         
       64530343063      MEM_INST_RETIRED.ALL_LOADS                                   
       22900705491      MEM_INST_RETIRED.ALL_STORES                                   
       19815558484      MEM_INST_RETIRED.SPLIT_LOADS                                   
         701176106      MEM_INST_RETIRED.SPLIT_STORES    

Presence of scalar peel loop before the vector loop can save this penalty. 
We should also extend the scope of optimization (preferably in this PR or in subsequent one) to optimize [MAC computation routine accepting ByteBuffer.](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java#L116),

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

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


From mpowers at openjdk.org  Wed Nov  2 04:42:48 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 2 Nov 2022 04:42:48 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
Message-ID: <XhP8MrVBNuefJeUxRIvdYqk9150u4js-HDzJXbruSvM=.e76cce2a-e3fd-4a97-974d-2d769b31542e@github.com>

On Tue, 1 Nov 2022 19:10:13 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:
> 
>   typo correction

tier1 and tier2 tests all pass

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

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


From xuelei at openjdk.org  Wed Nov  2 04:42:49 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 2 Nov 2022 04:42:49 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <XhP8MrVBNuefJeUxRIvdYqk9150u4js-HDzJXbruSvM=.e76cce2a-e3fd-4a97-974d-2d769b31542e@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
 <XhP8MrVBNuefJeUxRIvdYqk9150u4js-HDzJXbruSvM=.e76cce2a-e3fd-4a97-974d-2d769b31542e@github.com>
Message-ID: <-ICyaZicLSQ7kvWHqKEyDqMDH0Op8S-8vEoaoQthjjU=.67980050-ffd1-4f2f-bf16-79e77c6a76a4@github.com>

On Wed, 2 Nov 2022 04:37:44 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> tier1 and tier2 tests all pass

Thank you very much, @mcpowers!  Please let me know if you need more time for the review.

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

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


From duke at openjdk.org  Wed Nov  2 08:18:31 2022
From: duke at openjdk.org (duke)
Date: Wed, 2 Nov 2022 08:18:31 GMT
Subject: Withdrawn: 8281236: (D)TLS key exchange named groups
In-Reply-To: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
Message-ID: <fF4XbSOh53FKyydsN_eEP17MSLqC79LkNTAhAn2cWMQ=.c92d1676-636e-4f78-8e13-021dc1546986@github.com>

On Fri, 5 Aug 2022 14:57:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.org/browse/JDK-8291950
> RFE: https://bugs.openjdk.org/browse/JDK-8281236
> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
> 
> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)

This pull request has been closed without being integrated.

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

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


From rhalade at openjdk.org  Wed Nov  2 08:24:37 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 2 Nov 2022 08:24:37 GMT
Subject: RFR: 8245654: Add Certigna Root CA [v3]
In-Reply-To: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
References: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
Message-ID: <9gPtmstqCcl5jO5Kq9B7I2fa621wf6dMyd1Ccgvsx2s=.0dc9a5ed-140a-45e7-8001-78ad6ac7e369@github.com>

> This fix adds Certigna root CA to cacerts trust store.

Rajan Halade 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:

 - Merge branch 'openjdk:master' into 8247698-certigna
 - Merge branch 'master' into 8247698-certigna
 - remove control-M characters
 - Added Certigna CA cert and updated VerifyCACerts.java test
 - Merge remote-tracking branch 'origin/master' into 8247698-certigna
 - 8247698: Evaluate the inclusion of DHIMYOTIS (certigna) roots

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10030/files
  - new: https://git.openjdk.org/jdk/pull/10030/files/19a5d3ef..caa4e356

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

  Stats: 302893 lines in 4306 files changed: 169354 ins; 83821 del; 49718 mod
  Patch: https://git.openjdk.org/jdk/pull/10030.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10030/head:pull/10030

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


From alanb at openjdk.org  Wed Nov  2 12:22:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Nov 2022 12:22:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <Qnv25No1OKTGQ8SRg0TCExRCbZB5h0Izs5vhqAWDTAQ=.66d04bd1-9cb0-4b92-b2ae-a27ee3d8c24d@github.com>

On Tue, 1 Nov 2022 16:14:20 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - 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

Marked as reviewed by alanb (Reviewer).

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

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


From mullan at openjdk.org  Wed Nov  2 13:16:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 2 Nov 2022 13:16:30 GMT
Subject: RFR: 8245654: Add Certigna Root CA [v3]
In-Reply-To: <9gPtmstqCcl5jO5Kq9B7I2fa621wf6dMyd1Ccgvsx2s=.0dc9a5ed-140a-45e7-8001-78ad6ac7e369@github.com>
References: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
 <9gPtmstqCcl5jO5Kq9B7I2fa621wf6dMyd1Ccgvsx2s=.0dc9a5ed-140a-45e7-8001-78ad6ac7e369@github.com>
Message-ID: <A78049cHlLO0ZM3OzVNc122fav86UsZRRJlnenZl0BY=.106453a9-d448-4346-832a-604b9cb049a6@github.com>

On Wed, 2 Nov 2022 08:24:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> This fix adds Certigna root CA to cacerts trust store.
>
> Rajan Halade 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:
> 
>  - Merge branch 'openjdk:master' into 8247698-certigna
>  - Merge branch 'master' into 8247698-certigna
>  - remove control-M characters
>  - Added Certigna CA cert and updated VerifyCACerts.java test
>  - Merge remote-tracking branch 'origin/master' into 8247698-certigna
>  - 8247698: Evaluate the inclusion of DHIMYOTIS (certigna) roots

src/java.base/share/data/cacerts/certignaca line 5:

> 3: Serial number: fedce3010fc948ff
> 4: Valid from: Fri Jun 29 15:13:05 GMT 2007 until: Tue Jun 29 15:13:05 GMT 2027
> 5: Signature algorithm name: SHA1withRSA (weak)

Don't include "(weak)" in this line. The signature algorithm of root certificates is not a security issue, since the certificate fingerprint has been verified and the public key is trusted directly.

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

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


From mullan at openjdk.org  Wed Nov  2 14:10:27 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 2 Nov 2022 14:10:27 GMT
Subject: RFR: 8296142: CertAttrSet::(getName|getElements|delete) are mostly
 useless
In-Reply-To: <gCjGZ3L1xf4n4x9KXpskZ3EZhQdSBCTGN7TeunB1tbo=.764f7164-b96d-4822-a0ef-6333eab308e5@github.com>
References: <gCjGZ3L1xf4n4x9KXpskZ3EZhQdSBCTGN7TeunB1tbo=.764f7164-b96d-4822-a0ef-6333eab308e5@github.com>
Message-ID: <MhJm9qV9RqaoZNKDBQNgwg5X3XUpI1Iyu8Ml6uKlrGM=.ebf0bb5f-4b40-414b-924a-8929b13a8a0c@github.com>

On Tue, 1 Nov 2022 13:34:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change removes `getElements()` and `delete()` from `CertAttrSet` and all its subclasses. The `getName()` method is moved to `s.s.x.Extension` since it's only useful there.
> 
> Except for removing lines, the only place where real changes are made are:
> 
> 1. `getName()` in `Extension`.
> 2. No need to cast to into a `CertAttrSet` object in `CertificateExtensions::parseExtension` at https://github.com/openjdk/jdk/pull/10934/files#diff-0b9f279d1a1537d66ce5adf4e2abcff9a15d4905f500539a6cf52e9f6710aef7R108-R109, since `getName()` is in `Extension` now.
> 3. No need to call different methods `CertAttrSet::getName` and `Extension::getExtensionId::toString` depending on the types in `CertificateExtensions::equals` at https://github.com/openjdk/jdk/pull/10934/files#diff-0b9f279d1a1537d66ce5adf4e2abcff9a15d4905f500539a6cf52e9f6710aef7L298-L303, since the default implementation in `Extension::getName` is already returning the OID.
> 
> The last 2 points are also true for `CRLExtensions`.

The bug needs a noreg label; otherwise looks good.

Hooray for removing dead code!

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

Marked as reviewed by mullan (Reviewer).

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


From duke at openjdk.org  Wed Nov  2 14:39:00 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 2 Nov 2022 14:39:00 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: <G3Fyie0iDYBFPTHckKRy3PyiQFrT7PNaS_qKHuN7N2Q=.ab876e9b-9b60-423d-8433-3ec7835c8876@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

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

> 408:                 // as it hapeens to be 4. For bit set other than 4 bits, for
> 409:                 // example, 3 bits set (0x8), the value should be added back.
> 410:                 // d.setProduct(w[2]);

I think you can remove this comment, or at least fix your typos: "for-lopp" -> "for loop",  "hapeens" -> "happens",  "(0x8)" -> "(0x7)". 
You can say something like.: ' "if(k != -1) d.setProduct(w[k]);" is not necessary here as k is -1 at the end of the loop for this exponent'

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

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


From weijun at openjdk.org  Wed Nov  2 14:43:35 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 2 Nov 2022 14:43:35 GMT
Subject: Integrated: 8296142: CertAttrSet::(getName|getElements|delete) are
 mostly useless
In-Reply-To: <gCjGZ3L1xf4n4x9KXpskZ3EZhQdSBCTGN7TeunB1tbo=.764f7164-b96d-4822-a0ef-6333eab308e5@github.com>
References: <gCjGZ3L1xf4n4x9KXpskZ3EZhQdSBCTGN7TeunB1tbo=.764f7164-b96d-4822-a0ef-6333eab308e5@github.com>
Message-ID: <qaa21XVfgTMDsKrXlCIKnzjiYE337SSxBGHJ5IQFbYs=.536bcc54-5d3f-41e7-8120-c78cd1e628bf@github.com>

On Tue, 1 Nov 2022 13:34:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change removes `getElements()` and `delete()` from `CertAttrSet` and all its subclasses. The `getName()` method is moved to `s.s.x.Extension` since it's only useful there.
> 
> Except for removing lines, the only place where real changes are made are:
> 
> 1. `getName()` in `Extension`.
> 2. No need to cast to into a `CertAttrSet` object in `CertificateExtensions::parseExtension` at https://github.com/openjdk/jdk/pull/10934/files#diff-0b9f279d1a1537d66ce5adf4e2abcff9a15d4905f500539a6cf52e9f6710aef7R108-R109, since `getName()` is in `Extension` now.
> 3. No need to call different methods `CertAttrSet::getName` and `Extension::getExtensionId::toString` depending on the types in `CertificateExtensions::equals` at https://github.com/openjdk/jdk/pull/10934/files#diff-0b9f279d1a1537d66ce5adf4e2abcff9a15d4905f500539a6cf52e9f6710aef7L298-L303, since the default implementation in `Extension::getName` is already returning the OID.
> 
> The last 2 points are also true for `CRLExtensions`.

This pull request has now been integrated.

Changeset: 16a041a6
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16a041a67a30ad8f3160e211c629c055d3ff2f80
Stats:     1191 lines in 41 files changed: 33 ins; 1135 del; 23 mod

8296142: CertAttrSet::(getName|getElements|delete) are mostly useless

Reviewed-by: mullan

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

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


From duke at openjdk.org  Wed Nov  2 14:48:31 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 2 Nov 2022 14:48:31 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: <gf7boGy8yDbTX774E7awreNc11bPFdmuuD-2Zyn6WBo=.f226a43a-6f18-4412-ba0d-581b0c4c4b87@github.com>

On Mon, 31 Oct 2022 17:19:21 GMT, Xue-Lei Andrew Fan <xuelei 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.

Well, I doubt this would be one of those cases you have in mind...
Your method of computing the inverse looks good to me, but I still think that if we can achieve a better result with an existing general method then we should do that instead of writing special ones for every curve. 
I think there is a risk in having more code, too.

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

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


From coffeys at openjdk.org  Wed Nov  2 15:42:08 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 2 Nov 2022 15:42:08 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v4]
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: <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@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 21 commits:

 - code clean up
 - funnel cert events via generateCertificate only
 - Revert use of x509 constructor helper in some areas. Clean up tests
 - modules fix up in test
 - Capture CertAndKeyGen certs
 - import clean up
 - Copyright year update
 - Merge branch 'master' into 8292033-x509Event
 - record events for internal constructor calls. Expand testing
 - Use X500Principal#toString()
 - ... and 11 more: https://git.openjdk.org/jdk/compare/cf5546b3...f430a3ee

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

Changes: https://git.openjdk.org/jdk/pull/10422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10422&range=03
  Stats: 222 lines in 13 files changed: 134 ins; 54 del; 34 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  Wed Nov  2 15:49:34 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 2 Nov 2022 15:49:34 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v4]
In-Reply-To: <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
Message-ID: <6dfyzDXJHaL6OvtN0VduF3aUhE8j6fOJlfF3L2o1QyA=.fff6efcd-2df0-4c3e-b56c-32f2bd51ff04@github.com>

On Wed, 2 Nov 2022 15:42:08 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 21 commits:
> 
>  - code clean up
>  - funnel cert events via generateCertificate only
>  - Revert use of x509 constructor helper in some areas. Clean up tests
>  - modules fix up in test
>  - Capture CertAndKeyGen certs
>  - import clean up
>  - Copyright year update
>  - Merge branch 'master' into 8292033-x509Event
>  - record events for internal constructor calls. Expand testing
>  - Use X500Principal#toString()
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/cf5546b3...f430a3ee

on further reading, it turns out that code like `CertificateFactory.generateCertPath` or `generateCertificates` need not have an explicit X509Cert event recording. In theory, that implementation should call into  `CertificateFactory.generateCertificate` to generate the underlying certificates. Some of the JDK implementation doesn't go down that route and I've added an X509CertImpl getter method to help in those scenarios.  (to construct and record an X509CertImpl instance)

Recording cert events from  `CertificateFactory.generateCertPath` or `generateCertificates` would most likely lead to duplicate certificates being recorded. It depends on how the 3rd party providers are coded of course and we have no control over that.

I've beefed up the test logic to cover the various CertificateFactory methods that raised concern. I also included a CertAndGen example to cover what keytool might do in such scenarios.

@seanjmullan  - I'll log a new bug to cover the `sun.security.pkcs.PKCS7` code issues you highlight

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

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


From xuelei at openjdk.org  Wed Nov  2 16:11:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 2 Nov 2022 16:11:30 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <gf7boGy8yDbTX774E7awreNc11bPFdmuuD-2Zyn6WBo=.f226a43a-6f18-4412-ba0d-581b0c4c4b87@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>
 <gf7boGy8yDbTX774E7awreNc11bPFdmuuD-2Zyn6WBo=.f226a43a-6f18-4412-ba0d-581b0c4c4b87@github.com>
Message-ID: <J-X0JLGGQZlzg9AZa7YXjTlm-Ltfcc2UfDggwMnS7aA=.380e04d9-bc76-4cfa-b9ed-6b4b4ef5f500@github.com>

On Wed, 2 Nov 2022 14:44:30 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.
> 
> Well, I doubt this would be one of those cases you have in mind... Your method of computing the inverse looks good to me, but I still think that if we can achieve a better result with an existing general method then we should do that instead of writing special ones for every curve. I think there is a risk in having more code, too.

There was vulnerability reported to other TLS vendors for non-constant inversion computation and we was OK.  The new implementation performance in this PR is pretty close to using BigIntegers.   We might not want to take the risks by introducing the branchless implementation back.  

I agree that more code means more risks.  I hope the risk is under control and get examined.  It also come with an advantage.  With this update, if secp256r1 broken, secp521r1 may be still safe as they are using different code base.

Thank you for looking into the implementation.

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

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


From xuelei at openjdk.org  Wed Nov  2 16:22:00 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 2 Nov 2022 16:22:00 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v4]
In-Reply-To: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
Message-ID: <5ZT0N4WURus3thV3bH6WfbYaejPSow08U8-0HlQnCtI=.d3c26682-f8c0-4b71-ba7b-014ba4fc71a1@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:

  remove unnecessary comment

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

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

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

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 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  Wed Nov  2 16:22:04 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 2 Nov 2022 16:22:04 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v3]
In-Reply-To: <G3Fyie0iDYBFPTHckKRy3PyiQFrT7PNaS_qKHuN7N2Q=.ab876e9b-9b60-423d-8433-3ec7835c8876@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <dH9Y-Qf_sqeol2fv2ULpJHZBahJpKKKQ5MvcmXwMOC8=.15805de6-593d-43bd-96fe-f936763c88e1@github.com>
 <G3Fyie0iDYBFPTHckKRy3PyiQFrT7PNaS_qKHuN7N2Q=.ab876e9b-9b60-423d-8433-3ec7835c8876@github.com>
Message-ID: <KUMV2GcAWXKmzBkCn6HN_n9AK_ewYkSVzLQgdrgcUjA=.a97aced4-c929-49ce-b0ae-9c5486775e73@github.com>

On Wed, 2 Nov 2022 14:35:20 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more improvement
>
> src/java.base/share/classes/sun/security/util/math/IntegerModuloP.java line 410:
> 
>> 408:                 // as it hapeens to be 4. For bit set other than 4 bits, for
>> 409:                 // example, 3 bits set (0x8), the value should be added back.
>> 410:                 // d.setProduct(w[2]);
> 
> I think you can remove this comment, or at least fix your typos: "for-lopp" -> "for loop",  "hapeens" -> "happens",  "(0x8)" -> "(0x7)". 
> You can say something like.: ' "if(k != -1) d.setProduct(w[k]);" is not necessary here as k is -1 at the end of the loop for this exponent'

Thank you for the suggestion.  I would like to remove this comment as it looks more clear to me.

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

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


From anthony.scarpino at oracle.com  Wed Nov  2 16:56:16 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 2 Nov 2022 09:56:16 -0700
Subject: TLS Performance Regression in JDK18+
In-Reply-To: <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
 <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
Message-ID: <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>

Hi Carter,

Are you running this on an AVX512 machine?  Have you seen/tried to run 
this on a machine that does not have AVX512, like AVX2 or even aarch64?

thanks

Tony

On 11/1/22 12:19 PM, Anthony Scarpino wrote:
> Hi Carter,
> 
> I'll have to review your data more and look into it.
> 
> thanks
> 
> Tony
> 
> On 10/31/22 4:51 PM, Carter Kozak wrote:
>> 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


From anthony.scarpino at oracle.com  Wed Nov  2 17:51:38 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 2 Nov 2022 10:51:38 -0700
Subject: TLS Performance Regression in JDK18+
In-Reply-To: <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
 <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
 <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>
Message-ID: <ccba6d8a-b197-20d5-0622-47c57069c89f@oracle.com>

I see that you ran this on a Xeon W-2175, so that answers that question.

So aside from the question about running it on any other processors, how 
do you run jdk18 on your test.  When I typed './gradlew run' it only ran 
jdk17.

thanks

Tony

On 11/2/22 9:56 AM, Anthony Scarpino wrote:
> Hi Carter,
> 
> Are you running this on an AVX512 machine?? Have you seen/tried to run 
> this on a machine that does not have AVX512, like AVX2 or even aarch64?
> 
> thanks
> 
> Tony
> 
> On 11/1/22 12:19 PM, Anthony Scarpino wrote:
>> Hi Carter,
>>
>> I'll have to review your data more and look into it.
>>
>> thanks
>>
>> Tony
>>
>> On 10/31/22 4:51 PM, Carter Kozak wrote:
>>> 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


From ckozak at ckozak.net  Wed Nov  2 18:13:21 2022
From: ckozak at ckozak.net (Carter Kozak)
Date: Wed, 02 Nov 2022 11:13:21 -0700
Subject: TLS Performance Regression in JDK18+
In-Reply-To: <ccba6d8a-b197-20d5-0622-47c57069c89f@oracle.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
 <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
 <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>
 <ccba6d8a-b197-20d5-0622-47c57069c89f@oracle.com>
Message-ID: <afc89329-44ee-46b3-866b-75024915a858@app.fastmail.com>

> So aside from the question about running it on any other processors, how 
> do you run jdk18 on your test.  When I typed './gradlew run' it only ran 
> jdk17.

The easiest way is to update the source with '@Fork(value = 1, jvm = "/absolute/path/to/bin/java")'
e.g. https://github.com/carterkozak/java-crypto-allocation-performance/pull/2

Otherwise, you can build a distZip with `./gradlew distZip` which will be
created in 'java-crypto-allocation-performance/build/distributions'
Which has a start script 'bin/java-crypto-allocation-performance' that will
use your JAVA_HOME envvar.

Best,
Carter Kozak


From weijun at openjdk.org  Wed Nov  2 20:00:28 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 2 Nov 2022 20:00:28 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
Message-ID: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>

The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.

Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.

Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.

The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.

Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.

There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/10959/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10959&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296143
  Stats: 2836 lines in 66 files changed: 57 ins; 2284 del; 495 mod
  Patch: https://git.openjdk.org/jdk/pull/10959.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10959/head:pull/10959

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


From weijun at openjdk.org  Wed Nov  2 21:21:34 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 2 Nov 2022 21:21:34 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <z1FoQz2XxkSYbe5LHUMjwPSCWnCvf6C4f1aRb8gCirs=.8c86128d-d4c9-4a0f-a63a-2ddfb10834f3@github.com>

On Wed, 2 Nov 2022 19:52:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

In fact, all extensions can be made immutable since their setters are only called inside tests.

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

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


From duke at openjdk.org  Thu Nov  3 07:49:28 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 3 Nov 2022 07:49:28 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>

On Tue, 1 Nov 2022 16:14:20 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - 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

Since?these are?in?the?same compilation?unit as?the?deprecated `URL`?constructors, `@SuppressWarnings("deprecation")` isn?t?needed:

src/java.base/share/classes/java/net/URL.java line 885:

> 883:             @SuppressWarnings("deprecation")
> 884:             var result = new URL("jrt", host, port, file, null);
> 885:             return result;

Suggestion:

            return new URL("jrt", host, port, file, null);

src/java.base/share/classes/java/net/URL.java line 909:

> 907:         @SuppressWarnings("deprecation")
> 908:         var result = new URL((URL)null, uri.toString(), handler);
> 909:         return result;

Suggestion:

        return new URL((URL)null, uri.toString(), handler);

src/java.base/share/classes/java/net/URL.java line 1833:

> 1831:         try {
> 1832:             @SuppressWarnings("deprecation")
> 1833:             var _unused = replacementURL = new URL(urlString);

Suggestion:

            replacementURL = new URL(urlString);

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

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


From dfuchs at openjdk.org  Thu Nov  3 11:20:03 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:03 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
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: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@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 incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/f6b8a9f9..fc899005

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

  Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 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  Thu Nov  3 11:20:04 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 3 Nov 2022 11:20:04 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>

On Thu, 3 Nov 2022 10:56:28 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 incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/java/net/URL.java line 152:

> 150:  * provide any guarantee about its conformance to the URL
> 151:  * syntax specification.
> 152:  * <p>

I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)?

Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical.

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

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


From dfuchs at openjdk.org  Thu Nov  3 11:20:05 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:05 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
 <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>
Message-ID: <f6KQGfu1BOAUMUam_LwZTp88-8NX2-I6d4Ku2d4LJ3U=.e9a5ef53-afa7-4163-bd4b-1260e7ebc2ef@github.com>

On Thu, 3 Nov 2022 10:56:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/java/net/URL.java line 152:
> 
>> 150:  * provide any guarantee about its conformance to the URL
>> 151:  * syntax specification.
>> 152:  * <p>
> 
> I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)?
> 
> Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical.

That would better go in URL::toURI I think - but AFAICS would only apply if you constructed the URL from one of the deprecated constructors. It's not a bad idea - but given that the CSR has been approved I'd rather track that in a follow up PR.

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

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


From dfuchs at openjdk.org  Thu Nov  3 11:20:08 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:08 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
 <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>
Message-ID: <JPqOXDD-OIUnBfjasVY1YXwf6cN-Vknvd4XhDEXJDvI=.7c24b554-eff1-47de-8db2-898439de2338@github.com>

On Thu, 3 Nov 2022 07:42:44 GMT, ExE Boss <duke at openjdk.org> wrote:

>> 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 six additional commits since the last revision:
>> 
>>  - Integrated review feedback
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - 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 885:
> 
>> 883:             @SuppressWarnings("deprecation")
>> 884:             var result = new URL("jrt", host, port, file, null);
>> 885:             return result;
> 
> Suggestion:
> 
>             return new URL("jrt", host, port, file, null);

Ah ! Good point thanks! I have accepted your suggestions.

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

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


From mbaesken at openjdk.org  Thu Nov  3 12:19:27 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Nov 2022 12:19:27 GMT
Subject: RFR: JDK-8296226: Add constructors (String, Throwable) and (Throwable)
 to InvalidParameterException
Message-ID: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>

This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

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

Commit messages:
 - JDK-8296226

Changes: https://git.openjdk.org/jdk/pull/10966/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10966&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296226
  Stats: 33 lines in 7 files changed: 21 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10966.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10966/head:pull/10966

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


From duke at openjdk.org  Thu Nov  3 12:19:29 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 3 Nov 2022 12:19:29 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException
In-Reply-To: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
Message-ID: <gIH1OCWxqnqZ3ddjXDWeLx2feBcxMU2G5ZpSS4qSfIs=.672f6ea8-5061-481a-877c-d6619cbdb999@github.com>

On Thu, 3 Nov 2022 09:07:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

These?should probably?have `@since`?tags:

src/java.base/share/classes/java/security/InvalidParameterException.java line 68:

> 66:      * @param msg the detail message.
> 67:      * @param cause the cause.
> 68:      */

Suggestion:

     * @since 20
     */

src/java.base/share/classes/java/security/InvalidParameterException.java line 78:

> 76:      *
> 77:      * @param cause the cause.
> 78:      */

Suggestion:

     * @since 20
     */

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

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


From aefimov at openjdk.org  Thu Nov  3 13:05:33 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 3 Nov 2022 13:05:33 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <k_5J1gI_C0W-b_WcMMG6Rf71Bxu-rLiTzonaEiDtXTU=.5a547097-d335-42bc-bb3b-dd970135a666@github.com>

On Thu, 3 Nov 2022 11:20:03 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 incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

`java.naming` changes looks reasonable to me. Thanks!

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

Marked as reviewed by aefimov (Committer).

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


From mbaesken at openjdk.org  Thu Nov  3 13:41:24 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Nov 2022 13:41:24 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException
In-Reply-To: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
Message-ID: <lVLO8VO57OOGkxgKAJESqBk01lQVnW2cJeOYsFOVNsY=.9cefb270-2dcc-431c-9249-dcb5bc10993e@github.com>

On Thu, 3 Nov 2022 09:07:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

Hi ExE-Boss, thanks for the suggestion , I will add `@since`   tags .

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

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


From mullan at openjdk.org  Thu Nov  3 13:49:07 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 13:49:07 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException
In-Reply-To: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
Message-ID: <_enikRGWu3-u49UlzR9ICGudjLyazWIcekH--RIhGEU=.e7801909-b442-4a76-8df9-461c1a8ae824@github.com>

On Thu, 3 Nov 2022 09:07:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

The new constructors are underspecified. They should be consistent with the specification of the superclass constructors, which describe the behavior of `null` parameters and give more details on the error message. I would basically copy most of the description and params from the `Throwable` constructors. See, for example the `java.lang.IllegalArgumentException` constructors that take `Throwable` params.

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

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


From mbaesken at openjdk.org  Thu Nov  3 14:26:52 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Nov 2022 14:26:52 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException [v2]
In-Reply-To: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
Message-ID: <xLCsrFLdG8sqhsW5HXqfVyxQ7YEndXvJRTLVI1cKYXo=.7dca6274-872a-456a-bcc2-bffb739fd309@github.com>

> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust javadoc of the added InvalidParameterException constructors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10966/files
  - new: https://git.openjdk.org/jdk/pull/10966/files/b87cf7f7..847b14f2

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

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

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


From mbaesken at openjdk.org  Thu Nov  3 14:26:52 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Nov 2022 14:26:52 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException
In-Reply-To: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
Message-ID: <b1G-QtcjiIL5LZ7BXur6OVkyIRC3KPOs69bsJy30s2I=.8d236464-11f5-4ac8-905d-2b5e179ce199@github.com>

On Thu, 3 Nov 2022 09:07:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

Hi Sean, I adjusted the constructor javadoc related comments, also added the since tags.

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

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


From mullan at openjdk.org  Thu Nov  3 15:07:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 15:07:47 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites
Message-ID: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>

This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.

Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.

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

Commit messages:
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/10969/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10969&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8279164
  Stats: 92 lines in 4 files changed: 14 ins; 63 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10969.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10969/head:pull/10969

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


From michaelm at openjdk.org  Thu Nov  3 15:10:37 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 3 Nov 2022 15:10:37 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <VIPkTGY5ZJNqBRiHcqesQQOdR3wuw_MR6KIKUm6TGeg=.802cdd63-df58-4c2e-bf83-049e4018021d@github.com>

On Thu, 3 Nov 2022 11:20:03 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 incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by michaelm (Reviewer).

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

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


From xuelei at openjdk.org  Thu Nov  3 15:19:33 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 3 Nov 2022 15:19:33 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites
In-Reply-To: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
Message-ID: <FtBedf4CYGmESyhT8j3DmUT4yLg854DRGirDwpfySlY=.8e2828fd-dfc2-4d05-a173-ee45123ee45a@github.com>

On Thu, 3 Nov 2022 14:59:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
> 
> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.

Looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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


From mullan at openjdk.org  Thu Nov  3 15:28:35 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 15:28:35 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException [v2]
In-Reply-To: <xLCsrFLdG8sqhsW5HXqfVyxQ7YEndXvJRTLVI1cKYXo=.7dca6274-872a-456a-bcc2-bffb739fd309@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
 <xLCsrFLdG8sqhsW5HXqfVyxQ7YEndXvJRTLVI1cKYXo=.7dca6274-872a-456a-bcc2-bffb739fd309@github.com>
Message-ID: <jq8ApoRP_6Zjoe6PlYpaVxLpmkiYeRxRLv6N_CvOVfM=.311ab88f-13f5-4299-b8eb-0b64a645ebd6@github.com>

On Thu, 3 Nov 2022 14:26:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust javadoc of the added InvalidParameterException constructors

Please also update test/jdk/java/security/Exceptions/ChainingConstructors.java and add a new test for these constructors.

src/java.base/share/classes/java/security/InvalidParameterException.java line 64:

> 62:     /**
> 63:      * Constructs an {@code InvalidParameterException} with the
> 64:      * specified detail message and cause. A detail message is a {@code String} that describes

Keep these lines within 80 character width to be consistent with the rest of the file.

src/java.base/share/classes/java/security/InvalidParameterException.java line 78:

> 76:      *         unknown.)
> 77:      *
> 78:      * @since 20

Nit: align "20" with text (add a space) to be consistent with other ctor.

src/java.base/share/classes/java/security/InvalidParameterException.java line 85:

> 83: 
> 84:     /**
> 85:      * Constructs an {@code InvalidParameterException} with the specified cause and a detail

Keep these lines within 80 character width to be consistent with the rest of the file.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyGenerator.java line 338:

> 336:             newSignificantKeySize = checkKeySize(mechanism, keySize, range);
> 337:         } catch (InvalidAlgorithmParameterException iape) {
> 338:             throw new InvalidParameterException("Invalid algorithm parameter", iape);

I would change this to `throw new InvalidParameterException(iape)`. The detail message of the cause is more useful in this case.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 154:

> 152:             checkKeySize(keySize, null);
> 153:         } catch (InvalidAlgorithmParameterException e) {
> 154:             throw new InvalidParameterException(e.getMessage(), e);

Here too I would change this to `throw new InvalidParameterException(e)` since the detail message of the cause will be used, the first parameter doesn't add any value.

test/jdk/sun/security/tools/keytool/fakegen/java.base/sun/security/rsa/RSAKeyPairGenerator.java line 60:

> 58:                     RSAKeyGenParameterSpec.F4), random);
> 59:         } catch (InvalidAlgorithmParameterException iape) {
> 60:             throw new InvalidParameterException(iape.getMessage(), iape);

Use the one-arg ctor to make this consistent with the code above: [src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java](https://github.com/openjdk/jdk/pull/10966/files#diff-4eaff4fafb2999bb74081347365803821458dc8ea618808474a948a4dc7d9b75)

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

Changes requested by mullan (Reviewer).

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


From duke at openjdk.org  Thu Nov  3 15:28:46 2022
From: duke at openjdk.org (Bernd)
Date: Thu, 3 Nov 2022 15:28:46 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites
In-Reply-To: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
Message-ID: <PxG9F1JprcwWjGiS7YXBrlQU3WJ0Q5xV4FCUhWez4m4=.a54d1bf3-710c-4a77-8f5e-2c59e098d938@github.com>

On Thu, 3 Nov 2022 14:59:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
> 
> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.

Should probably also be mentioned as planned on the Ora crypto roadmap or will it only be added at release time?

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

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


From mullan at openjdk.org  Thu Nov  3 15:34:31 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 15:34:31 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites
In-Reply-To: <PxG9F1JprcwWjGiS7YXBrlQU3WJ0Q5xV4FCUhWez4m4=.a54d1bf3-710c-4a77-8f5e-2c59e098d938@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
 <PxG9F1JprcwWjGiS7YXBrlQU3WJ0Q5xV4FCUhWez4m4=.a54d1bf3-710c-4a77-8f5e-2c59e098d938@github.com>
Message-ID: <QT_JF1VduZt1n9q6sK40aUn4xVSqPqoy8aQRNOru2lI=.dc8ce79e-c54f-4c24-aaca-d97c6419c685@github.com>

On Thu, 3 Nov 2022 15:26:44 GMT, Bernd <duke at openjdk.org> wrote:

> Should probably also be mentioned as planned on the Ora crypto roadmap or will it only be added at release time?

Eventually. This is to first get this change into a feature release.

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

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


From dfuchs at openjdk.org  Thu Nov  3 15:52:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 15:52:53 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v5]
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: <BkNpz5wPrxpFJDaE0AzRWyRnG2r8B5qdEgm32zDE3Dw=.32ed243e-d406-4296-86bc-847aaa9d9a06@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 10 additional commits since the last revision:

 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Integrated review feedback
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - 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/fc899005..b4a73f40

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

  Stats: 42853 lines in 291 files changed: 10793 ins; 30812 del; 1248 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 duke at openjdk.org  Thu Nov  3 16:35:25 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 3 Nov 2022 16:35:25 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
Message-ID: <vpwb5fVBMF-jl-v6QjzhAHQ5iW8L2G3mGPPLTfOi4tM=.8e8861e9-6469-45c7-8181-d049d132ad91@github.com>

On Tue, 1 Nov 2022 19:10:13 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:
> 
>   typo correction

Thanks!

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 425:

> 423:         // point.  The multiplier point is specified by the implementation of
> 424:         // this interface, which could be a general EC point or EC generator
> 425:         // point.

Suggestion for the comment:
         // Multiply the ECPoint (that is specified in the implementation) by a scalar and return the result as a 
         // ProjectivePoint.Mutable point. 
         // The point to be multiplied can be a general EC point or the generator of a named EC group.
         // The scalar multiplier is an integer in little endian byte array representation.

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 539:

> 537: 
> 538:         final class Secp256R1GeneratorMultiplier implements PointMultiplier {
> 539:             private static final ECPoint point =

I would rename "point" to "generator"

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 579:

> 577:             }
> 578: 
> 579:             private static int posit(byte[] k, int i) {

I would rename "posit" to "bit"

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 590:

> 588:                 // 16 elements. For the 1st dimension, each element in it is
> 589:                 // a pre-computed generator point multiplication value.
> 590:                 //

I suggest to reword this:
                // Pre-computed table to speed up the point multiplication.
                 //
                 // This is a 4x16 array of ProjectivePoint.Immutable elements.
                 // The first row contains the following multiples of the generator.
                 //

src/jdk.crypto.ec/share/classes/sun/security/ec/ECOperations.java line 612:

> 610:                 // For the following dimensions, each element is multiplied
> 611:                 // by 2^16 of the corresponding element value in the previous
> 612:                 // dimension.

Suggestion for the last part of the comment:
                 // For the other 3 rows: points[I][j] = (points[I-1][j] scalar multiplied by 2^16)

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

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


From mpowers at openjdk.org  Thu Nov  3 16:55:31 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 3 Nov 2022 16:55:31 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
Message-ID: <rhGHi1XdEHEdpyHFhBzPeS3jXYqrvl2obnhBoUfEGQE=.e1bbcdb6-f1fe-49fa-b449-e688f54b14f0@github.com>

On Tue, 1 Nov 2022 19:10:13 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:
> 
>   typo correction

Is this improvement also derived from the paper by Renes, Costello, and Batina?

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

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


From dfuchs at openjdk.org  Thu Nov  3 17:22:28 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 17:22:28 GMT
Subject: Integrated: 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: <4AGCrDQ4XC3UDTwYPRw8OPCbIFPueKKAGAJVb7ulbmM=.d7bc126d-3230-4d27-8519-ff06233dd8d9@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

This pull request has now been integrated.

Changeset: 4338f527
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4338f527aa81350e3636dcfbcd2eb17ddaad3914
Stats:     853 lines in 82 files changed: 707 ins; 5 del; 141 mod

8294241: Deprecate URL public constructors

Reviewed-by: joehw, prr, alanb, aefimov, michaelm

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

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


From mullan at openjdk.org  Thu Nov  3 17:48:39 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 17:48:39 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v4]
In-Reply-To: <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
Message-ID: <xVoAoPyfFmSH_icDA9830FON9gs0gDS94H2SSdvbcMY=.4f9ab62f-415f-4ae0-8082-5f292e0ae5b6@github.com>

On Wed, 2 Nov 2022 15:42:08 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 21 commits:
> 
>  - code clean up
>  - funnel cert events via generateCertificate only
>  - Revert use of x509 constructor helper in some areas. Clean up tests
>  - modules fix up in test
>  - Capture CertAndKeyGen certs
>  - import clean up
>  - Copyright year update
>  - Merge branch 'master' into 8292033-x509Event
>  - record events for internal constructor calls. Expand testing
>  - Use X500Principal#toString()
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/cf5546b3...f430a3ee

src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 289:

> 287:     public X509CertImpl(X509CertInfo certInfo) {
> 288:         this.info = certInfo;
> 289:         JCAUtil.tryCommitCertEvent(this);

Why do we need to record this as an event? This is an incomplete (unsigned) certificate.

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

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


From mullan at openjdk.org  Thu Nov  3 17:58:27 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 17:58:27 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v4]
In-Reply-To: <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
Message-ID: <9z2MSQkoYiC1YDeXGr56TPNIIuHf09fQxTrcQzygNkI=.5fb43b63-29ea-49fc-8d89-242b400bae82@github.com>

On Wed, 2 Nov 2022 15:42:08 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 21 commits:
> 
>  - code clean up
>  - funnel cert events via generateCertificate only
>  - Revert use of x509 constructor helper in some areas. Clean up tests
>  - modules fix up in test
>  - Capture CertAndKeyGen certs
>  - import clean up
>  - Copyright year update
>  - Merge branch 'master' into 8292033-x509Event
>  - record events for internal constructor calls. Expand testing
>  - Use X500Principal#toString()
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/cf5546b3...f430a3ee

Do you think it is that useful to have keytool record events? Ok, I guess some apps could be execing keytool, but that would be in a separate process, and probably wouldn't have JFR enabled. Also, these certs, if used for authentication usages will eventually come back into the runtime through CertificateFactory.

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

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


From xuelei at openjdk.org  Thu Nov  3 18:18:42 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 3 Nov 2022 18:18:42 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v5]
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <izZBwGm2sxd1IrWBYYRAEhutZ0P8CaS39i8MplqstiQ=.fab07331-87a9-4f13-a406-93d3be844fa5@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:

  wordsmithing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10893/files
  - new: https://git.openjdk.org/jdk/pull/10893/files/37aa43da..2999562e

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

  Stats: 21 lines in 1 file changed: 6 ins; 2 del; 13 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 Nov  3 18:18:43 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 3 Nov 2022 18:18:43 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <rhGHi1XdEHEdpyHFhBzPeS3jXYqrvl2obnhBoUfEGQE=.e1bbcdb6-f1fe-49fa-b449-e688f54b14f0@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
 <rhGHi1XdEHEdpyHFhBzPeS3jXYqrvl2obnhBoUfEGQE=.e1bbcdb6-f1fe-49fa-b449-e688f54b14f0@github.com>
Message-ID: <XfYMCnPK8Cwp7jSjXD2VSVmLUwWQUgREU-5rhcYqFGc=.3f8992d9-01a9-41d8-b383-2590c79836fd@github.com>

On Thu, 3 Nov 2022 16:51:47 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> Is this improvement also derived from the paper by Renes, Costello, and Batina?

Not really.  The idea is an improvement of the traditional double and addition formulas [1] for EC algorithms, by using interleaved multiplication [2].  In the ["Fast Elliptic Curve Cryptography in OpenSSL"](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37376.pdf) paper, there is a short description of the interleaved multiplication (see section 3.3).  This is an improvement so that it could be better fit for P384 and P521.

[1]: Hankerson, Darrel; Vanstone, Scott; Menezes, Alfred (2004). Guide to Elliptic Curve Cryptography. Springer Professional Computing. New York: Springer-Verlag.
[2]: Bodo M?oller. Algorithms for multi-exponentiation.

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

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


From xuelei at openjdk.org  Thu Nov  3 18:20:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 3 Nov 2022 18:20:28 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <vpwb5fVBMF-jl-v6QjzhAHQ5iW8L2G3mGPPLTfOi4tM=.8e8861e9-6469-45c7-8181-d049d132ad91@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
 <vpwb5fVBMF-jl-v6QjzhAHQ5iW8L2G3mGPPLTfOi4tM=.8e8861e9-6469-45c7-8181-d049d132ad91@github.com>
Message-ID: <rG3XgjXeej3XAd3E51Zucb8goAty7-8JYpwctrOtlXY=.1081ee7e-a8ad-47d2-8c67-6db976428fb5@github.com>

On Thu, 3 Nov 2022 16:32:13 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo correction
>
> Thanks!

@ferakocz All good suggestions to me.  Thank you very much!

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

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


From rhalade at openjdk.org  Thu Nov  3 20:33:24 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 3 Nov 2022 20:33:24 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites
In-Reply-To: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
Message-ID: <VWVrJeTrJAGXk5UTojY7EfpJx0a1WJObOAk5f33fLLE=.0dc2495c-94eb-48b9-8552-78d18d47e7d8@github.com>

On Thu, 3 Nov 2022 14:59:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
> 
> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.

Marked as reviewed by rhalade (Reviewer).

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

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


From mullan at openjdk.org  Thu Nov  3 20:39:52 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 20:39:52 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites [v2]
In-Reply-To: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
Message-ID: <KwiLw0od343wXtiWResvCvwHpZZ8slC1shhmA3K7LcE=.c8543a58-cf93-476a-9530-4b567ace86a5@github.com>

> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
> 
> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.

Sean Mullan 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 two additional commits since the last revision:

 - Merge
 - Initial revision.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10969/files
  - new: https://git.openjdk.org/jdk/pull/10969/files/897f5603..0aa21bdc

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

  Stats: 45937 lines in 472 files changed: 12808 ins; 31155 del; 1974 mod
  Patch: https://git.openjdk.org/jdk/pull/10969.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10969/head:pull/10969

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


From mullan at openjdk.org  Thu Nov  3 21:25:33 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 3 Nov 2022 21:25:33 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v4]
In-Reply-To: <rG3XgjXeej3XAd3E51Zucb8goAty7-8JYpwctrOtlXY=.1081ee7e-a8ad-47d2-8c67-6db976428fb5@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <ogXDlSMEElG3ItyBHOTE2CorqQSBFHLmd3PzdV4wze4=.420b4624-13ad-403d-8214-33966c7fe065@github.com>
 <vpwb5fVBMF-jl-v6QjzhAHQ5iW8L2G3mGPPLTfOi4tM=.8e8861e9-6469-45c7-8181-d049d132ad91@github.com>
 <rG3XgjXeej3XAd3E51Zucb8goAty7-8JYpwctrOtlXY=.1081ee7e-a8ad-47d2-8c67-6db976428fb5@github.com>
Message-ID: <LONW2gIhASZt00hgVjVsFz9fTl_n_7NhoZH24fLF-Ds=.f6467b47-1eb6-4916-9632-eeea7e79cb8c@github.com>

On Thu, 3 Nov 2022 18:17:44 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Thanks!
>
> @ferakocz All good suggestions to me.  Thank you very much!

@XueleiFan Please hold off on integrating this, as I want to review some parts of this and need more time.

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

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


From weijun at openjdk.org  Thu Nov  3 22:34:50 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 3 Nov 2022 22:34:50 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v2]
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <hCfz1Yh1UMyAjdrXqjIrF-s9CwP0VcT4ooraqckLUL0=.42c09429-309c-44e5-bcbb-d44422aa994d@github.com>

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

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

  less throws IOException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10959/files
  - new: https://git.openjdk.org/jdk/pull/10959/files/8dc7ba34..de2ac663

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

  Stats: 39 lines in 2 files changed: 0 ins; 18 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10959.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10959/head:pull/10959

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


From coffeys at openjdk.org  Thu Nov  3 23:11:28 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 3 Nov 2022 23:11:28 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v4]
In-Reply-To: <xVoAoPyfFmSH_icDA9830FON9gs0gDS94H2SSdvbcMY=.4f9ab62f-415f-4ae0-8082-5f292e0ae5b6@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
 <xVoAoPyfFmSH_icDA9830FON9gs0gDS94H2SSdvbcMY=.4f9ab62f-415f-4ae0-8082-5f292e0ae5b6@github.com>
Message-ID: <qHiDCxXZhTtVC__zMtsgV77DlM_eUSz49iiQ_8GiVZ8=.69de0e61-ce18-4182-85a3-7f6f8aaed05a@github.com>

On Thu, 3 Nov 2022 17:40:53 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 21 commits:
>> 
>>  - code clean up
>>  - funnel cert events via generateCertificate only
>>  - Revert use of x509 constructor helper in some areas. Clean up tests
>>  - modules fix up in test
>>  - Capture CertAndKeyGen certs
>>  - import clean up
>>  - Copyright year update
>>  - Merge branch 'master' into 8292033-x509Event
>>  - record events for internal constructor calls. Expand testing
>>  - Use X500Principal#toString()
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/cf5546b3...f430a3ee
>
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 289:
> 
>> 287:     public X509CertImpl(X509CertInfo certInfo) {
>> 288:         this.info = certInfo;
>> 289:         JCAUtil.tryCommitCertEvent(this);
> 
> Why do we need to record this as an event? This is an incomplete (unsigned) certificate.

good point. this constructor is mainly used by keytool. Would it make sense if I committed the event after the cert details are signed ?

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

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


From coffeys at openjdk.org  Thu Nov  3 23:27:31 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 3 Nov 2022 23:27:31 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v4]
In-Reply-To: <9z2MSQkoYiC1YDeXGr56TPNIIuHf09fQxTrcQzygNkI=.5fb43b63-29ea-49fc-8d89-242b400bae82@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
 <9z2MSQkoYiC1YDeXGr56TPNIIuHf09fQxTrcQzygNkI=.5fb43b63-29ea-49fc-8d89-242b400bae82@github.com>
Message-ID: <V1OuHa1zaGPrt0-Z6psqPYPHdr8750f2gr1YWUSgni4=.256855bf-8f29-4bfe-bc75-27343dd139b8@github.com>

On Thu, 3 Nov 2022 17:54:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Do you think it is that useful to have keytool record events? Ok, I guess some apps could be execing keytool, but that would be in a separate process, and probably wouldn't have JFR enabled. Also, these certs, if used for authentication usages will eventually come back into the runtime through CertificateFactory.

I figured it would be useful. keytool is an important generator of X509 certs. Why not give the opportunity to record them if JFR is enabled etc ? -J-XX:StartFlightRecording passed to keytool is sufficient to capture a recording.

The certs could be deployed out to any software stack I guess. Java being one possibility. 

I see your point about recording of constructor with X509CertInfo now. The keytool eventually re-loads the newly generated cert. I'll look at editing. (duplicate record)


jdk.X509Certificate {
  startTime = 23:16:53.687 (2022-11-03)
  algorithm = N/A
  serialNumber = "44ffbec5b6f38b64"
  subject = "CN=test.oracle.com, OU=JPG, C=US"
  issuer = "CN=test.oracle.com, OU=JPG, C=US"
  keyType = "RSA"
  keyLength = 2048
  certificateId = 0
  validFrom = 23:16:53.686 (2022-11-03)
  validUntil = 23:16:53.686 (2023-11-03)
  eventThread = "main" (javaThreadId = 1)
  stackTrace = [
    sun.security.jca.JCAUtil.tryCommitCertEvent(Certificate) line: 129
    sun.security.x509.X509CertImpl.<init>(X509CertInfo) line: 290
    sun.security.tools.keytool.CertAndKeyGen.getSelfCertificate(X500Name, Date, long, CertificateExtensions) line: 340
    sun.security.tools.keytool.Main.doGenKeyPair(String, String, String, int, String, String, String) line: 2013
    sun.security.tools.keytool.Main.doCommands(PrintStream) line: 1180
    ...
  ]
}

jdk.X509Certificate {
  startTime = 23:16:53.901 (2022-11-03)
  algorithm = "SHA384withRSA"
  serialNumber = "44ffbec5b6f38b64"
  subject = "CN=test.oracle.com, OU=JPG, C=US"
  issuer = "CN=test.oracle.com, OU=JPG, C=US"
  keyType = "RSA"
  keyLength = 2048
  certificateId = 1683785197
  validFrom = 23:16:53.000 (2022-11-03)
  validUntil = 23:16:53.000 (2023-11-03)
  eventThread = "main" (javaThreadId = 1)
  stackTrace = [
    sun.security.jca.JCAUtil.tryCommitCertEvent(Certificate) line: 129
    java.security.cert.CertificateFactory.generateCertificate(InputStream) line: 356
    sun.security.pkcs12.PKCS12KeyStore.loadSafeContents(DerInputStream) line: 2428
    sun.security.pkcs12.PKCS12KeyStore.lambda$engineLoad$1(AlgorithmParameters, byte[], char[]) line: 2127
    sun.security.pkcs12.PKCS12KeyStore$RetryWithZero.run(PKCS12KeyStore$RetryWithZero, char[]) line: 257
  ]

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

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


From wetmore at openjdk.org  Fri Nov  4 00:29:34 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 4 Nov 2022 00:29:34 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites [v2]
In-Reply-To: <KwiLw0od343wXtiWResvCvwHpZZ8slC1shhmA3K7LcE=.c8543a58-cf93-476a-9530-4b567ace86a5@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
 <KwiLw0od343wXtiWResvCvwHpZZ8slC1shhmA3K7LcE=.c8543a58-cf93-476a-9530-4b567ace86a5@github.com>
Message-ID: <7CCvR1dgc1Lqmt4ay7NYMK9HbqZIlw-OMkRM_5dz79M=.f367a780-e023-4b14-a79b-686b5f64f1e1@github.com>

On Thu, 3 Nov 2022 20:39:52 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
>> 
>> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.
>
> Sean Mullan 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 two additional commits since the last revision:
> 
>  - Merge
>  - Initial revision.

LGTM other than the typos.

test/jdk/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java line 85:

> 83:         "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
> 84: 
> 85:         // AES_256(GCM) - not forward screcy

Can you please fix the rest of the"screcy" typos in this file?

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

Marked as reviewed by wetmore (Reviewer).

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


From mpowers at openjdk.org  Fri Nov  4 02:24:33 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 4 Nov 2022 02:24:33 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v2]
In-Reply-To: <hCfz1Yh1UMyAjdrXqjIrF-s9CwP0VcT4ooraqckLUL0=.42c09429-309c-44e5-bcbb-d44422aa994d@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <hCfz1Yh1UMyAjdrXqjIrF-s9CwP0VcT4ooraqckLUL0=.42c09429-309c-44e5-bcbb-d44422aa994d@github.com>
Message-ID: <uAGM_2TIwragiDlQjS0ncj3zE-jPt45sHjXxr_j9UU4=.1dcfa603-ab9b-4175-8444-194c277b900c@github.com>

On Thu, 3 Nov 2022 22:34:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
>> 
>> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
>> 
>> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
>> 
>> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
>> 
>> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
>> 
>> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less throws IOException

src/java.base/share/classes/java/security/cert/X509CertSelector.java line 2397:

> 2395:             GeneralSubtrees excluded = ext.getExcludedSubtrees();
> 2396:             if (excluded != null) {
> 2397:                 if (matchExcluded(excluded) == false) {

`if (!matchExcluded(excluded) {`

src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 338:

> 336:             if (idpExt == null ||
> 337:                     idpExt.isIndirectCRL()
> 338:                     == Boolean.FALSE) {

`!idpExt.isIndirectCRL()) {`

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

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


From mpowers at openjdk.org  Fri Nov  4 02:38:31 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 4 Nov 2022 02:38:31 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v2]
In-Reply-To: <hCfz1Yh1UMyAjdrXqjIrF-s9CwP0VcT4ooraqckLUL0=.42c09429-309c-44e5-bcbb-d44422aa994d@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <hCfz1Yh1UMyAjdrXqjIrF-s9CwP0VcT4ooraqckLUL0=.42c09429-309c-44e5-bcbb-d44422aa994d@github.com>
Message-ID: <eEWSKWuDwTKkZDg62HqT8NIG5-I6bio1sqlabuH09Z0=.c0c9e09c-10e2-45f3-904a-78d9ee319da9@github.com>

On Thu, 3 Nov 2022 22:34:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
>> 
>> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
>> 
>> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
>> 
>> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
>> 
>> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
>> 
>> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less throws IOException

Way easier to read. Amazing work!

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

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


From duke at openjdk.org  Fri Nov  4 03:20:11 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 03:20:11 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@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

Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - address Jamil's review
 - invalidkeyexception and some review comments
 - extra whitespace character
 - 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
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9d3b4ef2...38d9e83c

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

Changes: https://git.openjdk.org/jdk/pull/10582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=06
  Stats: 1852 lines in 32 files changed: 1815 ins; 3 del; 34 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 Nov  4 03:24:33 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 03:24:33 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <0xJMPRdK0h3UJBYxqeLMfp1baL8xoaUpNcAZOtrFLKo=.d5c1020e-9e61-4800-bb52-9adbdd17e19f@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>
 <0xJMPRdK0h3UJBYxqeLMfp1baL8xoaUpNcAZOtrFLKo=.d5c1020e-9e61-4800-bb52-9adbdd17e19f@github.com>
Message-ID: <NssSsJxvYeCOKX6UGg_bACpV4eiFeJMBWjpceF22X_o=.c42e7e49-ac46-4ca1-a267-60ec0fc129dd@github.com>

On Fri, 28 Oct 2022 21:55:59 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> 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)`.

done

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

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


From duke at openjdk.org  Fri Nov  4 03:54:13 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 03:54:13 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
In-Reply-To: <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
Message-ID: <gAD-wSexeb2a5tq1LEFJqWRS6QF0Fi8EhAxZ1L5cBRc=.9f93ba53-64f2-4965-a1cc-323c7107e08c@github.com>

On Fri, 4 Nov 2022 03:20:11 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>  - address Jamil's review
>  - invalidkeyexception and some review comments
>  - extra whitespace character
>  - 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
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9d3b4ef2...38d9e83c

@jnimeh Hopefully last change addresses your pending comments.

More data, new data...

datasize | master | optimized | disabled | opt/mst | dis/mst
-- | -- | -- | -- | -- | --
32 | 3218169 | 3476352 | 3126538 | 1.08 | 0.97
64 | 2858030 | 3391015 | 2846735 | 1.19 | 1.00
128 | 2396796 | 3239888 | 2406931 | 1.35 | 1.00
256 | 1780679 | 3063749 | 1765664 | 1.72 | 0.99
512 | 1168824 | 2918524 | 1153009 | 2.50 | 0.99
1024 | 648772.1 | 2716787 | 688467.7 | 4.19 | 1.06
2048 | 357009 | 2382723 | 376023.7 | 6.67 | 1.05
16384 | 48854.33 | 896850 | 53104.68 | 18.36 | 1.09
1048576 | 771.461 | 15088.63 | 846.247 | 19.56 | 1.10

src/hotspot/share/opto/library_call.cpp line 7016:

> 7014:   Node* rObj = new CheckCastPPNode(control(), rFace, rtype);
> 7015:   rObj = _gvn.transform(rObj);
> 7016:   Node* rlimbs = load_field_from_object(rObj, "limbs", "[J");

@jnimeh if you could be particularly 'critical' here please? I generally know what I wanted to accomplish. And stepped through things with a debugger... but all the various IR types and conversions, I just don't know. I copied things from AES, which seem to work, as they do here, but I don't _understand_ the code.

i.e. recursive `getfield`s `((IntegerPolynomial$MutableElement)(this.a)).limbs` plus checks if we know field offsets: if (recursive) classes are loaded. But if not loaded, crashing with assert? Seems 'rude'. I think Poly1305 class constructor running would had forced the classes here to load so nothing to worry about, so I suppose assert is enough.)

src/hotspot/share/opto/library_call.cpp line 7027:

> 7025:   // Node* cmp = _gvn.transform(new CmpINode(load_array_length(alimbs), intcon(5)));
> 7026:   // Node* bol = _gvn.transform(new BoolNode(cmp, BoolTest::eq));
> 7027:   // Node* if_eq = generate_slow_guard(bol, slow_region);

@jnimeh I had "valiantly" tried to do a length check here, but couldn't find where to steal code from! If you have some suggestions...

Meanwhile, I decided that perhaps a Java check would not be _that_ bad for non-intrinsic code. See `checkLimbsForIntrinsic`; I had to change the interface `IntegerModuloP` which initially felt like a hack.

But perhaps the java check is 'alright', reminds java developer that there is a related intrinsic.

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;

@jnimeh FYI... In case you end up doing supporting other architectures, left a trail (and lots of 'math' comments in the assembler)

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

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


From mbaesken at openjdk.org  Fri Nov  4 08:44:34 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Nov 2022 08:44:34 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException [v3]
In-Reply-To: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
Message-ID: <9eYVPkNafFv2S7uneyQH9Cb2w2wo8VmGOWKMGCmLWL8=.7940e3af-926e-4e3d-bab8-72946db21a05@github.com>

> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Small adjustments to javadoc, some exceptions and add test coding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10966/files
  - new: https://git.openjdk.org/jdk/pull/10966/files/847b14f2..6b37ce44

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

  Stats: 23 lines in 5 files changed: 10 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/10966.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10966/head:pull/10966

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


From mbaesken at openjdk.org  Fri Nov  4 08:46:32 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Nov 2022 08:46:32 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException [v2]
In-Reply-To: <xLCsrFLdG8sqhsW5HXqfVyxQ7YEndXvJRTLVI1cKYXo=.7dca6274-872a-456a-bcc2-bffb739fd309@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
 <xLCsrFLdG8sqhsW5HXqfVyxQ7YEndXvJRTLVI1cKYXo=.7dca6274-872a-456a-bcc2-bffb739fd309@github.com>
Message-ID: <k7zGDLAPL3kXS0_8uJ2NwveJdVL2Ulufd_W5FqqmURs=.e779af6a-faa2-45ca-82eb-ba99e215c7d8@github.com>

On Thu, 3 Nov 2022 14:26:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust javadoc of the added InvalidParameterException constructors

Hi Sean, I adjusted the javadoc and the exceptions mentioned.
Also added InvalidParameterException to the ChainingConstructors test.
(btw the whole ChainingConstructors  test coding looks a bit bloated but that is maybe for another PR)

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

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


From djelinski1 at gmail.com  Fri Nov  4 11:21:29 2022
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 4 Nov 2022 12:21:29 +0100
Subject: TLS1.3 record padding
Message-ID: <CAMrH03KY5E6deE6+Fxqv_aXyg1HWObkCc=7g-tHDJmyczxjGLQ@mail.gmail.com>

Hello,
I noticed that we're padding every TLS 1.3 record with exactly 16 zeros
[1]. I'd like to remove that padding to conserve network bandwidth and
processing power. Thoughts?

Some background:
- TLS 1.3 RFC [2] defines padding as a means to hide the size of the
traffic. Constant-length padding does not hide it, obviously. The RFC does
not define any padding policies ("Selecting a padding policy that suggests
when and how much to pad is a complex topic and is beyond the scope of this
specification.")
- OpenSSL [3] defines 2 methods to select the length of the padding block:
the user may provide a callback that selects adequate padding length, or
provide block length, and then every record is padded to a multiple of
block length. By default OpenSSL does not pad records.
- I'm not aware of any discussions around record padding on this list,
which suggests that there's no demand for more complex padding schemes.

Regards,
Daniel

[1]
https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L302
[2] https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4
[3]
https://www.openssl.org/docs/man1.1.1/man3/SSL_set_record_padding_callback.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221104/f042c55f/attachment.htm>

From mullan at openjdk.org  Fri Nov  4 13:12:34 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Nov 2022 13:12:34 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites [v3]
In-Reply-To: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
Message-ID: <2nzPxoeWroYa-ugHM5rWBouWN6jhUHhV7B95GMYQokM=.de8e33b4-4dcf-4eb0-b94d-3722a6f72a9d@github.com>

> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
> 
> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.

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

  Fix "screcy" typos.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10969/files
  - new: https://git.openjdk.org/jdk/pull/10969/files/0aa21bdc..5a557059

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

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

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


From mullan at openjdk.org  Fri Nov  4 13:12:34 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Nov 2022 13:12:34 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites [v3]
In-Reply-To: <7CCvR1dgc1Lqmt4ay7NYMK9HbqZIlw-OMkRM_5dz79M=.f367a780-e023-4b14-a79b-686b5f64f1e1@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
 <KwiLw0od343wXtiWResvCvwHpZZ8slC1shhmA3K7LcE=.c8543a58-cf93-476a-9530-4b567ace86a5@github.com>
 <7CCvR1dgc1Lqmt4ay7NYMK9HbqZIlw-OMkRM_5dz79M=.f367a780-e023-4b14-a79b-686b5f64f1e1@github.com>
Message-ID: <bmaBElzfLMRQirarFRuv-hNhmEmbV5j1dP8euEx85xQ=.c9318149-20e0-4104-976a-8dfaa69da6a7@github.com>

On Fri, 4 Nov 2022 00:23:03 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix "screcy" typos.
>
> test/jdk/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java line 85:
> 
>> 83:         "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
>> 84: 
>> 85:         // AES_256(GCM) - not forward screcy
> 
> Can you please fix the rest of the"screcy" typos in this file?

Fixed.

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

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


From weijun at openjdk.org  Fri Nov  4 13:39:57 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 4 Nov 2022 13:39:57 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v3]
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <yHZvuro7yHDXKB2jh6lt0aQF5PAXjqzrlKqq4rXXASE=.c09caa12-2555-471a-886b-847a0dd997d8@github.com>

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

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

  more cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10959/files
  - new: https://git.openjdk.org/jdk/pull/10959/files/de2ac663..26a1f5c7

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

  Stats: 19 lines in 5 files changed: 6 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10959.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10959/head:pull/10959

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


From jnimeh at openjdk.org  Fri Nov  4 14:40:45 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 4 Nov 2022 14:40:45 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
In-Reply-To: <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
Message-ID: <GuAp66LcJ1C9QrjIKi-UfLCbz-YS9subHRLGcjXrlUM=.d1599b0d-78c1-4da8-bce3-2705602f92ab@github.com>

On Fri, 4 Nov 2022 03:20:11 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>  - address Jamil's review
>  - invalidkeyexception and some review comments
>  - extra whitespace character
>  - 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
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9d3b4ef2...38d9e83c

Regarding the updated numbers and master v. optimized-and-disabled, those are looking pretty good.  Looks like the break-even point is at 64 bytes and gets better from there which I think addresses my concerns.

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

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


From duke at openjdk.org  Fri Nov  4 14:40:45 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 14:40:45 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <mymD7nKP6xLz1XoansrlVbhxo6EK0Zefc5OJ_WFyf3g=.33270ab8-22af-4cc3-b0ca-eb364624925a@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>
 <Cju0XRYyqdeVeZZEpttxF9eUX02aQ0UM3CfD5uIe0OI=.6057ecb9-c80f-4eef-8aae-9f8748bc8f6c@github.com>
 <4HxTb1DtD6KeuYupOKf32GoQ7SV8_EjHcqfhiZhbLHM=.884e631a-1336-454d-aae1-06f85f784381@github.com>
 <mymD7nKP6xLz1XoansrlVbhxo6EK0Zefc5OJ_WFyf3g=.33270ab8-22af-4cc3-b0ca-eb364624925a@github.com>
Message-ID: <2_5CBS8aY7mUfXAvavQiM66Xg7ZNmjDiM6YM1vADCM4=.c0b0cc5e-9257-4d65-82cc-1cfd5523b554@github.com>

On Wed, 2 Nov 2022 03:16:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> And just looking now on uops.info, they seem to have identical timings?
>> 
>> Actual instruction being used (aligned vs unaligned versions) doesn't matter much here, because it's a dynamic property of the address being accessed: misaligned accesses that cross cache line boundary incur a penalty. Since cache lines are 64 bytes in size, every misaligned 512-bit access is penalized.
>
> I collected performance counters for the benchmark included with the patch and its showing around 30% of 64 byte loads were spanning across the cache line.
> 
>  Performance counter stats for 'java -jar target/benchmarks.jar -f 1 -wi 1 -i 2 -w 30 -p dataSize=8192':
> 
>       122385646614      cycles                                                      
>       328096538160      instructions              #    2.68  insn per cycle         
>        64530343063      MEM_INST_RETIRED.ALL_LOADS                                   
>        22900705491      MEM_INST_RETIRED.ALL_STORES                                   
>        19815558484      MEM_INST_RETIRED.SPLIT_LOADS                                   
>          701176106      MEM_INST_RETIRED.SPLIT_STORES    
> 
> Presence of scalar peel loop before the vector loop can save this penalty but given its operating over block streams  it may be tricky. 
> We should also extend the scope of optimization (preferably in this PR or in subsequent one) to optimize [MAC computation routine accepting ByteBuffer.](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java#L116),

To close this thread.. @jatin-bhateja and I talked and realized that it is not possible to re-align input here. At least not with peeling with scalar loop. Scalar loop peels full blocks only (i.e. 16 bytes at a time). So out of 64 positions, 1 is already aligned, 3 could be aligned with the right peel, and 60 will land badly regardless.

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

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


From duke at openjdk.org  Fri Nov  4 14:40:45 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 14:40:45 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <4AB7TAZwydDonBwfxasMLmgVIQuaLgMUxck7eCbzYxw=.a9062602-90d4-4bde-baff-629bea466527@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>
 <4AB7TAZwydDonBwfxasMLmgVIQuaLgMUxck7eCbzYxw=.a9062602-90d4-4bde-baff-629bea466527@github.com>
Message-ID: <tZyP57PymZoHKFEd2x4U9muSBSp6taAXyu-GQdhwkzw=.2c78e05a-eacd-4315-b1a3-d96db81b58d7@github.com>

On Fri, 28 Oct 2022 20:58:33 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

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

thread resumed below

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

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


From duke at openjdk.org  Fri Nov  4 14:40:46 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 14:40:46 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
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: <jdvVk9YyVGlfhzbzbYo9A1IbGKQdWjFSx6-PKDh8RvA=.275f6e48-b15d-4aaa-8da7-73b3f752c3c3@github.com>

On Tue, 18 Oct 2022 22:51:51 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>>  - address Jamil's review
>>  - invalidkeyexception and some review comments
>>  - extra whitespace character
>>  - 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
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9d3b4ef2...38d9e83c
>
> 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.

done, added a flag

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

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


From mullan at openjdk.org  Fri Nov  4 14:55:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Nov 2022 14:55:29 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException [v3]
In-Reply-To: <9eYVPkNafFv2S7uneyQH9Cb2w2wo8VmGOWKMGCmLWL8=.7940e3af-926e-4e3d-bab8-72946db21a05@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
 <9eYVPkNafFv2S7uneyQH9Cb2w2wo8VmGOWKMGCmLWL8=.7940e3af-926e-4e3d-bab8-72946db21a05@github.com>
Message-ID: <OSbK5kKQbOWbHYH4cx0bOhFxPUf2FOatPv3b0zXZSPA=.96d44aa5-acee-4839-8a85-1f6e334bd50f@github.com>

On Fri, 4 Nov 2022 08:44:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small adjustments to javadoc, some exceptions and add test coding

Everything LGTM now. Thanks.

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

Marked as reviewed by mullan (Reviewer).

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


From mbaesken at openjdk.org  Fri Nov  4 15:18:30 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Nov 2022 15:18:30 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException [v3]
In-Reply-To: <9eYVPkNafFv2S7uneyQH9Cb2w2wo8VmGOWKMGCmLWL8=.7940e3af-926e-4e3d-bab8-72946db21a05@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
 <9eYVPkNafFv2S7uneyQH9Cb2w2wo8VmGOWKMGCmLWL8=.7940e3af-926e-4e3d-bab8-72946db21a05@github.com>
Message-ID: <GtipJJjMva65pZeU8ZIAjsdknYylNGBF4OXQISgH3ws=.8ad8e62c-6eeb-4fe7-a2b5-57772646e48b@github.com>

On Fri, 4 Nov 2022 08:44:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small adjustments to javadoc, some exceptions and add test coding

Hi Sean, thanks for the review !

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

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


From weijun at openjdk.org  Fri Nov  4 15:53:50 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 4 Nov 2022 15:53:50 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v4]
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <klHSlwF4w2qNx8A8_f9K886UmVJyGWO3-N60nqx16Xc=.5ac295b8-ba7b-41d2-b307-1fefb57644db@github.com>

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

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

  more cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10959/files
  - new: https://git.openjdk.org/jdk/pull/10959/files/26a1f5c7..f4b3d09a

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

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

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


From mdoerr at openjdk.org  Fri Nov  4 15:54:03 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 4 Nov 2022 15:54:03 GMT
Subject: RFR: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException [v3]
In-Reply-To: <9eYVPkNafFv2S7uneyQH9Cb2w2wo8VmGOWKMGCmLWL8=.7940e3af-926e-4e3d-bab8-72946db21a05@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
 <9eYVPkNafFv2S7uneyQH9Cb2w2wo8VmGOWKMGCmLWL8=.7940e3af-926e-4e3d-bab8-72946db21a05@github.com>
Message-ID: <KbsRTEMQLaA43k5MQ8aT_fOpJOGdnsULvJc3Oz4OTU4=.2c7d1f88-d812-4c66-8eb0-5c0b07492bbc@github.com>

On Fri, 4 Nov 2022 08:44:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small adjustments to javadoc, some exceptions and add test coding

LGTM, too.

test/jdk/java/security/Exceptions/ChainingConstructors.java line 189:

> 187: 
> 188:         InvalidParameterException ipe =
> 189:                 new InvalidParameterException(cause);

Indentation looks unusual, but it's consistent with some other parts. No need to change!

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

Marked as reviewed by mdoerr (Reviewer).

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


From coffeys at openjdk.org  Fri Nov  4 15:58:01 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 4 Nov 2022 15:58:01 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v5]
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: <nNRUMHWFV-vlqOAlqxTfPUwMU1C9QtlqyiryyB4hM3Y=.e29af3f2-db9d-40fe-a77a-b8acf4026faf@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:

  Further code review comments and new keytool test coverage with JFR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10422/files
  - new: https://git.openjdk.org/jdk/pull/10422/files/f430a3ee..e3635647

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

  Stats: 59 lines in 4 files changed: 48 ins; 4 del; 7 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 xuelei.f at gmail.com  Fri Nov  4 15:58:03 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Fri, 4 Nov 2022 08:58:03 -0700
Subject: TLS1.3 record padding
In-Reply-To: <CAMrH03KY5E6deE6+Fxqv_aXyg1HWObkCc=7g-tHDJmyczxjGLQ@mail.gmail.com>
References: <CAMrH03KY5E6deE6+Fxqv_aXyg1HWObkCc=7g-tHDJmyczxjGLQ@mail.gmail.com>
Message-ID: <EA5188D2-5B6B-4BE3-AD2D-68CA3BC16D34@gmail.com>

The padding may be also necessary to prevent from a kind of attacks, besides hiding the length.  But I cannot recall the details.

Removing padding may be not the direction.  Instead, a padding length customizable solution may be more flexible.  Here is an enhancement request in JBS (https://bugs.openjdk.org/browse/JDK-8244983 <https://bugs.openjdk.org/browse/JDK-8244983>), please feel free to take it.    

Xuelei

> On Nov 4, 2022, at 4:21 AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
> 
> Hello,
> I noticed that we're padding every TLS 1.3 record with exactly 16 zeros [1]. I'd like to remove that padding to conserve network bandwidth and processing power. Thoughts?
> 
> Some background:
> - TLS 1.3 RFC [2] defines padding as a means to hide the size of the traffic. Constant-length padding does not hide it, obviously. The RFC does not define any padding policies ("Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification.")
> - OpenSSL [3] defines 2 methods to select the length of the padding block: the user may provide a callback that selects adequate padding length, or provide block length, and then every record is padded to a multiple of block length. By default OpenSSL does not pad records.
> - I'm not aware of any discussions around record padding on this list, which suggests that there's no demand for more complex padding schemes.
> 
> Regards,
> Daniel
> 
> [1] https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L302 <https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/OutputRecord.java#L302>
> [2] https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4 <https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4>
> [3] https://www.openssl.org/docs/man1.1.1/man3/SSL_set_record_padding_callback.html <https://www.openssl.org/docs/man1.1.1/man3/SSL_set_record_padding_callback.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221104/cd7eae6f/attachment.htm>

From jnimeh at openjdk.org  Fri Nov  4 16:32:16 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 4 Nov 2022 16:32:16 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
In-Reply-To: <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
Message-ID: <f0Bv-td_2zmCQ7F8RjVS-O5SK36DolXJt83FD34zsuY=.d5336884-e8ae-4f01-bf23-47f6fec785c7@github.com>

On Fri, 4 Nov 2022 03:20:11 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>  - address Jamil's review
>  - invalidkeyexception and some review comments
>  - extra whitespace character
>  - 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
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9d3b4ef2...38d9e83c

src/hotspot/share/opto/library_call.cpp line 7036:

> 7034:   assert(r_start, "r array is NULL");
> 7035: 
> 7036:   Node* call = make_runtime_call(RC_LEAF,

Can we safely change this to `RC_LEAF | RC_NO_FP`?  For the ChaCha20 block intrinsic I'm working on I've been using that parameter because I'm not touching the FP registers and that looks to be the case here (though your intrinsic is a lot more complicated than mine so I may have missed something).  I believe the GHASH and AES library call routines also call `make_runtime_call()` in this way.

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

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


From ascarpino at openjdk.org  Fri Nov  4 17:29:47 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 4 Nov 2022 17:29:47 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
In-Reply-To: <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
Message-ID: <_KivimSjPXP-a8M1gaVOxawfozZ8K4mOkvWwb1w00J8=.70c924a0-8d7e-4673-977c-01d1044ae73c@github.com>

On Fri, 4 Nov 2022 03:20:11 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>  - address Jamil's review
>  - invalidkeyexception and some review comments
>  - extra whitespace character
>  - 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
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9d3b4ef2...38d9e83c

Thanks for moving the conversion of R and A from the java code into the intrinsic.  That certainly reduced the footprint on the java code with regard to performance and code flow.

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

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


From duke at openjdk.org  Fri Nov  4 17:29:48 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 17:29:48 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
In-Reply-To: <f0Bv-td_2zmCQ7F8RjVS-O5SK36DolXJt83FD34zsuY=.d5336884-e8ae-4f01-bf23-47f6fec785c7@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
 <f0Bv-td_2zmCQ7F8RjVS-O5SK36DolXJt83FD34zsuY=.d5336884-e8ae-4f01-bf23-47f6fec785c7@github.com>
Message-ID: <yakJWzO8mmn5VJ0WpAEAwo1DHqpq2xkkD-oQol0gEhA=.dc776ad9-a666-4928-b59c-087af1052508@github.com>

On Fri, 4 Nov 2022 16:28:51 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>>  - address Jamil's review
>>  - invalidkeyexception and some review comments
>>  - extra whitespace character
>>  - 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
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9d3b4ef2...38d9e83c
>
> src/hotspot/share/opto/library_call.cpp line 7036:
> 
>> 7034:   assert(r_start, "r array is NULL");
>> 7035: 
>> 7036:   Node* call = make_runtime_call(RC_LEAF,
> 
> Can we safely change this to `RC_LEAF | RC_NO_FP`?  For the ChaCha20 block intrinsic I'm working on I've been using that parameter because I'm not touching the FP registers and that looks to be the case here (though your intrinsic is a lot more complicated than mine so I may have missed something).  I believe the GHASH and AES library call routines also call `make_runtime_call()` in this way.

Makes sense to me, will put it in and re-test (no fp registers anywhere in the intrinsic). Thanks!

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

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


From mullan at openjdk.org  Fri Nov  4 20:02:27 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Nov 2022 20:02:27 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v4]
In-Reply-To: <V1OuHa1zaGPrt0-Z6psqPYPHdr8750f2gr1YWUSgni4=.256855bf-8f29-4bfe-bc75-27343dd139b8@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <eDPdZuCpZvZhAsDl19MaKYNUOOiXqynSNWLIU7TCP5g=.4c339f75-32fc-4a3b-bea4-d3d26cd07434@github.com>
 <9z2MSQkoYiC1YDeXGr56TPNIIuHf09fQxTrcQzygNkI=.5fb43b63-29ea-49fc-8d89-242b400bae82@github.com>
 <V1OuHa1zaGPrt0-Z6psqPYPHdr8750f2gr1YWUSgni4=.256855bf-8f29-4bfe-bc75-27343dd139b8@github.com>
Message-ID: <aNxbtJS1J-VskBW9VRRbN8dAY4sc7prq48vlbJKOrRY=.e608fd93-75f5-458a-8da7-c2a906394d71@github.com>

On Thu, 3 Nov 2022 23:25:29 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> > Do you think it is that useful to have keytool record events? Ok, I guess some apps could be execing keytool, but that would be in a separate process, and probably wouldn't have JFR enabled. Also, these certs, if used for authentication usages will eventually come back into the runtime through CertificateFactory.
> 
> I figured it would be useful. keytool is an important generator of X509 certs. Why not give the opportunity to record them if JFR is enabled etc ? -J-XX:StartFlightRecording passed to keytool is sufficient to capture a recording.
> 
> The certs could be deployed out to any software stack I guess. Java being one possibility.

I think the threat level is a bit different than certificates that are actually parsed and potentially being used by applications to authenticate servers, etc, so I would be wary of treating these events with equivalence. These certificates may never be used by applications, and if they are, then there will be an event for that. 

Also with keytool, you have direct control over what algorithms, key sizes, validity, etc are being used, whereas in an app case, you don't really know until you parse the certificate and see what it contains.

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

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


From coffeys at openjdk.org  Fri Nov  4 20:32:31 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 4 Nov 2022 20:32:31 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v5]
In-Reply-To: <nNRUMHWFV-vlqOAlqxTfPUwMU1C9QtlqyiryyB4hM3Y=.e29af3f2-db9d-40fe-a77a-b8acf4026faf@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <nNRUMHWFV-vlqOAlqxTfPUwMU1C9QtlqyiryyB4hM3Y=.e29af3f2-db9d-40fe-a77a-b8acf4026faf@github.com>
Message-ID: <jCfhde_6o3pCwxOqzwRZqAk5ACptT12zLTyFMjqe5I4=.fa09e904-1431-47ab-9a57-0047bc2005d5@github.com>

On Fri, 4 Nov 2022 15:58:01 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:
> 
>   Further code review comments and new keytool test coverage with JFR

I'd agree with your thoughts. While it may not be a threat level, it's still a useful information point, especially in environments where hard coded values might get embedded in some type of key generation tool. Not many might be interested but there's a option there now with JFR to view this data at least. I don't think many will configure keytool to run with JFR.

Happy to revert the keytool change but I don't see it being too invasive in code changes.

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

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


From duke at openjdk.org  Fri Nov  4 21:01:40 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 4 Nov 2022 21:01:40 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: <p7zf1K8ddqMuzyjT13mfYVS28z-VWZsrsGvOF2F3upM=.359cfea5-4dde-46bc-95d3-1ba6728e65ea@github.com>

On Tue, 25 Oct 2022 00:31:07 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski 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;
> 
> The ByteBuffer version can also benefit from this optimization if it has array as backing storage.

I spent some time looking at `engineUpdate(ByteBuffer buf)`. I think it makes sense to make it into a separate PR. I think I figured out the code, but its rather 'finicky'. The existing function is already rather clever; there are quite a few cases to get correct (`engineUpdate(byte[] input, int offset, int len)` unrolled the decision tree, so its easier to reason about)

For future reference, patched but untested:


    void engineUpdate(ByteBuffer buf) {
        int remaining = buf.remaining();
        while (remaining > 0) {
            int bytesToWrite = Integer.min(remaining,
                    BLOCK_LENGTH - blockOffset);

            if (bytesToWrite >= BLOCK_LENGTH) {
                // Have at least one full block in the buf, process all full blocks
                int blockMultipleLength = buf.remaining() & (~(BLOCK_LENGTH-1));
                processMultipleBlocks(buf, blockMultipleLength);
                remaining -= blockMultipleLength;
            } else {
                // We have some left-over data from previous updates, so
                // copy that into the holding block until we get a full block.
                buf.get(block, blockOffset, bytesToWrite);
                blockOffset += bytesToWrite;

                if (blockOffset >= BLOCK_LENGTH) {
                    processBlock(block, 0, BLOCK_LENGTH);
                    blockOffset = 0;
                }
                remaining -= bytesToWrite;
            }
        }
    }

    private void processMultipleBlocks(ByteBuffer buf, int blockMultipleLength) {
        if (buf.hasArray()) {
            byte[] input = buf.array();
            int offset = buf.arrayOffset();

            Objects.checkFromIndexSize(offset, blockMultipleLength, input.length);
            a.checkLimbsForIntrinsic();
            r.checkLimbsForIntrinsic();
            processMultipleBlocks(input, offset, blockMultipleLength);
            return;
        }

        while (blockMultipleLength > 0) {
            processBlock(buf, BLOCK_LENGTH);
            blockMultipleLength -= BLOCK_LENGTH;
        }
    }


But it might make more sense to emulate `engineUpdate(byte[] input, int offset, int len)` and unroll the loop. (Hint: to test for Buffer without array, create read-only buffer:

    public final boolean hasArray() {
        return (hb != null) && !isReadOnly;
    }

end hint)

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

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


From sviswanathan at openjdk.org  Fri Nov  4 21:05:30 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 4 Nov 2022 21:05:30 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v5]
In-Reply-To: <p7zf1K8ddqMuzyjT13mfYVS28z-VWZsrsGvOF2F3upM=.359cfea5-4dde-46bc-95d3-1ba6728e65ea@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>
 <p7zf1K8ddqMuzyjT13mfYVS28z-VWZsrsGvOF2F3upM=.359cfea5-4dde-46bc-95d3-1ba6728e65ea@github.com>
Message-ID: <Eqsi1O08UMG0Oq-eUNGck6Y1ALmsoKHZ9k-cDS_C-DY=.f9519ec0-7ecd-4f0d-9137-f1656b9dcc4b@github.com>

On Fri, 4 Nov 2022 20:59:10 GMT, Volodymyr Paprotski <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;
>> 
>> The ByteBuffer version can also benefit from this optimization if it has array as backing storage.
>
> I spent some time looking at `engineUpdate(ByteBuffer buf)`. I think it makes sense to make it into a separate PR. I think I figured out the code, but its rather 'finicky'. The existing function is already rather clever; there are quite a few cases to get correct (`engineUpdate(byte[] input, int offset, int len)` unrolled the decision tree, so its easier to reason about)
> 
> For future reference, patched but untested:
> 
> 
>     void engineUpdate(ByteBuffer buf) {
>         int remaining = buf.remaining();
>         while (remaining > 0) {
>             int bytesToWrite = Integer.min(remaining,
>                     BLOCK_LENGTH - blockOffset);
> 
>             if (bytesToWrite >= BLOCK_LENGTH) {
>                 // Have at least one full block in the buf, process all full blocks
>                 int blockMultipleLength = buf.remaining() & (~(BLOCK_LENGTH-1));
>                 processMultipleBlocks(buf, blockMultipleLength);
>                 remaining -= blockMultipleLength;
>             } else {
>                 // We have some left-over data from previous updates, so
>                 // copy that into the holding block until we get a full block.
>                 buf.get(block, blockOffset, bytesToWrite);
>                 blockOffset += bytesToWrite;
> 
>                 if (blockOffset >= BLOCK_LENGTH) {
>                     processBlock(block, 0, BLOCK_LENGTH);
>                     blockOffset = 0;
>                 }
>                 remaining -= bytesToWrite;
>             }
>         }
>     }
> 
>     private void processMultipleBlocks(ByteBuffer buf, int blockMultipleLength) {
>         if (buf.hasArray()) {
>             byte[] input = buf.array();
>             int offset = buf.arrayOffset();
> 
>             Objects.checkFromIndexSize(offset, blockMultipleLength, input.length);
>             a.checkLimbsForIntrinsic();
>             r.checkLimbsForIntrinsic();
>             processMultipleBlocks(input, offset, blockMultipleLength);
>             return;
>         }
> 
>         while (blockMultipleLength > 0) {
>             processBlock(buf, BLOCK_LENGTH);
>             blockMultipleLength -= BLOCK_LENGTH;
>         }
>     }
> 
> 
> But it might make more sense to emulate `engineUpdate(byte[] input, int offset, int len)` and unroll the loop. (Hint: to test for Buffer without array, create read-only buffer:
> 
>     public final boolean hasArray() {
>         return (hb != null) && !isReadOnly;
>     }
> 
> end hint)

Sounds good, let us do the ByteBuffer support as a follow on PR.

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

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


From wetmore at openjdk.org  Fri Nov  4 21:07:45 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 4 Nov 2022 21:07:45 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites [v3]
In-Reply-To: <2nzPxoeWroYa-ugHM5rWBouWN6jhUHhV7B95GMYQokM=.de8e33b4-4dcf-4eb0-b94d-3722a6f72a9d@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
 <2nzPxoeWroYa-ugHM5rWBouWN6jhUHhV7B95GMYQokM=.de8e33b4-4dcf-4eb0-b94d-3722a6f72a9d@github.com>
Message-ID: <35HAoBjt9ML2dUc88XO6s9iLRRaleA2nmGulyuiECmM=.42fbcb67-a0f6-4020-97e1-2acaa7da4b48@github.com>

On Fri, 4 Nov 2022 13:12:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
>> 
>> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix "screcy" typos.

Thanks.

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

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


From wetmore at openjdk.org  Fri Nov  4 21:07:45 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 4 Nov 2022 21:07:45 GMT
Subject: RFR: 8279164: Disable TLS_ECDH_* cipher suites [v3]
In-Reply-To: <bmaBElzfLMRQirarFRuv-hNhmEmbV5j1dP8euEx85xQ=.c9318149-20e0-4104-976a-8dfaa69da6a7@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
 <KwiLw0od343wXtiWResvCvwHpZZ8slC1shhmA3K7LcE=.c8543a58-cf93-476a-9530-4b567ace86a5@github.com>
 <7CCvR1dgc1Lqmt4ay7NYMK9HbqZIlw-OMkRM_5dz79M=.f367a780-e023-4b14-a79b-686b5f64f1e1@github.com>
 <bmaBElzfLMRQirarFRuv-hNhmEmbV5j1dP8euEx85xQ=.c9318149-20e0-4104-976a-8dfaa69da6a7@github.com>
Message-ID: <8dHOTu49jZD6UIzHhuMFH2MALGPrPqYXT6rVT_DidmQ=.71f85cd5-1173-4388-8cba-bebf2e72a1a8@github.com>

On Fri, 4 Nov 2022 13:08:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java line 85:
>> 
>>> 83:         "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
>>> 84: 
>>> 85:         // AES_256(GCM) - not forward screcy
>> 
>> Can you please fix the rest of the"screcy" typos in this file?
>
> Fixed.

Thanks.

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

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


From bradford.wetmore at oracle.com  Sat Nov  5 03:01:50 2022
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 4 Nov 2022 20:01:50 -0700
Subject: TLS1.3 record padding
In-Reply-To: <EA5188D2-5B6B-4BE3-AD2D-68CA3BC16D34@gmail.com>
References: <CAMrH03KY5E6deE6+Fxqv_aXyg1HWObkCc=7g-tHDJmyczxjGLQ@mail.gmail.com>
 <EA5188D2-5B6B-4BE3-AD2D-68CA3BC16D34@gmail.com>
Message-ID: <7f745633-4aec-5906-0223-735ce2d76b42@oracle.com>



On 11/4/2022 8:58 AM, Xuelei Fan wrote:
> The padding may be also necessary to prevent from a kind of attacks, 
> besides hiding the length. ?But I cannot recall the details.

I have a vague recollection of that, but I was thinking it was something 
pre-1.3.  But I'm not seeing any special padding in the pre-TLSv1.3 
changeset:

c7c819cd8bba9f204f23b24a0d788fda61823eb3

so I may be off in my recollections.

> ?Here is an enhancement 
> request in JBS (https://bugs.openjdk.org/browse/JDK-8244983 
> <https://bugs.openjdk.org/browse/JDK-8244983>), please feel free to take 
> it.

Ah yes.

Brad



From aturbanov at openjdk.org  Sun Nov  6 14:41:18 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 6 Nov 2022 14:41:18 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v4]
In-Reply-To: <klHSlwF4w2qNx8A8_f9K886UmVJyGWO3-N60nqx16Xc=.5ac295b8-ba7b-41d2-b307-1fefb57644db@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <klHSlwF4w2qNx8A8_f9K886UmVJyGWO3-N60nqx16Xc=.5ac295b8-ba7b-41d2-b307-1fefb57644db@github.com>
Message-ID: <kkWpyG2vFsGn96dgCa7f31oxd3qooKLdz7lDkpoC-5E=.a437fb00-1bd9-4d17-90af-b7e5ecf2cb7b@github.com>

On Fri, 4 Nov 2022 15:53:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
>> 
>> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
>> 
>> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
>> 
>> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
>> 
>> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
>> 
>> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

src/java.base/share/classes/sun/security/x509/CertificateX509Key.java line 102:

> 100:      */
> 101:     public PublicKey getKey() {
> 102:         return(key);

Suggestion:

        return key;

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

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


From weijun at openjdk.org  Sun Nov  6 18:20:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 6 Nov 2022 18:20:27 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v4]
In-Reply-To: <kkWpyG2vFsGn96dgCa7f31oxd3qooKLdz7lDkpoC-5E=.a437fb00-1bd9-4d17-90af-b7e5ecf2cb7b@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <klHSlwF4w2qNx8A8_f9K886UmVJyGWO3-N60nqx16Xc=.5ac295b8-ba7b-41d2-b307-1fefb57644db@github.com>
 <kkWpyG2vFsGn96dgCa7f31oxd3qooKLdz7lDkpoC-5E=.a437fb00-1bd9-4d17-90af-b7e5ecf2cb7b@github.com>
Message-ID: <x-ZqkddFyza5lIvN8sr6U8knVSrumxlNfLNGbutFz6A=.a2ade17b-69f4-44e0-a053-1a1131935e70@github.com>

On Sun, 6 Nov 2022 14:37:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more cleanup
>
> src/java.base/share/classes/sun/security/x509/CertificateX509Key.java line 102:
> 
>> 100:      */
>> 101:     public PublicKey getKey() {
>> 102:         return(key);
> 
> Suggestion:
> 
>         return key;

Thanks. I was just copying lines from the old get method. Will fix.

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

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


From weijun at openjdk.org  Sun Nov  6 22:00:41 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 6 Nov 2022 22:00:41 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v5]
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <iPpgwYZSuI-9Lg9IZgL7SpvshS8wWsmw5gdolLtk-Kw=.f0e2df6b-772f-4e43-90b3-cfbb5575ea4c@github.com>

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

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

  return (abc) to return abc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10959/files
  - new: https://git.openjdk.org/jdk/pull/10959/files/f4b3d09a..b4453f66

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

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:06 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:06 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
Message-ID: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>

This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:

- x86_64: AVX, AVX2 and AVX512
- aarch64: platforms that support the advanced SIMD instructions

Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)

x86_64
Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz

Java only (-XX:-UseChaCha20Intrinsics)
--------------------------------------
Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s

Intrinsics enabled (-XX:UseAVX=1)
---------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s

Intrinsics enabled (-XX:UseAVX=2)
---------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s

Intrinsics enabled (-XX:UseAVX=3)
---------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s

aarch64
Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
  part : 0xd0c, revision : 1

Java only (-XX:-UseChaCha20Intrinsics)
--------------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s

Intrinsics enabled
------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s

Special thanks to the folks who have made many helpful comments while this PR was in draft form.

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

Commit messages:
 - consolidate single-structure ld_st methods
 - Add intrinsic tests that target specific SIMD instruction sets
 - add explicit int cast on counter rollover protection
 - Merge with main
 - expand input sizes for ChaCha20 and ChaCha20-Poly1305 micro benchmarks
 - rename chapoly to chacha
 - make alg-specific stub/macro files exclusive to chacha20
 - Remove stubRoutines constant generation method, replace using emit_int64/adr
 - Use block-parallel intrinsic, remove qr-parallel intrinsic, use sub/cbnz for loop control
 - Minor fixes from comments
 - ... and 30 more: https://git.openjdk.org/jdk/compare/c7b95a89...c79abe34

Changes: https://git.openjdk.org/jdk/pull/7702/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7702&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8247645
  Stats: 1590 lines in 30 files changed: 1552 ins; 4 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/7702.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7702/head:pull/7702

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


From aph at openjdk.org  Mon Nov  7 07:34:09 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 7 Nov 2022 07:34:09 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <Beacw6Zz39Sfy-LwdkOi7Q9scH-i3fqtz_sVygbWdi0=.01208ee7-838d-4a6e-9de5-ad2561c5e337@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

What's the status of this?

Please my friend, let's get this finished or I'm going to have to do it myself.

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2521:

> 2519: #undef INSN3
> 2520: #undef INSN4
> 2521: 

This code to handle the AdvSIMD load/store single structure and AdvSIMD load/store single structure (post-indexed) is excessive.

Every one of these instructions has the the format, 

`0|Q|0011010|L|R|00000|opcode|S|size|Rn|Rt`

or

`0|Q|0011011|L|R|   Rm|opcode|S|size|Rn|Rt`

Perhaps consider using a `RegSet regs` for the registers. Then the instruction encoding to use (1,2,3,or 4 consecutive registers) can be picked up from `regs.size()`. There only needs to be a single routine for all of the `ld_st` variants.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4068:

> 4066:         __ ext(c, __ T16B, c, c, cCnt);             \
> 4067:         __ ext(d, __ T16B, d, d, dCnt);             \
> 4068: 

There's a fairly extensive use of macros here for the rounds, but I don't think there's any need for them to be macros. `SHIFT_LANES` and all the other macros here should be functions. This would reduce the size of the libjvm.so binary.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4141:

> 4139:     // rotation tbl instruction.
> 4140:     __ lea(tmpAddr, ExternalAddress(
> 4141:                 StubRoutines::aarch64::chacha20_constdata()));

Better to move `cc20_gen_constdata()` to the start of `cc20_gen_constdata()`, mark it with a `Label`, and use `adr(tmpAddr, LABEL);` .

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:12 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:12 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <Beacw6Zz39Sfy-LwdkOi7Q9scH-i3fqtz_sVygbWdi0=.01208ee7-838d-4a6e-9de5-ad2561c5e337@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <Beacw6Zz39Sfy-LwdkOi7Q9scH-i3fqtz_sVygbWdi0=.01208ee7-838d-4a6e-9de5-ad2561c5e337@github.com>
Message-ID: <2t37RDNwT7XZqqddyBSaUlzj21ERuVhy8XH3EN8RCb4=.e878bb9e-9b90-499e-8289-ac3abe6b62db@github.com>

On Fri, 2 Sep 2022 09:32:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
>> 
>> - x86_64: AVX, AVX2 and AVX512
>> - aarch64: platforms that support the advanced SIMD instructions
>> 
>> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
>> 
>> x86_64
>> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
>> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
>> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=1)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=2)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=3)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
>> 
>> aarch64
>> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>>   part : 0xd0c, revision : 1
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
>> 
>> Intrinsics enabled
>> ------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
>> 
>> Special thanks to the folks who have made many helpful comments while this PR was in draft form.
>
> src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2521:
> 
>> 2519: #undef INSN3
>> 2520: #undef INSN4
>> 2521: 
> 
> This code to handle the AdvSIMD load/store single structure and AdvSIMD load/store single structure (post-indexed) is excessive.
> 
> Every one of these instructions has the the format, 
> 
> `0|Q|0011010|L|R|00000|opcode|S|size|Rn|Rt`
> 
> or
> 
> `0|Q|0011011|L|R|   Rm|opcode|S|size|Rn|Rt`
> 
> Perhaps consider using a `RegSet regs` for the registers. Then the instruction encoding to use (1,2,3,or 4 consecutive registers) can be picked up from `regs.size()`. There only needs to be a single routine for all of the `ld_st` variants.

Thanks for the suggestion.  I will look into this.  I can see how `regs.size()` could simplify these macros.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4068:
> 
>> 4066:         __ ext(c, __ T16B, c, c, cCnt);             \
>> 4067:         __ ext(d, __ T16B, d, d, dCnt);             \
>> 4068: 
> 
> There's a fairly extensive use of macros here for the rounds, but I don't think there's any need for them to be macros. `SHIFT_LANES` and all the other macros here should be functions. This would reduce the size of the libjvm.so binary.

Thanks for the feedback.  I've been wondering if I might need something like a macroAssembler_<arch>_chapoly.cpp file to handle these kinds of things and future functions for Poly1305 when I start in on that.  I wasn't aware of the impact on libjvm.so going the macro approach versus functions.  I'll pull these out to functions.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4141:
> 
>> 4139:     // rotation tbl instruction.
>> 4140:     __ lea(tmpAddr, ExternalAddress(
>> 4141:                 StubRoutines::aarch64::chacha20_constdata()));
> 
> Better to move `cc20_gen_constdata()` to the start of `cc20_gen_constdata()`, mark it with a `Label`, and use `adr(tmpAddr, LABEL);` .

I think I see what you're saying from looking at `generate_sha1_implCompress()` and how it uses adr.  I also see what looks like a similar approach in some functions in the same file where it defines the constant value via a `static const uint64_t[] foo = { ... };` and then loads that address via `lea(reg, ExternalAddress((address) foo)` and proceeds from there (see `generate_sha3_implCompress()`).  To my eye that looks a bit more straightforward and the approach seems to be used more often than the adr approach in the file for defining constants.  What I don't know is if one approach is better than the other for other reasons like performance or memory consumption.  Do you have any feelings one way or the other?

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:11 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:11 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <PyjrUPWy5yvYJIb7Vu3s8_H2XEVWlxZ_ffHXFhDY2bg=.ef20c323-880b-4b72-aff9-4445dd2dfe1d@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

Work is ongoing.  I'm making a few refinements on the x86_64 side and will remove x86_32 stub generators but hopefully will open this up for formal review soon.  I've also extended the single-structure st4 to now do single structure st1/2/3/4.  I just needed to do a little internal playtesting with them to make sure I was still getting the correct results.  I don't plan on using st1/2/3 but since they all use the same opcode generation macros as st4 I figured it would be worth including them.  That will all show up in my next commit/push.

FYI, I'm holding off on some changes that @iwanowww had suggested in order to wait for #10111 and #10124 to integrate (but more for the former).  I think I may end up shifting the CC20 intrinsics into separate files like Vladimir is proposing for AES.  Also it has been a while since I've merged the master branch so it could do with a refresh to get 10111 in there.

Quick update: I've run into a strange "Unschedulable graph" issue being raised at the C2 layer of things.  It happens specifically with the ChaCha20Poly1305.decrypt microbenchmark and only on AVX512 (with -XX:UseAVX=3).  Investigation is ongoing, but points away (right now) from the stub itself and may be a latent C2 issue that is being uncovered.  I have run hundreds of thousands of AVX512 cc20-p1305 decrypts of various sizes outside the microbenchmark and never run into this.  I will share more as I learn it.

Quick update on the unschedulable graph issue: It appears that we're running into an issue related to either [JDK-8252848](https://bugs.openjdk.org/browse/JDK-8252848) or [JDK-8266951](https://bugs.openjdk.org/browse/JDK-8266951).  A new issue to track this has been created in [JDK-8296233](https://bugs.openjdk.org/browse/JDK-8296233).  While this has only ever been seen thus far with the ChaCha20Poly1305.decrypt microbenchmark when -XX:UseAVX=3 is employed, the nature of the issue is such that it could happen with any of the intrinsics since it is triggered more by the library call change to C2's IR.  But this has never been seen outside of the current narrow configuration to date.

Good news.  It turns out that [JDK-8292780](https://bugs.openjdk.org/browse/JDK-8292780) is a fix for the underlying issue that caused the benchmark to crash.  Once I did a pull/merge and retested the benchmarks are no longer failing.

src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3636:

> 3634:     const XMMRegister zmm_cState = xmm6;
> 3635:     const XMMRegister zmm_dState = xmm7;
> 3636:     const XMMRegister zmm_addMask = xmm8;

Whoops!  It looks like there may not be an xmm8 register available to 32-bit architectures.  This may need a little creative restructuring in order to make it work.  Or we might just add from the ExternalAddress directly in this specific case.

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

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


From aph at openjdk.org  Mon Nov  7 07:34:13 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 7 Nov 2022 07:34:13 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <2t37RDNwT7XZqqddyBSaUlzj21ERuVhy8XH3EN8RCb4=.e878bb9e-9b90-499e-8289-ac3abe6b62db@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <Beacw6Zz39Sfy-LwdkOi7Q9scH-i3fqtz_sVygbWdi0=.01208ee7-838d-4a6e-9de5-ad2561c5e337@github.com>
 <2t37RDNwT7XZqqddyBSaUlzj21ERuVhy8XH3EN8RCb4=.e878bb9e-9b90-499e-8289-ac3abe6b62db@github.com>
Message-ID: <9Y4BmZrQIbE94pTuo7vqgMi-v_EFVWpMOCwXVRTW2b4=.c2d5cc64-e4d3-4e7e-ab79-c4960e7209e9@github.com>

On Fri, 2 Sep 2022 16:52:02 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2521:
>> 
>>> 2519: #undef INSN3
>>> 2520: #undef INSN4
>>> 2521: 
>> 
>> This code to handle the AdvSIMD load/store single structure and AdvSIMD load/store single structure (post-indexed) is excessive.
>> 
>> Every one of these instructions has the the format, 
>> 
>> `0|Q|0011010|L|R|00000|opcode|S|size|Rn|Rt`
>> 
>> or
>> 
>> `0|Q|0011011|L|R|   Rm|opcode|S|size|Rn|Rt`
>> 
>> Perhaps consider using a `RegSet regs` for the registers. Then the instruction encoding to use (1,2,3,or 4 consecutive registers) can be picked up from `regs.size()`. There only needs to be a single routine for all of the `ld_st` variants.
>
> Thanks for the suggestion.  I will look into this.  I can see how `regs.size()` could simplify these macros.

Another thing that may be better than a `RegSet`. If you use a C++11 template parameter pack, you can do something like this:


template<typename R, typename... Rx>
void foo(R first_register, Rx... more_registers) {
  const R regs[] = { first_register, more_registers... };  // An array that contains the more regs
  const int count = sizeof...(more_registers);             // The count of more regs
  ...
}

And then you can use the same logic, regardless of the number of registers.

> What I don't know is if one approach is better than the other for other reasons like performance or memory consumption. Do you have any feelings one way or the other?

`ADR` is smaller and faster at runtime, `lea(reg, ExternalAddress((address) foo)` with `const uint64_t[] foo = { ... }` will be slightly faster at start-up time. It makes no sense to emit the table with `emit_data64()` then take the address of the table you've just emitted with `lea`. That's worse for startup time _and_ for runtime. So I don't much mind emitting the table at runtime, but if you do, get its address with `ADR`.

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

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


From dchuyko at openjdk.org  Mon Nov  7 07:34:15 2022
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 7 Nov 2022 07:34:15 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <07z1ueSVi_yO56oR5nT04JKrU_Vui1k7JsgxZrKEnbs=.16a0350b-1f76-4015-9419-035d26a78d82@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4156:

> 4154:     // Decrement and iterate
> 4155:     __ subs(loopCtr, loopCtr, 1);
> 4156:     __ cmp(loopCtr, (u1)0);

CMP probably can be removed or can there be just SUB and CBNZ?

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4306:

> 4304:     __ subs(loopCtr, loopCtr, 1);
> 4305:     __ cmp(loopCtr, (u1)0);
> 4306:     __ br(Assembler::NE, L_twoRounds);

Same thing about subs-cmp0-bne.

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:15 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:15 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <07z1ueSVi_yO56oR5nT04JKrU_Vui1k7JsgxZrKEnbs=.16a0350b-1f76-4015-9419-035d26a78d82@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <07z1ueSVi_yO56oR5nT04JKrU_Vui1k7JsgxZrKEnbs=.16a0350b-1f76-4015-9419-035d26a78d82@github.com>
Message-ID: <BCdk4pS1pfOgOe-i6plw1_EvJ8wLDUZKCCkilcg_xxA=.9cb99ab4-8beb-454d-9555-2b5ae5760673@github.com>

On Thu, 18 Aug 2022 14:26:47 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
>> 
>> - x86_64: AVX, AVX2 and AVX512
>> - aarch64: platforms that support the advanced SIMD instructions
>> 
>> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
>> 
>> x86_64
>> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
>> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
>> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=1)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=2)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=3)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
>> 
>> aarch64
>> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>>   part : 0xd0c, revision : 1
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
>> 
>> Intrinsics enabled
>> ------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
>> 
>> Special thanks to the folks who have made many helpful comments while this PR was in draft form.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4156:
> 
>> 4154:     // Decrement and iterate
>> 4155:     __ subs(loopCtr, loopCtr, 1);
>> 4156:     __ cmp(loopCtr, (u1)0);
> 
> CMP probably can be removed or can there be just SUB and CBNZ?

See my comment on the similar note below.  I will likely be removing this version of the intrinsic in favor of the _blockpar version.  I really like that second version better as it removes the need for the two sets of lane shifting operations on each of the 10 iterations.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4306:
> 
>> 4304:     __ subs(loopCtr, loopCtr, 1);
>> 4305:     __ cmp(loopCtr, (u1)0);
>> 4306:     __ br(Assembler::NE, L_twoRounds);
> 
> Same thing about subs-cmp0-bne.

Thanks for the suggestion.  I actually have a version of the _blockpar cc20 block function intrinsic that uses a C++ for-loop around the cc20_quarter_round macro calls to generate that portion of the stub.  I believe that effectively unrolls the loop in the resulting stub and removes the need for the subs, cmp and br for all 10 iterations.  Right now the aarch64 has two versions of the same block function as I was play testing both.  I will probably end up removing the _qr (quarter-round parallel) version and favor the _blockpar (block-parallel) version as they both are pretty comparable in terms of speed, but the block parallel version seems to be a little better.

I'm always open to these other ways of handling the loop control as assembly is not my strong suit so I appreciate the suggestion!

Interesting, I had not considered that.  Thanks for pointing that out.  I'm honestly not sure how to evaluate the impact of the generated code on the icache.  I'll look at the logic surrounding the ghash processBlocks(_wide) code to see how that decision is made.  I don't have an aversion to going back to an assembly-based loop using the suggestions that @dchuyko made and maybe that's the right choice if it means more compact code.

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

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


From aph at openjdk.org  Mon Nov  7 07:34:16 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 7 Nov 2022 07:34:16 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <BCdk4pS1pfOgOe-i6plw1_EvJ8wLDUZKCCkilcg_xxA=.9cb99ab4-8beb-454d-9555-2b5ae5760673@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <07z1ueSVi_yO56oR5nT04JKrU_Vui1k7JsgxZrKEnbs=.16a0350b-1f76-4015-9419-035d26a78d82@github.com>
 <BCdk4pS1pfOgOe-i6plw1_EvJ8wLDUZKCCkilcg_xxA=.9cb99ab4-8beb-454d-9555-2b5ae5760673@github.com>
Message-ID: <RS_tuxkIudqRFFwLEtUlzYnpSxsueee_Zu5SxAyv4nA=.f26a6f98-3533-4467-937c-261d1106fdb4@github.com>

On Thu, 18 Aug 2022 14:43:51 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4306:
>> 
>>> 4304:     __ subs(loopCtr, loopCtr, 1);
>>> 4305:     __ cmp(loopCtr, (u1)0);
>>> 4306:     __ br(Assembler::NE, L_twoRounds);
>> 
>> Same thing about subs-cmp0-bne.
>
> Thanks for the suggestion.  I actually have a version of the _blockpar cc20 block function intrinsic that uses a C++ for-loop around the cc20_quarter_round macro calls to generate that portion of the stub.  I believe that effectively unrolls the loop in the resulting stub and removes the need for the subs, cmp and br for all 10 iterations.  Right now the aarch64 has two versions of the same block function as I was play testing both.  I will probably end up removing the _qr (quarter-round parallel) version and favor the _blockpar (block-parallel) version as they both are pretty comparable in terms of speed, but the block parallel version seems to be a little better.
> 
> I'm always open to these other ways of handling the loop control as assembly is not my strong suit so I appreciate the suggestion!

Be careful about the code expansion. If you're not careful you'll blow away much of the icache for little benefit. For AES/GCM on AArch64 we have generate `_ghash_processBlocks()` and `generate_ghash_processBlocks_wide()`. We don't call the big one unless it's worth it. It all depends on how big the code turns out to be.

> Interesting, I had not considered that.  Thanks for pointing that out.  I'm honestly not sure how to evaluate the impact of the generated code on the icache.  I'll look at the logic surrounding the ghash processBlocks(_wide) code to see how that decision is made.  I don't have an aversion to going back to an assembly-based loop using the suggestions that @dchuyko made and maybe that's the right choice if it means more compact code.

It's not so complicated. if you can make the code smaller with negligible impact on throughput, do so. If not, don't.

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:17 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:17 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <RS_tuxkIudqRFFwLEtUlzYnpSxsueee_Zu5SxAyv4nA=.f26a6f98-3533-4467-937c-261d1106fdb4@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <07z1ueSVi_yO56oR5nT04JKrU_Vui1k7JsgxZrKEnbs=.16a0350b-1f76-4015-9419-035d26a78d82@github.com>
 <BCdk4pS1pfOgOe-i6plw1_EvJ8wLDUZKCCkilcg_xxA=.9cb99ab4-8beb-454d-9555-2b5ae5760673@github.com>
 <RS_tuxkIudqRFFwLEtUlzYnpSxsueee_Zu5SxAyv4nA=.f26a6f98-3533-4467-937c-261d1106fdb4@github.com>
Message-ID: <lsHRgtMSbhVGRklc3tY4BoJ_nNBIgRC-I8e-nT2myeI=.56815ba4-f880-460d-beb9-f9ff6ce302ce@github.com>

On Fri, 16 Sep 2022 09:27:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Interesting, I had not considered that.  Thanks for pointing that out.  I'm honestly not sure how to evaluate the impact of the generated code on the icache.  I'll look at the logic surrounding the ghash processBlocks(_wide) code to see how that decision is made.  I don't have an aversion to going back to an assembly-based loop using the suggestions that @dchuyko made and maybe that's the right choice if it means more compact code.
>
> It's not so complicated. if you can make the code smaller with negligible impact on throughput, do so. If not, don't.

I really didn't see a noticeable impact on performance with the loop unrolled so I'm going with the SUB/CBNZ approach.  Seems like it does the best job of keeping the generated stub smaller and still be a tiny bit more efficient than what I started with.  As always, I appreciate the suggestions.

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

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


From sviswanathan at openjdk.org  Mon Nov  7 07:34:25 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 7 Nov 2022 07:34:25 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <e7YhTmbhucfO2m_KITHD4rcwuqAK1zdA-_V8Q2oAdLk=.3e88980c-1a19-426b-8444-db8697d29f8b@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

src/hotspot/cpu/x86/assembler_x86.cpp line 4994:

> 4992:     assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 4993:             (vector_len == AVX_256bit ? VM_Version::supports_avx2() :
> 4994:             (vector_len == AVX_512bit ? VM_Version::supports_evex() : 0)), "");

VM_Version::supports_evex() here should be VM_Version::supports_avx512bw().

src/hotspot/cpu/x86/assembler_x86.cpp line 4996:

> 4994:             (vector_len == AVX_512bit ? VM_Version::supports_evex() : 0)), "");
> 4995:     NOT_LP64(assert(VM_Version::supports_sse2(), ""));
> 4996:     InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

legacy mode here should be _legacy_mode_bw.

src/hotspot/cpu/x86/assembler_x86.cpp line 5025:

> 5023:     assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 5024:             (vector_len == AVX_256bit ? VM_Version::supports_avx2() :
> 5025:             (vector_len == AVX_512bit ? VM_Version::supports_evex() : 0)), "");

VM_Version::supports_evex() here should be VM_Version::supports_avx512bw().

src/hotspot/cpu/x86/assembler_x86.cpp line 5027:

> 5025:             (vector_len == AVX_512bit ? VM_Version::supports_evex() : 0)), "");
> 5026:     NOT_LP64(assert(VM_Version::supports_sse2(), ""));
> 5027:     InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

legacy_mode here should be _legacy_mode_bw.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5682:

> 5680:   /* Add mask for 4-block ChaCha20 Block calculations */
> 5681:   address chacha20_ctradd_avx512() {
> 5682:     __ align(CodeEntryAlignment);

This could be __ align64();

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5698:

> 5696:   /* Scatter mask for key stream output on AVX-512 */
> 5697:   address chacha20_scmask_avx512() {
> 5698:     __ align(CodeEntryAlignment);

This could be __ align64();

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5728:

> 5726:     const XMMRegister zmm_cVec = xmm2;
> 5727:     const XMMRegister zmm_dVec = xmm3;
> 5728:     const XMMRegister zmm_scratch = xmm4;

We could have 5 additional scratch registers zmm_s1 .. zmm_s5 (mapping to xmm5 ... xmm9)  to keep values read from memory into registers.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5738:

> 5736:     __ evbroadcasti32x4(zmm_bVec, Address(state, 16), Assembler::AVX_512bit);
> 5737:     __ evbroadcasti32x4(zmm_cVec, Address(state, 32), Assembler::AVX_512bit);
> 5738:     __ evbroadcasti32x4(zmm_dVec, Address(state, 48), Assembler::AVX_512bit);

zmm_aVec to zmm_dVec could be copied into zmm_s1 to zmm_s4 respectively thereby eliminating broadcast needed later. For example:
 __ evmovdquq(zmm_s1, zmm_aVec, Assembler::AVX_512bit);

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5740:

> 5738:     __ evbroadcasti32x4(zmm_dVec, Address(state, 48), Assembler::AVX_512bit);
> 5739: 
> 5740:     __ vpaddd(zmm_dVec, zmm_dVec, ExternalAddress(StubRoutines::x86::chacha20_counter_addmask_avx512()), Assembler::AVX_512bit, rax);

The chacha20_counter_addmask_avx512() could be preloaded into zmm_s5 before line 5735 as follows:
 __ evmovdquq(zmm_s5, ExternalAddress(StubRoutines::x86::chacha20_counter_addmask_avx512()), Assembler::AVX_512bit, rax);
vpaddd can then use zmm_s5 also the later usage could use zmm_s5 directly.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5827:

> 5825:     __ evbroadcasti32x4(zmm_scratch, Address(state, 48), Assembler::AVX_512bit);
> 5826:     __ vpaddd(zmm_dVec, zmm_dVec, zmm_scratch, Assembler::AVX_512bit);
> 5827:     __ vpaddd(zmm_dVec, zmm_dVec, ExternalAddress(StubRoutines::x86::chacha20_counter_addmask_avx512()), Assembler::AVX_512bit, rax);

These could directly use the values in zmm_s1 to zmm_s5 registers  :
    __ vpaddd(zmm_aVec, zmm_aVec, zmm_s1, Assembler::AVX_512bit);
    ...
    __ vpaddd(zmm_dVec, zmm_dVec, zmm_s5, Assembler::AVX_512bit);

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5842:

> 5840:     __ evpscatterdd(Address(result, zmm_scratch, Address::times_4, 32), writeMask, zmm_cVec, Assembler::AVX_512bit);
> 5841:     __ knotwl(writeMask, writeMask);
> 5842:     __ evpscatterdd(Address(result, zmm_scratch, Address::times_4, 48), writeMask, zmm_dVec, Assembler::AVX_512bit);

Using the vextracti32x4 instead of evpscatterdd would give better performance:
    __ vextracti32x4(Address(result, 0), zmm_aVec, 0);
    __ vextracti32x4(Address(result, 64), zmm_aVec, 1);
    __ vextracti32x4(Address(result, 128), zmm_aVec, 2);
    __ vextracti32x4(Address(result, 192), zmm_aVec, 3);
    __ vextracti32x4(Address(result, 16), zmm_bVec, 0);
    __ vextracti32x4(Address(result, 80), zmm_bVec, 1);
    __ vextracti32x4(Address(result, 144), zmm_bVec, 2);
    __ vextracti32x4(Address(result, 208), zmm_bVec, 3);
    __ vextracti32x4(Address(result, 32), zmm_cVec, 0);
    __ vextracti32x4(Address(result, 96), zmm_cVec, 1);
    __ vextracti32x4(Address(result, 160), zmm_cVec, 2);
    __ vextracti32x4(Address(result, 224), zmm_cVec, 3);
    __ vextracti32x4(Address(result, 48), zmm_dVec, 0);
    __ vextracti32x4(Address(result, 112), zmm_dVec, 1);
    __ vextracti32x4(Address(result, 176), zmm_dVec, 2);
    __ vextracti32x4(Address(result, 240), zmm_dVec, 3);

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

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


From vlivanov at openjdk.org  Mon Nov  7 07:34:29 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Nov 2022 07:34:29 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <bfvITmE9Ikr80Nagm_5JQuvxK7QoU_sXFGYgnMLfZgQ=.87249f91-ca3f-4529-a1a4-cb642480b0da@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

src/hotspot/cpu/x86/assembler_x86.cpp line 5034:

> 5032:     assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 5033:             (vector_len == AVX_256bit ? VM_Version::supports_avx2() :
> 5034:             (vector_len == AVX_512bit ? VM_Version::supports_avx512bw() : 0)), "");

It's better to use `false` rather than `0`.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5364:

> 5362: 
> 5363:   /* The 2-block AVX/AVX2-enabled ChaCha20 block function implementation */
> 5364:   address generate_chacha20Block_avx() {

Considering you already introduce a dedicated CPP file, it makes sense to move the guts of this function into `macroAssembler_x86_chapoly.cpp`.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1128:

> 1126:   // based on the VM capabilities whether to use an AVX2 or AVX512-enabled
> 1127:   // version.
> 1128:   if ((UseSSE >= 2) && (UseAVX >= 1) ) {

`UseAVX > 1` already implies `UseSSE >=2`.

src/hotspot/share/opto/library_call.cpp line 6913:

> 6911:   Node* cc20Blk = make_runtime_call(RC_LEAF|RC_NO_FP,
> 6912:                                   OptoRuntime::chacha20Block_Type(),
> 6913:                                   stubAddr, stubName, TypePtr::BOTTOM,

BTW it can be further improved: the stub reads from `int[]` and writes into `byte[]` while `TypePtr::BOTTOM` signals both in and out memory state is wide. `GraphKit::make_runtime_call()` doesn't support it yet, but if you pass input and output address types separately, it should be possible to turn both into narrow memory and represent the runtime call accordingly (see `wide_in`/`wide_out`-related code in `GraphKit::make_runtime_call()`).  Also, it can be done as a follow-up enhancement later.

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:32 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:32 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <5vHrtG9EzPVw4Rzda3-H85Upr1jANl472BED7D38Vw4=.38e54240-afe5-449b-b357-adfe99ed3839@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <e7YhTmbhucfO2m_KITHD4rcwuqAK1zdA-_V8Q2oAdLk=.3e88980c-1a19-426b-8444-db8697d29f8b@github.com>
 <5vHrtG9EzPVw4Rzda3-H85Upr1jANl472BED7D38Vw4=.38e54240-afe5-449b-b357-adfe99ed3839@github.com>
Message-ID: <DDY2X4rX-b_RTtqS5u6wlY2uGWahm8WKTZdLc6s4i7o=.1368a123-0468-4fb1-95e3-718cc47caffc@github.com>

On Tue, 22 Mar 2022 23:07:30 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5842:
>> 
>>> 5840:     __ evpscatterdd(Address(result, zmm_scratch, Address::times_4, 32), writeMask, zmm_cVec, Assembler::AVX_512bit);
>>> 5841:     __ knotwl(writeMask, writeMask);
>>> 5842:     __ evpscatterdd(Address(result, zmm_scratch, Address::times_4, 48), writeMask, zmm_dVec, Assembler::AVX_512bit);
>> 
>> Using the vextracti32x4 instead of evpscatterdd would give better performance:
>>     __ vextracti32x4(Address(result, 0), zmm_aVec, 0);
>>     __ vextracti32x4(Address(result, 64), zmm_aVec, 1);
>>     __ vextracti32x4(Address(result, 128), zmm_aVec, 2);
>>     __ vextracti32x4(Address(result, 192), zmm_aVec, 3);
>>     __ vextracti32x4(Address(result, 16), zmm_bVec, 0);
>>     __ vextracti32x4(Address(result, 80), zmm_bVec, 1);
>>     __ vextracti32x4(Address(result, 144), zmm_bVec, 2);
>>     __ vextracti32x4(Address(result, 208), zmm_bVec, 3);
>>     __ vextracti32x4(Address(result, 32), zmm_cVec, 0);
>>     __ vextracti32x4(Address(result, 96), zmm_cVec, 1);
>>     __ vextracti32x4(Address(result, 160), zmm_cVec, 2);
>>     __ vextracti32x4(Address(result, 224), zmm_cVec, 3);
>>     __ vextracti32x4(Address(result, 48), zmm_dVec, 0);
>>     __ vextracti32x4(Address(result, 112), zmm_dVec, 1);
>>     __ vextracti32x4(Address(result, 176), zmm_dVec, 2);
>>     __ vextracti32x4(Address(result, 240), zmm_dVec, 3);
>
> I have been wondering about this approach for a while now, since I did something similar for the AVX2 version.  I had assumed that using evpscatterdd used less instructions and therefore would be more efficient, but I'm more than happy to move to the vextracti32x4 approach.  I'll be eager to see how it impacts performance along with the increased storage of intermediate data on additional XMMRegister objects.

The changes you recommended yielded about a 10-15% performance improvement on the system I was using for benchmarks.  Thanks for the suggestions!

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:26 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:26 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <e7YhTmbhucfO2m_KITHD4rcwuqAK1zdA-_V8Q2oAdLk=.3e88980c-1a19-426b-8444-db8697d29f8b@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <e7YhTmbhucfO2m_KITHD4rcwuqAK1zdA-_V8Q2oAdLk=.3e88980c-1a19-426b-8444-db8697d29f8b@github.com>
Message-ID: <5vHrtG9EzPVw4Rzda3-H85Upr1jANl472BED7D38Vw4=.38e54240-afe5-449b-b357-adfe99ed3839@github.com>

On Wed, 16 Mar 2022 00:48:17 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
>> 
>> - x86_64: AVX, AVX2 and AVX512
>> - aarch64: platforms that support the advanced SIMD instructions
>> 
>> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
>> 
>> x86_64
>> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
>> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
>> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=1)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=2)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=3)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
>> 
>> aarch64
>> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>>   part : 0xd0c, revision : 1
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
>> 
>> Intrinsics enabled
>> ------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
>> 
>> Special thanks to the folks who have made many helpful comments while this PR was in draft form.
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 5027:
> 
>> 5025:             (vector_len == AVX_512bit ? VM_Version::supports_evex() : 0)), "");
>> 5026:     NOT_LP64(assert(VM_Version::supports_sse2(), ""));
>> 5027:     InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);
> 
> legacy_mode here should be _legacy_mode_bw.

Good catch, fixed, along with all the other similar findings below.

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5682:
> 
>> 5680:   /* Add mask for 4-block ChaCha20 Block calculations */
>> 5681:   address chacha20_ctradd_avx512() {
>> 5682:     __ align(CodeEntryAlignment);
> 
> This could be __ align64();

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5698:
> 
>> 5696:   /* Scatter mask for key stream output on AVX-512 */
>> 5697:   address chacha20_scmask_avx512() {
>> 5698:     __ align(CodeEntryAlignment);
> 
> This could be __ align64();

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5728:
> 
>> 5726:     const XMMRegister zmm_cVec = xmm2;
>> 5727:     const XMMRegister zmm_dVec = xmm3;
>> 5728:     const XMMRegister zmm_scratch = xmm4;
> 
> We could have 5 additional scratch registers zmm_s1 .. zmm_s5 (mapping to xmm5 ... xmm9)  to keep values read from memory into registers.

For AVX-512 I was able to get it to work with 4 scratch registers fortunately.  For AVX and AVX2 I think the same approach can work, but since there are no lanewise bit rotation instructions (just L/R shifts) that I can find I need a 5th scratch register.

For the 32-bit version it is a little more complicated as there are only 8 SIMD registers to work with.  I think even there I could simply read the state from memory for one memory-to-register add instead of doing 4, and then hold the other 128-bit state lines on 3 scratch registers.  I'm going to experiment with that a bit to see how much I can limit memory fetches to get some improvements on both 64-bit and 32-bit.

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5738:
> 
>> 5736:     __ evbroadcasti32x4(zmm_bVec, Address(state, 16), Assembler::AVX_512bit);
>> 5737:     __ evbroadcasti32x4(zmm_cVec, Address(state, 32), Assembler::AVX_512bit);
>> 5738:     __ evbroadcasti32x4(zmm_dVec, Address(state, 48), Assembler::AVX_512bit);
> 
> zmm_aVec to zmm_dVec could be copied into zmm_s1 to zmm_s4 respectively thereby eliminating broadcast needed later. For example:
>  __ evmovdquq(zmm_s1, zmm_aVec, Assembler::AVX_512bit);

A good suggestion, this has been changed.

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5740:
> 
>> 5738:     __ evbroadcasti32x4(zmm_dVec, Address(state, 48), Assembler::AVX_512bit);
>> 5739: 
>> 5740:     __ vpaddd(zmm_dVec, zmm_dVec, ExternalAddress(StubRoutines::x86::chacha20_counter_addmask_avx512()), Assembler::AVX_512bit, rax);
> 
> The chacha20_counter_addmask_avx512() could be preloaded into zmm_s5 before line 5735 as follows:
>  __ evmovdquq(zmm_s5, ExternalAddress(StubRoutines::x86::chacha20_counter_addmask_avx512()), Assembler::AVX_512bit, rax);
> vpaddd can then use zmm_s5 also the later usage could use zmm_s5 directly.

Another good improvement, done.

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5827:
> 
>> 5825:     __ evbroadcasti32x4(zmm_scratch, Address(state, 48), Assembler::AVX_512bit);
>> 5826:     __ vpaddd(zmm_dVec, zmm_dVec, zmm_scratch, Assembler::AVX_512bit);
>> 5827:     __ vpaddd(zmm_dVec, zmm_dVec, ExternalAddress(StubRoutines::x86::chacha20_counter_addmask_avx512()), Assembler::AVX_512bit, rax);
> 
> These could directly use the values in zmm_s1 to zmm_s5 registers  :
>     __ vpaddd(zmm_aVec, zmm_aVec, zmm_s1, Assembler::AVX_512bit);
>     ...
>     __ vpaddd(zmm_dVec, zmm_dVec, zmm_s5, Assembler::AVX_512bit);

Keeping the original broadcasted state data on registers was a good idea, as it saved me the extra reach out to memory at the end of the loop.  Fixed as recommended.

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5842:
> 
>> 5840:     __ evpscatterdd(Address(result, zmm_scratch, Address::times_4, 32), writeMask, zmm_cVec, Assembler::AVX_512bit);
>> 5841:     __ knotwl(writeMask, writeMask);
>> 5842:     __ evpscatterdd(Address(result, zmm_scratch, Address::times_4, 48), writeMask, zmm_dVec, Assembler::AVX_512bit);
> 
> Using the vextracti32x4 instead of evpscatterdd would give better performance:
>     __ vextracti32x4(Address(result, 0), zmm_aVec, 0);
>     __ vextracti32x4(Address(result, 64), zmm_aVec, 1);
>     __ vextracti32x4(Address(result, 128), zmm_aVec, 2);
>     __ vextracti32x4(Address(result, 192), zmm_aVec, 3);
>     __ vextracti32x4(Address(result, 16), zmm_bVec, 0);
>     __ vextracti32x4(Address(result, 80), zmm_bVec, 1);
>     __ vextracti32x4(Address(result, 144), zmm_bVec, 2);
>     __ vextracti32x4(Address(result, 208), zmm_bVec, 3);
>     __ vextracti32x4(Address(result, 32), zmm_cVec, 0);
>     __ vextracti32x4(Address(result, 96), zmm_cVec, 1);
>     __ vextracti32x4(Address(result, 160), zmm_cVec, 2);
>     __ vextracti32x4(Address(result, 224), zmm_cVec, 3);
>     __ vextracti32x4(Address(result, 48), zmm_dVec, 0);
>     __ vextracti32x4(Address(result, 112), zmm_dVec, 1);
>     __ vextracti32x4(Address(result, 176), zmm_dVec, 2);
>     __ vextracti32x4(Address(result, 240), zmm_dVec, 3);

I have been wondering about this approach for a while now, since I did something similar for the AVX2 version.  I had assumed that using evpscatterdd used less instructions and therefore would be more efficient, but I'm more than happy to move to the vextracti32x4 approach.  I'll be eager to see how it impacts performance along with the increased storage of intermediate data on additional XMMRegister objects.

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

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


From jnimeh at openjdk.org  Mon Nov  7 07:34:31 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 07:34:31 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <bfvITmE9Ikr80Nagm_5JQuvxK7QoU_sXFGYgnMLfZgQ=.87249f91-ca3f-4529-a1a4-cb642480b0da@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <bfvITmE9Ikr80Nagm_5JQuvxK7QoU_sXFGYgnMLfZgQ=.87249f91-ca3f-4529-a1a4-cb642480b0da@github.com>
Message-ID: <LEzZ_esHmVlGl4snVbW1fuNuYshGI6opyJeQG4157RM=.2e6abf99-d02f-4462-9eff-f281d0c98ce7@github.com>

On Mon, 6 Jun 2022 20:57:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
>> 
>> - x86_64: AVX, AVX2 and AVX512
>> - aarch64: platforms that support the advanced SIMD instructions
>> 
>> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
>> 
>> x86_64
>> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
>> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
>> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=1)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=2)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
>> 
>> Intrinsics enabled (-XX:UseAVX=3)
>> ---------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
>> 
>> aarch64
>> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>>   part : 0xd0c, revision : 1
>> 
>> Java only (-XX:-UseChaCha20Intrinsics)
>> --------------------------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
>> 
>> Intrinsics enabled
>> ------------------
>> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
>> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
>> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
>> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
>> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
>> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
>> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
>> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
>> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
>> 
>> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
>> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
>> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
>> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
>> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
>> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
>> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
>> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
>> 
>> Special thanks to the folks who have made many helpful comments while this PR was in draft form.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5364:
> 
>> 5362: 
>> 5363:   /* The 2-block AVX/AVX2-enabled ChaCha20 block function implementation */
>> 5364:   address generate_chacha20Block_avx() {
> 
> Considering you already introduce a dedicated CPP file, it makes sense to move the guts of this function into `macroAssembler_x86_chapoly.cpp`.

I've updated the code to follow your example with AES and moved the intrinsics into their own stubGenerator_x86_64_chapoly.cpp.  I hope that will compartmentalize things.  I'm not sure if I should combine the macroAssembler_x86_64_chapoly.cpp with the new stubGenerator file.  Certainly willing to do that, but I wanted to get the dedicated stubGenerator file working first since the last merge was ugly.  Going forward merges should be much easier now that my code is compartmentalized.

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

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


From mbaesken at openjdk.org  Mon Nov  7 07:54:31 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 7 Nov 2022 07:54:31 GMT
Subject: Integrated: JDK-8296226: Add constructors (String,Throwable) and
 (Throwable) to InvalidParameterException
In-Reply-To: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
References: <Dm4jJLsPDvs5qWKEIg1l_XLOCDH0AZ9JD0Ese-aPUDE=.5bfdf16e-e1e2-4d42-bb33-de575e1a19be@github.com>
Message-ID: <UnFGGT1kEVBGY8YF-KJmsomUfpCRn0iHrVyR-VDtUok=.b253d00c-e58a-42ea-be3f-e58980f2722d@github.com>

On Thu, 3 Nov 2022 09:07:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This change adds constructors (String,Throwable) and (Throwable) to InvalidParameterException and uses them at a few places in the jdk coding.

This pull request has now been integrated.

Changeset: 8836b925
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8836b92593565e66d8063b1228d6701316f3078d
Stats:     63 lines in 8 files changed: 50 ins; 3 del; 10 mod

8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException

Reviewed-by: mullan, mdoerr

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

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


From djelinski at openjdk.org  Mon Nov  7 08:08:25 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 7 Nov 2022 08:08:25 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <QhaLrjytvPfClkXYMhnAArELqVrbivgiKKgCqGeu0Ug=.54ca5059-ed0f-4f12-a41b-81836497f683@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

Is it expected that AVX3 is 35% slower than AVX2 and 8% slower than AVX1?

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

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


From jnimeh at openjdk.org  Mon Nov  7 08:54:08 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 7 Nov 2022 08:54:08 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <QhaLrjytvPfClkXYMhnAArELqVrbivgiKKgCqGeu0Ug=.54ca5059-ed0f-4f12-a41b-81836497f683@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <QhaLrjytvPfClkXYMhnAArELqVrbivgiKKgCqGeu0Ug=.54ca5059-ed0f-4f12-a41b-81836497f683@github.com>
Message-ID: <ph6Wa6IO7lLcbTyi1yI3ZYsZejpWY7cNy1pzkMBh0Yo=.b0674112-5547-468a-ab53-262be342ee24@github.com>

On Mon, 7 Nov 2022 08:04:15 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Is it expected that AVX3 is 35% slower than AVX2 and 8% slower than AVX1?

Well, it isn't slower than AVX/AVX2 across the board.  For plain ChaCha20 it is slower for this particular benchmark at 256 bytes (and smaller I would assume), but that changes at data sizes above 256 bytes.  I haven't worked out the timings exactly, but this is what I think is happening:
The AVX512 intrinsic broadcasts into the registers from memory using twice as many registers and at twice the size over AVX2, and likewise writes 4x the amount of data into the keystream buffer upon completion.  I'm not certain by how much, but I believe the runtime of the AVX512 intrinsic is longer than that of the AVX/AVX2 intrinsic.  When the job size is 256 bytes, both AVX2 and AVX512 will run their intrinsics one time and that may account for the speed difference.  And for AVX at 256 bytes the intrinsic has to run twice (which is why the slowdown is less).  When you get to 1024 bytes, AVX has to run 8 times to make enough key stream, AVX2 has to run 4 times, but AVX512 still only has to run once.  So now AVX512 outperforms the other two, and continues that way for any larger single-part encryption job this benchmark is doing.  I haven't tried running other sizes yet to see where that cross-over point is, but I suspect it is probably once a job gets above 512 bytes.

This particular benchmark is a single-part encryption or decryption.  The performance characteristics look different when you are taking a large buffer and submitting multi-part updates.  In that case 16 byte updates has AVX512 and AVX2 nearly identical (AVX2 is 2% faster, AVX is already 23% slower), at 64 bytes AVX512 is faster than everything and the gap widens as the update sizes grow.

To be fair, I think the single-part jobs are more representative of what we would see in JSSE, but TLS application data job sizes are probably all over the map depending on what is being sent.

ChaCha20-Poly1305 - There AVX512 is slower than AVX2 across the board, and I am not sure why even at larger sizes the throughput gains we see in ChaCha20 are not seen here.  There's a lot more work being done outside the cc20 intrinsic, especially without the pending AVX512 poly1305 intrinsic, but I would've expected to see a crossover point at one of those benchmark sizes.

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

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


From mbaesken at openjdk.org  Mon Nov  7 12:57:43 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 7 Nov 2022 12:57:43 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
Message-ID: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>

The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.

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

Commit messages:
 - JDK-8296406

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

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


From mullan at openjdk.org  Mon Nov  7 14:11:34 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 7 Nov 2022 14:11:34 GMT
Subject: Integrated: 8279164: Disable TLS_ECDH_* cipher suites
In-Reply-To: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
References: <wdgwgRMeVYgd4ctaf9roySNXUOZytSZ0GiIsxCvQpsk=.bcc44f79-1cfd-4f5c-a59b-cecfed3ef667@github.com>
Message-ID: <tBkWmovFm3hYuesA_kX_4j2DTY3DCyZaxoGYq2vNn3U=.d3bd7f60-efbe-4cc8-9042-e0ff4fcea1a9@github.com>

On Thu, 3 Nov 2022 14:59:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change will disable TLS_ECDH_* cipher suites by default. These cipher suites do not preserve forward secrecy and are rarely used in practice. See the CSR for more details and rationale.
> 
> Users will still be able to enable the suites (at their own risk) by removing "ECDH" from the `jdk.tls.disabledAlgorithms` security property.

This pull request has now been integrated.

Changeset: 00d22f60
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00d22f605d2b54f2774aeaa1edfbb146a5635f21
Stats:     108 lines in 4 files changed: 14 ins; 63 del; 31 mod

8279164: Disable TLS_ECDH_* cipher suites

Reviewed-by: xuelei, rhalade, wetmore

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

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


From djelinski1 at gmail.com  Mon Nov  7 14:21:24 2022
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Mon, 7 Nov 2022 15:21:24 +0100
Subject: TLS1.3 record padding
In-Reply-To: <7f745633-4aec-5906-0223-735ce2d76b42@oracle.com>
References: <CAMrH03KY5E6deE6+Fxqv_aXyg1HWObkCc=7g-tHDJmyczxjGLQ@mail.gmail.com>
 <EA5188D2-5B6B-4BE3-AD2D-68CA3BC16D34@gmail.com>
 <7f745633-4aec-5906-0223-735ce2d76b42@oracle.com>
Message-ID: <CAMrH03+jn-hVTvj7Q8GrB=iDOYFp-7UDPFU8w9b-NUDDFMT_Sw@mail.gmail.com>

Thanks Xuelei and Brad for your replies!

https://bugs.openjdk.org/browse/JDK-8244983 mentions that random padding
could be used to mitigate BREACH attack. I googled for "breach random
padding", found 3 similar requests [1] [2] [3] for enhancements, none of
them was implemented. Also https://www.breachattack.com/ does not list TLS
record padding as a means to mitigate the attack, presumably because even
with random padding the response length will be eventually revealed if the
request can be repeated.

What kind of padding length customization would you like to see in the JDK?

Daniel

[1] https://www.drupal.org/project/seckit/issues/2737783
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=64434
[3] https://trac.nginx.org/nginx/ticket/1977


sob., 5 lis 2022 o 04:01 Bradford Wetmore <bradford.wetmore at oracle.com>
napisa?(a):

>
>
> On 11/4/2022 8:58 AM, Xuelei Fan wrote:
> > The padding may be also necessary to prevent from a kind of attacks,
> > besides hiding the length.  But I cannot recall the details.
>
> I have a vague recollection of that, but I was thinking it was something
> pre-1.3.  But I'm not seeing any special padding in the pre-TLSv1.3
> changeset:
>
> c7c819cd8bba9f204f23b24a0d788fda61823eb3
>
> so I may be off in my recollections.
>
> >  Here is an enhancement
> > request in JBS (https://bugs.openjdk.org/browse/JDK-8244983
> > <https://bugs.openjdk.org/browse/JDK-8244983>), please feel free to
> take
> > it.
>
> Ah yes.
>
> Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221107/f5beb0b3/attachment.htm>

From mpowers at openjdk.org  Mon Nov  7 16:02:25 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 7 Nov 2022 16:02:25 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
Message-ID: <O-gmBArcNIDmxVrSb71RPjKbkl_fOxco6JKjHe7-Ga0=.a201171b-6d48-40a8-8c4f-c76bc8b5548b@github.com>

On Mon, 7 Nov 2022 12:49:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.

LGTM

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

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


From xuelei.f at gmail.com  Mon Nov  7 16:22:09 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Mon, 7 Nov 2022 08:22:09 -0800
Subject: TLS1.3 record padding
In-Reply-To: <CAMrH03+jn-hVTvj7Q8GrB=iDOYFp-7UDPFU8w9b-NUDDFMT_Sw@mail.gmail.com>
References: <CAMrH03KY5E6deE6+Fxqv_aXyg1HWObkCc=7g-tHDJmyczxjGLQ@mail.gmail.com>
 <EA5188D2-5B6B-4BE3-AD2D-68CA3BC16D34@gmail.com>
 <7f745633-4aec-5906-0223-735ce2d76b42@oracle.com>
 <CAMrH03+jn-hVTvj7Q8GrB=iDOYFp-7UDPFU8w9b-NUDDFMT_Sw@mail.gmail.com>
Message-ID: <12BC6B06-B05A-4901-A9B6-B7C970111005@gmail.com>

> What kind of padding length customization would you like to see in the JDK?


I may be hesitate to add a new API.  A default random padding could be used instead, and might be controlled with a system property (e.g, ?jdk.tls.client/server.maxRecordPadding? or ?jdk.tls.client/server.recordPaddingRange?).  If random padding is enable, the padding adding/removing should be constant-time.

Xuelei 


> On Nov 7, 2022, at 6:21 AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
> 
> Thanks Xuelei and Brad for your replies!
> 
> https://bugs.openjdk.org/browse/JDK-8244983 <https://bugs.openjdk.org/browse/JDK-8244983> mentions that random padding could be used to mitigate BREACH attack. I googled for "breach random padding", found 3 similar requests [1] [2] [3] for enhancements, none of them was implemented. Also https://www.breachattack.com/ <https://www.breachattack.com/> does not list TLS record padding as a means to mitigate the attack, presumably because even with random padding the response length will be eventually revealed if the request can be repeated.
> 
> What kind of padding length customization would you like to see in the JDK?
> 
> Daniel
> 
> [1] https://www.drupal.org/project/seckit/issues/2737783 <https://www.drupal.org/project/seckit/issues/2737783>
> [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=64434 <https://bz.apache.org/bugzilla/show_bug.cgi?id=64434>
> [3] https://trac.nginx.org/nginx/ticket/1977 <https://trac.nginx.org/nginx/ticket/1977>
> 
> 
> sob., 5 lis 2022 o 04:01 Bradford Wetmore <bradford.wetmore at oracle.com <mailto:bradford.wetmore at oracle.com>> napisa?(a):
> 
> 
> On 11/4/2022 8:58 AM, Xuelei Fan wrote:
> > The padding may be also necessary to prevent from a kind of attacks, 
> > besides hiding the length.  But I cannot recall the details.
> 
> I have a vague recollection of that, but I was thinking it was something 
> pre-1.3.  But I'm not seeing any special padding in the pre-TLSv1.3 
> changeset:
> 
> c7c819cd8bba9f204f23b24a0d788fda61823eb3
> 
> so I may be off in my recollections.
> 
> >  Here is an enhancement 
> > request in JBS (https://bugs.openjdk.org/browse/JDK-8244983 <https://bugs.openjdk.org/browse/JDK-8244983> 
> > <https://bugs.openjdk.org/browse/JDK-8244983 <https://bugs.openjdk.org/browse/JDK-8244983>>), please feel free to take 
> > it.
> 
> Ah yes.
> 
> Brad
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221107/dbaa33f2/attachment.htm>

From ckozak at ckozak.net  Mon Nov  7 16:26:04 2022
From: ckozak at ckozak.net (Carter Kozak)
Date: Mon, 07 Nov 2022 11:26:04 -0500
Subject: TLS Performance Regression in JDK18+
In-Reply-To: <afc89329-44ee-46b3-866b-75024915a858@app.fastmail.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
 <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
 <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>
 <ccba6d8a-b197-20d5-0622-47c57069c89f@oracle.com>
 <afc89329-44ee-46b3-866b-75024915a858@app.fastmail.com>
Message-ID: <7159986b-8607-4ea7-9f5e-d2ef73218396@app.fastmail.com>

Following up, were you able to run the benchmark across openjdk releases? If so, can you confirm whether your observations matched my own? I really appreciate your help looking into this!

Thanks,
Carter Kozak


From aturbanov at openjdk.org  Mon Nov  7 16:48:54 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 7 Nov 2022 16:48:54 GMT
Subject: Integrated: 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: <k-11g8N4Kd5vqVmgOvznJBWjjp6GJmvkMk26FD6K9lc=.bc077b9c-fbe4-4fb2-b208-f2fa6d967b53@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.

This pull request has now been integrated.

Changeset: 3baad069
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3baad069a65a0ac138a6aaabf451758672d12fbc
Stats:     32 lines in 6 files changed: 0 ins; 18 del; 14 mod

8295953: Use enhanced-for cycle instead of Enumeration in sun.security

Reviewed-by: weijun

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

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


From anthony.scarpino at oracle.com  Mon Nov  7 16:57:45 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 7 Nov 2022 08:57:45 -0800
Subject: TLS Performance Regression in JDK18+
In-Reply-To: <7159986b-8607-4ea7-9f5e-d2ef73218396@app.fastmail.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
 <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
 <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>
 <ccba6d8a-b197-20d5-0622-47c57069c89f@oracle.com>
 <afc89329-44ee-46b3-866b-75024915a858@app.fastmail.com>
 <7159986b-8607-4ea7-9f5e-d2ef73218396@app.fastmail.com>
Message-ID: <cd0d9056-9a44-7e98-7e2b-4bf8b9190475@oracle.com>

On 11/7/22 8:26 AM, Carter Kozak wrote:
> Following up, were you able to run the benchmark across openjdk releases? If so, can you confirm whether your observations matched my own? I really appreciate your help looking into this!
> 
> Thanks,
> Carter Kozak

Yes, I was able to reproduce this.  The memory usage is related to a 
necessary java change for the AVX512 intrinsic.  It doesn't show up much 
in the crypto performance tests, but TLS triggers it more often, driving 
up the memory usage even though the performance is only slightly affected.

I have to see if I can change the code path without hurting the 
decryption performance gains from the AVX512 intrinsic.

Tony


From rhalade at openjdk.org  Mon Nov  7 17:18:32 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 7 Nov 2022 17:18:32 GMT
Subject: RFR: 8245654: Add Certigna Root CA [v4]
In-Reply-To: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
References: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
Message-ID: <tFOsutP1i4FnMVuxKJ7Et3qtYeTRxNBDYgV0BNtY-xY=.3201d9cf-c7bc-4987-a2cf-05b9816d56bf@github.com>

> This fix adds Certigna root CA to cacerts trust store.

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  int cert doesn't specify OCSP

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10030/files
  - new: https://git.openjdk.org/jdk/pull/10030/files/caa4e356..1546ff05

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

  Stats: 16 lines in 1 file changed: 11 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10030.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10030/head:pull/10030

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


From ckozak at ckozak.net  Mon Nov  7 17:50:41 2022
From: ckozak at ckozak.net (Carter Kozak)
Date: Mon, 07 Nov 2022 12:50:41 -0500
Subject: TLS Performance Regression in JDK18+
In-Reply-To: <cd0d9056-9a44-7e98-7e2b-4bf8b9190475@oracle.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
 <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
 <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>
 <ccba6d8a-b197-20d5-0622-47c57069c89f@oracle.com>
 <afc89329-44ee-46b3-866b-75024915a858@app.fastmail.com>
 <7159986b-8607-4ea7-9f5e-d2ef73218396@app.fastmail.com>
 <cd0d9056-9a44-7e98-7e2b-4bf8b9190475@oracle.com>
Message-ID: <533db22a-b9cd-4fcd-a45d-c399f4af513d@app.fastmail.com>

On Mon, Nov 7, 2022, at 11:57, Anthony Scarpino wrote:
> Yes, I was able to reproduce this.

Glad to hear it.

> The memory usage is related to a 
> necessary java change for the AVX512 intrinsic.  It doesn't show up much 
> in the crypto performance tests, but TLS triggers it more often, driving 
> up the memory usage even though the performance is only slightly affected.

In my synthetic benchmark, TLS_AES_128_GCM_SHA256 average time increased from 90ms/op to 160ms/op, a 78% regression. TLS_AES_128_GCM_SHA256 increased from 100ms/opt o 170ms/op, a 70% regression. I don't think this is an entirely accurate of standard TLS usage (especially because connections aren't reused) but I do believe the regression in practice is greater than 10%. I don't have much data from jdk19 in production, but historically, heavy allocations have impacted latency (or resource utilization depending on the GC) across an application, especially one that's already allocating heavily.

> I have to see if I can change the code path without hurting the 
> decryption performance gains from the AVX512 intrinsic.

That would be fantastic, thank you!

Thanks,
Carter Kozak


From rhalade at openjdk.org  Mon Nov  7 17:51:06 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 7 Nov 2022 17:51:06 GMT
Subject: RFR: 8296480: java/security/cert/pkix/policyChanges/TestPolicy.java is
 failing
Message-ID: <n1Rlo7re4bihNjnpLVKXa9EFFmlc1eSakuKjFRBgDNg=.74746021-bb1f-4880-94a2-968f94217587@github.com>

Test is updated to set validation date inside PKIXParameters to June 01, 2022.

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

Commit messages:
 - 8296480: java/security/cert/pkix/policyChanges/TestPolicy.java is failing

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

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


From xuelei at openjdk.org  Mon Nov  7 17:57:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 7 Nov 2022 17:57:30 GMT
Subject: RFR: 8296480:
 java/security/cert/pkix/policyChanges/TestPolicy.java is failing
In-Reply-To: <n1Rlo7re4bihNjnpLVKXa9EFFmlc1eSakuKjFRBgDNg=.74746021-bb1f-4880-94a2-968f94217587@github.com>
References: <n1Rlo7re4bihNjnpLVKXa9EFFmlc1eSakuKjFRBgDNg=.74746021-bb1f-4880-94a2-968f94217587@github.com>
Message-ID: <m-VORW5OIRZeDRlIXrGdaqGD9y7MRRLFzL40XfuyWJQ=.b7782501-2a2c-4fae-888c-081022c65f1e@github.com>

On Mon, 7 Nov 2022 17:43:42 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Test is updated to set validation date inside PKIXParameters to June 01, 2022.

Looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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


From rhalade at openjdk.org  Mon Nov  7 17:59:36 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 7 Nov 2022 17:59:36 GMT
Subject: RFR: 8245654: Add Certigna Root CA [v4]
In-Reply-To: <tFOsutP1i4FnMVuxKJ7Et3qtYeTRxNBDYgV0BNtY-xY=.3201d9cf-c7bc-4987-a2cf-05b9816d56bf@github.com>
References: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
 <tFOsutP1i4FnMVuxKJ7Et3qtYeTRxNBDYgV0BNtY-xY=.3201d9cf-c7bc-4987-a2cf-05b9816d56bf@github.com>
Message-ID: <bhRiVF8KDSAOBkwBuDdq2JEx__Py3dK4cd8Gkr1tdsM=.4b8050df-284c-42d7-a5c1-5e9d23948cf5@github.com>

On Mon, 7 Nov 2022 17:18:32 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> This fix adds Certigna root CA to cacerts trust store.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   int cert doesn't specify OCSP

I am closing this pull request as we still don't have OCA signed from CA.

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

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


From rhalade at openjdk.org  Mon Nov  7 17:59:37 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 7 Nov 2022 17:59:37 GMT
Subject: Withdrawn: 8245654: Add Certigna Root CA
In-Reply-To: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
References: <xQBD_s9MZX22Y96EFnhtrTqGAiw5a4AaIR9fdIw4mq8=.22d9cd87-0dc4-4a6e-8505-9921089791b2@github.com>
Message-ID: <r6T6Y9r5ElVuSD21W7ytStWqDE1v3AcqS-v9YAYeCyc=.432e0115-17ae-4e6e-bd1b-dbd7ad1a7a29@github.com>

On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix adds Certigna root CA to cacerts trust store.

This pull request has been closed without being integrated.

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

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


From vlivanov at openjdk.org  Mon Nov  7 18:06:41 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Nov 2022 18:06:41 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <ZUxveAxaS5YNw-Dt6LtOKkPe9Sya2c59PaBObFKKTIw=.f66f0a2c-c2c3-4382-96b6-cf1f47172349@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 989:

> 987:                  bool multi_block);
> 988: 
> 989:   // ChaCha20-Poly1305 macroAssembler defs

These methods can also be moved to `stubGenerator_x86_64.hpp`/`stubGenerator_x86_64_chacha.cpp`. There are no other usages besides x86-64-specific CC20 stub.

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

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


From vlivanov at openjdk.org  Mon Nov  7 18:11:40 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Nov 2022 18:11:40 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <hcljJAg4vgyddG_TnF-Eb0_Va1-B7DoG1Wu9VkipsQI=.3a053e67-03e5-4fa3-a81f-71ab3be4e2ef@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

A note on code formatting: [HotSpot coding style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md)  mentions "Indentation levels are two columns", but some portions of the newly added code use 4 column indentation.

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

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


From mullan at openjdk.org  Mon Nov  7 18:16:49 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 7 Nov 2022 18:16:49 GMT
Subject: RFR: 8296480:
 java/security/cert/pkix/policyChanges/TestPolicy.java is failing
In-Reply-To: <n1Rlo7re4bihNjnpLVKXa9EFFmlc1eSakuKjFRBgDNg=.74746021-bb1f-4880-94a2-968f94217587@github.com>
References: <n1Rlo7re4bihNjnpLVKXa9EFFmlc1eSakuKjFRBgDNg=.74746021-bb1f-4880-94a2-968f94217587@github.com>
Message-ID: <O6on9YUxHao4ELDEzePM1TWX6F_IB-QG3P4BD_clyFg=.e87ae1d9-579c-4174-bbc7-51a2ad3b28ce@github.com>

On Mon, 7 Nov 2022 17:43:42 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Test is updated to set validation date inside PKIXParameters to June 01, 2022.

Marked as reviewed by mullan (Reviewer).

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

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


From anthony.scarpino at oracle.com  Mon Nov  7 18:25:17 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 7 Nov 2022 10:25:17 -0800
Subject: [External] : Re: TLS Performance Regression in JDK18+
In-Reply-To: <533db22a-b9cd-4fcd-a45d-c399f4af513d@app.fastmail.com>
References: <26ccfe28-3aac-4135-bbdb-d3c44326d894@app.fastmail.com>
 <6738c7f5-63c5-f082-dec4-e5ad969622d5@oracle.com>
 <49a817ba-f9d3-b9be-7726-d5eb2e67077d@oracle.com>
 <ccba6d8a-b197-20d5-0622-47c57069c89f@oracle.com>
 <afc89329-44ee-46b3-866b-75024915a858@app.fastmail.com>
 <7159986b-8607-4ea7-9f5e-d2ef73218396@app.fastmail.com>
 <cd0d9056-9a44-7e98-7e2b-4bf8b9190475@oracle.com>
 <533db22a-b9cd-4fcd-a45d-c399f4af513d@app.fastmail.com>
Message-ID: <c7ef6354-80b6-02cb-d5a1-165517aa0160@oracle.com>



On 11/7/22 9:50 AM, Carter Kozak wrote:
> On Mon, Nov 7, 2022, at 11:57, Anthony Scarpino wrote:
>> Yes, I was able to reproduce this.
> 
> Glad to hear it.
> 
>> The memory usage is related to a
>> necessary java change for the AVX512 intrinsic.  It doesn't show up much
>> in the crypto performance tests, but TLS triggers it more often, driving
>> up the memory usage even though the performance is only slightly affected.
> 
> In my synthetic benchmark, TLS_AES_128_GCM_SHA256 average time increased from 90ms/op to 160ms/op, a 78% regression. TLS_AES_128_GCM_SHA256 increased from 100ms/opt o 170ms/op, a 70% regression. I don't think this is an entirely accurate of standard TLS usage (especially because connections aren't reused) but I do believe the regression in practice is greater than 10%. I don't have much data from jdk19 in production, but historically, heavy allocations have impacted latency (or resource utilization depending on the GC) across an application, especially one that's already allocating heavily.

I've seen differences of 77ms/ops vs 90ms/ops between jdk17 & jdk19, so 
not as dramatic as yours, but I think I saw more memory usage than you 
did with other tools.  Benchmarks seldom, if ever, show real world usage.

Using the same jdk releases, I can show AES/GCM output went from 4.8GB/s 
to 6.8GB/sec between 17 and 19, but that is under difference conditions 
than this TLS benchmark.  So everything gets taken in a case by case 
basis and sometimes involve trade offs.

Tony

> 
>> I have to see if I can change the code path without hurting the
>> decryption performance gains from the AVX512 intrinsic.
> 
> That would be fantastic, thank you!
> 
> Thanks,
> Carter Kozak


From xuelei at openjdk.org  Mon Nov  7 18:25:36 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 7 Nov 2022 18:25:36 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v2]
In-Reply-To: <CpFplI9BTIvRwyqb8hNxy3OF0zVbPU0H23w5AsulOhQ=.f37ca9fb-4747-42ff-bad3-e185ffde932e@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <CpFplI9BTIvRwyqb8hNxy3OF0zVbPU0H23w5AsulOhQ=.f37ca9fb-4747-42ff-bad3-e185ffde932e@github.com>
Message-ID: <Ly58sLiOmijwvXATkLsJRifZmzeiZvO9XTbVxmZi89E=.e1588b11-af15-4766-98f1-f7c96c741304@github.com>

On Tue, 9 Aug 2022 15:30:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan 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 three additional commits since the last revision:
> 
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

Anyone has cycle for the review?

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

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


From rhalade at openjdk.org  Mon Nov  7 18:27:17 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 7 Nov 2022 18:27:17 GMT
Subject: Integrated: 8296480:
 java/security/cert/pkix/policyChanges/TestPolicy.java is failing
In-Reply-To: <n1Rlo7re4bihNjnpLVKXa9EFFmlc1eSakuKjFRBgDNg=.74746021-bb1f-4880-94a2-968f94217587@github.com>
References: <n1Rlo7re4bihNjnpLVKXa9EFFmlc1eSakuKjFRBgDNg=.74746021-bb1f-4880-94a2-968f94217587@github.com>
Message-ID: <w8eprCqIVrH5bgxsG2KpnQMr4-fSvvLE3llhfH0IslA=.89d66cc1-d57b-4ff7-bab2-2b1281d31262@github.com>

On Mon, 7 Nov 2022 17:43:42 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Test is updated to set validation date inside PKIXParameters to June 01, 2022.

This pull request has now been integrated.

Changeset: b6ea69c0
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6ea69c06aca7f013e26596cebd039960c5b4d34
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8296480: java/security/cert/pkix/policyChanges/TestPolicy.java is failing

Reviewed-by: xuelei, mullan

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

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


From xuelei at openjdk.org  Mon Nov  7 18:28:26 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 7 Nov 2022 18:28:26 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v4]
In-Reply-To: <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>
Message-ID: <hIiI3o_2DOjwYK3jYRR8yZiKMqm7vogfGImYN8BvpcE=.7be0a0ef-2944-433c-8ec0-2afb29aae716@github.com>

On Thu, 13 Oct 2022 18:15:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> 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/curve25519, [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: No update for Ed448 as using less limbs does not improve the performance for Ed448):
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  1769.262 ?  4.251  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  1764.754 ? 12.185  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  1737.499 ? 43.937  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  1733.932 ?  7.938  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   636.614 ?  6.752  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   629.449 ?  8.000  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   645.898 ?  5.655  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   634.530 ? 11.846  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   334.413 ?  6.710  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   335.088 ?  6.630  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   339.729 ?  1.450  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   327.597 ?  2.341  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1361.028 ?  2.338  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1359.072 ?  3.748  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1347.409 ?  9.172  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1250.794 ? 11.750  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   321.312 ?  5.826  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   326.592 ?  4.213  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   322.183 ?  7.005  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   299.869 ? 16.594  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

Anyone has cycle to have a review?

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

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


From xuelei at openjdk.org  Mon Nov  7 18:48:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 7 Nov 2022 18:48:27 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
Message-ID: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>

> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.org/browse/JDK-8291950
> RFE: https://bugs.openjdk.org/browse/JDK-8281236
> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
> 
> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)

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 four commits:

 - Merge
 - Merge
 - add test cases
 - 8281236: (D)TLS key exchange algorithms

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

Changes: https://git.openjdk.org/jdk/pull/9776/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9776&range=02
  Stats: 893 lines in 16 files changed: 657 ins; 195 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/9776.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9776/head:pull/9776

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


From vlivanov at openjdk.org  Mon Nov  7 18:50:37 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Nov 2022 18:50:37 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <phhl3Y4SAoIsaUUS8zB3DRihsyXboH4E19BGSeyFBGI=.22ab4805-217e-4de4-be8d-8821856885c6@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 870:

> 868:      */
> 869:     @IntrinsicCandidate
> 870:     private static int _chaCha20Block(int[] initState, byte[] result) {

Seems like there are 2 major naming conventions for intrinsic helper methods: prepend "impl" (e.g, `CounterMode.implCrypt`) or append "0" (`GaloisCounterMode.implGCMCrypt0`). I'd prefer to see either one used here.

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

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


From rhalade at openjdk.org  Mon Nov  7 19:00:43 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 7 Nov 2022 19:00:43 GMT
Subject: RFR: 8296485: BuildEEBasicConstraints.java test fails with
 SunCertPathBuilderException
Message-ID: <uQfv3k0bmHdZSZluG6X80nCnZ7oEOM4XInTvdYoqrR0=.b297e971-1498-4c04-bf30-8acf9c5a1a28@github.com>

Test certificates are expired but backdated validation can be performed to fix this issue.

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

Commit messages:
 - 8296485: BuildEEBasicConstraints.java test fails with SunCertPathBuilderException

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

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


From vlivanov at openjdk.org  Mon Nov  7 19:02:42 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Nov 2022 19:02:42 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <i3HEiQ4tE7VHz-GczyoXN2rSnqIY3LZ6GwiKdIQevBg=.f6deb4c7-244a-4467-b7fb-8402d72e62e5@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)
> 
> x86_64
> Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
> ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
> ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
> ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
> ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=1)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
> ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=2)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
> ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s
> 
> Intrinsics enabled (-XX:UseAVX=3)
> ---------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
> ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
> ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
> ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
> ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s
> 
> aarch64
> Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
>   part : 0xd0c, revision : 1
> 
> Java only (-XX:-UseChaCha20Intrinsics)
> --------------------------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
> ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
> ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s
> 
> Intrinsics enabled
> ------------------
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
> ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
> ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
> ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
> ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
> ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s
> 
> ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
> ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
> ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
> ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
> ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
> ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
> ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
> ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

On AVX512 vs AVX1/2 discussion: it makes sense to consider doing runtime dispatching between AVX512 and AVX2 stubs depending on input size. As our previous experience shows (e.g., `AVX3Threshold`), running AVX512 code induces some overhead (varies between microarchitectures) which in some cases defeats the purpose of using AVX512.

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

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


From weijun at openjdk.org  Mon Nov  7 19:11:14 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 7 Nov 2022 19:11:14 GMT
Subject: RFR: 8296485: BuildEEBasicConstraints.java test fails with
 SunCertPathBuilderException
In-Reply-To: <uQfv3k0bmHdZSZluG6X80nCnZ7oEOM4XInTvdYoqrR0=.b297e971-1498-4c04-bf30-8acf9c5a1a28@github.com>
References: <uQfv3k0bmHdZSZluG6X80nCnZ7oEOM4XInTvdYoqrR0=.b297e971-1498-4c04-bf30-8acf9c5a1a28@github.com>
Message-ID: <q1mfpSAMSTlCCxJuUAyjG8r-JejF9wb6wSv8dnCTuic=.5007e523-63c0-4d6d-a2ec-c322d02cf084@github.com>

On Mon, 7 Nov 2022 18:51:52 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Test certificates are expired but backdated validation can be performed to fix this issue.

Marked as reviewed by weijun (Reviewer).

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

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


From rhalade at openjdk.org  Mon Nov  7 19:12:50 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 7 Nov 2022 19:12:50 GMT
Subject: Integrated: 8296485: BuildEEBasicConstraints.java test fails with
 SunCertPathBuilderException
In-Reply-To: <uQfv3k0bmHdZSZluG6X80nCnZ7oEOM4XInTvdYoqrR0=.b297e971-1498-4c04-bf30-8acf9c5a1a28@github.com>
References: <uQfv3k0bmHdZSZluG6X80nCnZ7oEOM4XInTvdYoqrR0=.b297e971-1498-4c04-bf30-8acf9c5a1a28@github.com>
Message-ID: <nX4FIMX5gs_q2bb8bbVKy52bMEaNiYUYaPKQIs-UnP4=.47e46c68-5c56-42c0-8a53-929aaede366b@github.com>

On Mon, 7 Nov 2022 18:51:52 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Test certificates are expired but backdated validation can be performed to fix this issue.

This pull request has now been integrated.

Changeset: 520db1ee
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/520db1eeb18797c782ddfad90467e19bbdd424ac
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8296485: BuildEEBasicConstraints.java test fails with SunCertPathBuilderException

Reviewed-by: weijun

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

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


From mpowers at openjdk.org  Mon Nov  7 23:28:31 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 7 Nov 2022 23:28:31 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
Message-ID: <vhe8NOZgq6P3gA_-9q8fPIFnOPtWjQ16fYV-MH8vHvM=.761e4394-b1c5-4f77-bae7-e099a71e693d@github.com>

On Mon, 7 Nov 2022 18:48:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> 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 four commits:
> 
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

Well crafted. LGTM.

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

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


From jnimeh at openjdk.org  Tue Nov  8 04:07:32 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 8 Nov 2022 04:07:32 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <_YnjdPpV7hzrWhrcM1Y_LG9IM26Nz-LHJWPr5UXPfB4=.03fe38dd-3b72-42ad-9a2b-42fd80fc136a@github.com>

On Fri, 4 Mar 2022 16:47:54 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Note: Microbenchmark results moved to a comment in the PR so we don't have to see it in every email.
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

Microbenchmark results (Note: ChaCha20-Poly1305 numbers do not include the pending Poly1305 intrinsics to be delivered in #10582)

x86_64
Processor: 4x Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz

Java only (-XX:-UseChaCha20Intrinsics)
--------------------------------------
Benchmark                  (dataSize)     Mode  Cnt       Score      Error  Units
ChaCha20.decrypt                  256    thrpt   40  772956.829 ? 4434.965  ops/s
ChaCha20.decrypt                 1024    thrpt   40  230478.075 ?  660.617  ops/s
ChaCha20.decrypt                 4096    thrpt   40   61504.367 ?  187.485  ops/s
ChaCha20.decrypt                16384    thrpt   40   15671.893 ?   59.860  ops/s
ChaCha20.encrypt                  256    thrpt   40  793708.698 ? 3587.562  ops/s
ChaCha20.encrypt                 1024    thrpt   40  232413.842 ?  808.766  ops/s
ChaCha20.encrypt                 4096    thrpt   40   61586.483 ?   94.821  ops/s
ChaCha20.encrypt                16384    thrpt   40   15749.637 ?   34.497  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40  219991.514 ? 2117.364  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40  101672.568 ? 1921.214  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40   32582.073 ?  946.061  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    8485.793 ?   26.348  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40  291605.327 ? 2893.898  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40  121034.948 ? 2545.312  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40   32657.343 ?  114.322  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    8527.834 ?   33.711  ops/s

Intrinsics enabled (-XX:UseAVX=1)
---------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1293211.662 ?  9833.892  ops/s
ChaCha20.decrypt                 1024    thrpt   40   450135.559 ?  1614.303  ops/s
ChaCha20.decrypt                 4096    thrpt   40   123675.797 ?   576.160  ops/s
ChaCha20.decrypt                16384    thrpt   40    31707.566 ?    93.988  ops/s
ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   250683.639 ?  3990.340  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   131000.144 ?  2895.410  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    45215.542 ?  1368.148  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    11879.307 ?    55.006  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   355255.774 ?  5397.267  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   156057.380 ?  4294.091  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    47016.845 ?  1618.779  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    12113.919 ?    45.792  ops/s

Intrinsics enabled (-XX:UseAVX=2)
---------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1824729.604 ? 12130.198  ops/s
ChaCha20.decrypt                 1024    thrpt   40   746024.477 ?  3921.472  ops/s
ChaCha20.decrypt                 4096    thrpt   40   219662.823 ?  2128.901  ops/s
ChaCha20.decrypt                16384    thrpt   40    57198.868 ?   221.973  ops/s
ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   260529.149 ?  4298.662  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   144967.984 ?  4558.697  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    50047.575 ?   171.204  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    13976.999 ?    72.299  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   378971.408 ?  9324.721  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   179361.248 ?  7968.109  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    55727.145 ?  2860.765  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    14205.830 ?    59.411  ops/s

Intrinsics enabled (-XX:UseAVX=3)
---------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1182958.956 ?  7782.532  ops/s
ChaCha20.decrypt                 1024    thrpt   40  1003530.400 ? 10315.996  ops/s
ChaCha20.decrypt                 4096    thrpt   40   339428.341 ?  2376.804  ops/s
ChaCha20.decrypt                16384    thrpt   40    92903.498 ?  1112.425  ops/s
ChaCha20.encrypt                  256    thrpt   40  1266584.736 ?  5101.597  ops/s
ChaCha20.encrypt                 1024    thrpt   40  1059717.173 ?  9435.649  ops/s
ChaCha20.encrypt                 4096    thrpt   40   350520.581 ?  2787.593  ops/s
ChaCha20.encrypt                16384    thrpt   40    95181.548 ?  1638.579  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   200722.479 ?  2045.896  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   124660.386 ?  3869.517  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    44059.327 ?   143.765  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    12412.936 ?    54.845  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   274528.005 ?  2945.416  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   145146.188 ?   857.254  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    47045.637 ?   128.049  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    12643.929 ?    55.748  ops/s

aarch64
Processor: 2 x CPU implementer : 0x41, architecture: 8, variant : 0x3,
  part : 0xd0c, revision : 1

Java only (-XX:-UseChaCha20Intrinsics)
--------------------------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1301037.920 ?  1734.836  ops/s
ChaCha20.decrypt                 1024    thrpt   40   387115.013 ?  1122.264  ops/s
ChaCha20.decrypt                 4096    thrpt   40   102591.108 ?   229.456  ops/s
ChaCha20.decrypt                16384    thrpt   40    25878.583 ?    89.351  ops/s
ChaCha20.encrypt                  256    thrpt   40  1332737.880 ?  2478.508  ops/s
ChaCha20.encrypt                 1024    thrpt   40   390288.663 ?  2361.851  ops/s
ChaCha20.encrypt                 4096    thrpt   40   101882.728 ?   744.907  ops/s
ChaCha20.encrypt                16384    thrpt   40    26001.888 ?    71.907  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   351189.393 ?  2209.148  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   142960.999 ?   361.619  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    42437.822 ?    85.557  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    11173.152 ?    24.969  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   444870.664 ? 12571.799  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   158481.143 ?  2149.208  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    43610.721 ?   282.795  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    11150.783 ?    27.911  ops/s

Intrinsics enabled
------------------
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.decrypt                  256    thrpt   40  1907215.648 ?  3163.767  ops/s
ChaCha20.decrypt                 1024    thrpt   40   631804.007 ?   736.430  ops/s
ChaCha20.decrypt                 4096    thrpt   40   172280.991 ?   362.190  ops/s
ChaCha20.decrypt                16384    thrpt   40    44150.254 ?    98.927  ops/s
ChaCha20.encrypt                  256    thrpt   40  1990050.859 ?  6380.625  ops/s
ChaCha20.encrypt                 1024    thrpt   40   636574.405 ?  3332.471  ops/s
ChaCha20.encrypt                 4096    thrpt   40   173258.615 ?   327.199  ops/s
ChaCha20.encrypt                16384    thrpt   40    44191.925 ?    72.996  ops/s

ChaCha20Poly1305.decrypt          256    thrpt   40   360555.774 ?  1988.467  ops/s
ChaCha20Poly1305.decrypt         1024    thrpt   40   162093.489 ?   413.684  ops/s
ChaCha20Poly1305.decrypt         4096    thrpt   40    50799.888 ?   110.955  ops/s
ChaCha20Poly1305.decrypt        16384    thrpt   40    13560.165 ?    32.208  ops/s
ChaCha20Poly1305.encrypt          256    thrpt   40   458079.724 ? 13746.235  ops/s
ChaCha20Poly1305.encrypt         1024    thrpt   40   188228.966 ?  3498.480  ops/s
ChaCha20Poly1305.encrypt         4096    thrpt   40    52665.733 ?   151.740  ops/s
ChaCha20Poly1305.encrypt        16384    thrpt   40    13606.192 ?    52.134  ops/s

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

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


From jnimeh at openjdk.org  Tue Nov  8 04:11:55 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 8 Nov 2022 04:11:55 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v2]
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <w91UdYDSds4Xa8dFfMwQaMMrjzVpjwS1ZcI8AbHM1JU=.66b990ff-c509-4d22-b426-9be51e1a3606@github.com>

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Note: Microbenchmark results moved to a comment in the PR so we don't have to see it in every email.
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

Jamil Nimeh has updated the pull request incrementally with six additional commits since the last revision:

 - Change intrinsic helper method name conform to convention
 - consolidate chacha macroAssembler routines into chacha stubGenerator file
 - More indentation fixes on aarch64
 - rename chapoly->chacha for macro file
 - rename chacha macro file to be consistent with x86_64 naming
 - Fix indentation issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7702/files
  - new: https://git.openjdk.org/jdk/pull/7702/files/c79abe34..53b432e5

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

  Stats: 826 lines in 9 files changed: 212 ins; 254 del; 360 mod
  Patch: https://git.openjdk.org/jdk/pull/7702.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7702/head:pull/7702

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


From jnimeh at openjdk.org  Tue Nov  8 04:13:30 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 8 Nov 2022 04:13:30 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v2]
In-Reply-To: <ZUxveAxaS5YNw-Dt6LtOKkPe9Sya2c59PaBObFKKTIw=.f66f0a2c-c2c3-4382-96b6-cf1f47172349@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <ZUxveAxaS5YNw-Dt6LtOKkPe9Sya2c59PaBObFKKTIw=.f66f0a2c-c2c3-4382-96b6-cf1f47172349@github.com>
Message-ID: <CUgMRm3tLXJQcxsWn1cwpLVBCKsz_Ad3Qy5xauo0naI=.3715cb24-23dd-47d8-ad89-451cacff6299@github.com>

On Mon, 7 Nov 2022 18:02:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Change intrinsic helper method name conform to convention
>>  - consolidate chacha macroAssembler routines into chacha stubGenerator file
>>  - More indentation fixes on aarch64
>>  - rename chapoly->chacha for macro file
>>  - rename chacha macro file to be consistent with x86_64 naming
>>  - Fix indentation issues
>
> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 989:
> 
>> 987:                  bool multi_block);
>> 988: 
>> 989:   // ChaCha20-Poly1305 macroAssembler defs
> 
> These methods can also be moved to `stubGenerator_x86_64.hpp`/`stubGenerator_x86_64_chacha.cpp`. There are no other usages besides x86-64-specific CC20 stub.

Done, and removed `macroAssembler_x86_chacha.cpp` since it is no longer needed.

> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 870:
> 
>> 868:      */
>> 869:     @IntrinsicCandidate
>> 870:     private static int _chaCha20Block(int[] initState, byte[] result) {
> 
> Seems like there are 2 major naming conventions for intrinsic helper methods: prepend "impl" (e.g, `CounterMode.implCrypt`) or append "0" (`GaloisCounterMode.implGCMCrypt0`). I'd prefer to see either one used here.

Done.

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

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


From xuelei at openjdk.org  Tue Nov  8 07:00:38 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 07:00:38 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <vhe8NOZgq6P3gA_-9q8fPIFnOPtWjQ16fYV-MH8vHvM=.761e4394-b1c5-4f77-bae7-e099a71e693d@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <vhe8NOZgq6P3gA_-9q8fPIFnOPtWjQ16fYV-MH8vHvM=.761e4394-b1c5-4f77-bae7-e099a71e693d@github.com>
Message-ID: <URMh4ioZFWSLWo4Ove9vCiRtvU9GCnAfCrqcE7j3dj0=.d9682c64-928e-423e-b3ec-3d8dba879e06@github.com>

On Mon, 7 Nov 2022 23:24:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> 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 four commits:
>> 
>>  - Merge
>>  - Merge
>>  - add test cases
>>  - 8281236: (D)TLS key exchange algorithms
>
> Well crafted. LGTM.

Thank you very much, @mcpowers!

May I have the CSR reviewed? https://bugs.openjdk.org/browse/JDK-8291950. The new feature deadline is approaching.  I appreciate if the CSR could be reviewed in 2 weeks.

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

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


From duke at openjdk.org  Tue Nov  8 09:49:22 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Tue, 8 Nov 2022 09:49:22 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no longer
 referenced
Message-ID: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>

SubjectCodeSource is no longer used, Class should be deleted and all references updated

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

Commit messages:
 - Merge branch 'master' into 8294526
 - Merge branch 'master' into 8294526
 - 8294526: SubjectCodeSource is no longer referenced
 - Merge branch 'master' into 8294526
 - Merge branch 'openjdk:master' into 8294526
 - 8294526: SubjectCodeSource is no longer used, removing class and all references

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

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


From weijun at openjdk.org  Tue Nov  8 09:49:23 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 09:49:23 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced
In-Reply-To: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
Message-ID: <FgDIjYdYsUHQ0gVKmEImxzKKC7tO8eiJ2TCcaHOXHgQ=.0d73bd33-b6c3-4646-97d4-fa28e58a21fa@github.com>

On Tue, 4 Oct 2022 08:25:10 GMT, Ryan Wallace <duke at openjdk.org> wrote:

> SubjectCodeSource is no longer used, Class should be deleted and all references updated

Marked as reviewed by weijun (Reviewer).

test/jdk/sun/security/provider/PolicyFile/Comparator.java line 27:

> 25:  * @test
> 26:  * @bug 5037004
> 27:  * @summary Frivolous ClassCastExceptions thrown by CodeSource.implies

The original bug is probably not related to CodeSource. Also, I don't know if this test is still relevant since SubjectCodeSource is already useless.

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

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


From duke at openjdk.org  Tue Nov  8 10:01:47 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Tue, 8 Nov 2022 10:01:47 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
Message-ID: <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>

> SubjectCodeSource is no longer used, Class should be deleted and all references updated

Ryan Wallace 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 branch 'master' into 8294526
 - Merge branch 'master' into 8294526
 - Merge branch 'master' into 8294526
 - 8294526: SubjectCodeSource is no longer referenced
 - Merge branch 'master' into 8294526
 - Merge branch 'openjdk:master' into 8294526
 - 8294526: SubjectCodeSource is no longer used, removing class and all references

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10550/files
  - new: https://git.openjdk.org/jdk/pull/10550/files/a41e36ce..feb38b83

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

  Stats: 3063 lines in 73 files changed: 1498 ins; 1312 del; 253 mod
  Patch: https://git.openjdk.org/jdk/pull/10550.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10550/head:pull/10550

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


From mullan at openjdk.org  Tue Nov  8 13:41:33 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 13:41:33 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
Message-ID: <nTN73bMFJmKoEH9Ar-pUUgTcuoqOyVUOw3SXQNtd9Rg=.9b954d7e-400d-4e4b-bed8-24fd99e2152a@github.com>

On Mon, 7 Nov 2022 12:49:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.

Add a `noreg-self` label to the JBS issue since this is a fix to the test itself. Also, I would classify this as an Enhancement, and not a Bug.

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

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


From mbaesken at openjdk.org  Tue Nov  8 13:56:27 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Nov 2022 13:56:27 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <nTN73bMFJmKoEH9Ar-pUUgTcuoqOyVUOw3SXQNtd9Rg=.9b954d7e-400d-4e4b-bed8-24fd99e2152a@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
 <nTN73bMFJmKoEH9Ar-pUUgTcuoqOyVUOw3SXQNtd9Rg=.9b954d7e-400d-4e4b-bed8-24fd99e2152a@github.com>
Message-ID: <TtSoTQ6XKs5COBhPbO6PZ01c1ZcEr3SSnLa6Jvar8PA=.7f0b20ec-c5aa-4888-9187-7383cf62339b@github.com>

On Tue, 8 Nov 2022 13:37:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Add a `noreg-self` label to the JBS issue since this is a fix to the test itself. Also, I would classify this as an Enhancement, and not a Bug.

Thanks, this all makes sense ! I adjusted the JBS issue.

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

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


From mullan at openjdk.org  Tue Nov  8 14:05:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 14:05:30 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
Message-ID: <YG3_c5DwL_VL-oVHYu3HsmymuqORckLkFkR_X3UKSrM=.32e5200f-bcac-4e3f-9a1e-2eaa9949e553@github.com>

On Mon, 7 Nov 2022 12:49:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.

Changes requested by mullan (Reviewer).

test/jdk/java/security/Exceptions/ChainingConstructors.java line 40:

> 38:     private static Exception cause = new Exception("cause");
> 39: 
> 40:     public static void main(String[] args) throws Exception {

I would add the bugid to line 26 since you are adding an additional test for CertPathBuilderException.

test/jdk/java/security/Exceptions/ChainingConstructors.java line 208:

> 206:             throw new SecurityException("Test 17 failed");
> 207:         }
> 208: */

I don't know why this is commented out, but when I uncomment it, the test still passes, so I would include a test for `SSLException` below.

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

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


From mbaesken at openjdk.org  Tue Nov  8 15:19:38 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Nov 2022 15:19:38 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <YG3_c5DwL_VL-oVHYu3HsmymuqORckLkFkR_X3UKSrM=.32e5200f-bcac-4e3f-9a1e-2eaa9949e553@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
 <YG3_c5DwL_VL-oVHYu3HsmymuqORckLkFkR_X3UKSrM=.32e5200f-bcac-4e3f-9a1e-2eaa9949e553@github.com>
Message-ID: <LH-bt0pVIhehB8HurvTFEH0N4JnXML38ttj6_DNOGaY=.4ddbfad4-7b85-4d21-9560-256d5e799269@github.com>

On Tue, 8 Nov 2022 14:01:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.
>
> test/jdk/java/security/Exceptions/ChainingConstructors.java line 208:
> 
>> 206:             throw new SecurityException("Test 17 failed");
>> 207:         }
>> 208: */
> 
> I don't know why this is commented out, but when I uncomment it, the test still passes, so I would include a test for `SSLException` below.

Hi Sean,  the summary says that the test is about  "java.security Exceptions" so  javax.net.ssl.SSLException.java from another package might not fit in, maybe that's why it was commented out.
Should I still add it ? If so, the  summary comment might need a little bit adjustment, what about this "Test constructors for exception chaining of  security-related exceptions"  ?

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

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


From mullan at openjdk.org  Tue Nov  8 15:56:38 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 15:56:38 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <LH-bt0pVIhehB8HurvTFEH0N4JnXML38ttj6_DNOGaY=.4ddbfad4-7b85-4d21-9560-256d5e799269@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
 <YG3_c5DwL_VL-oVHYu3HsmymuqORckLkFkR_X3UKSrM=.32e5200f-bcac-4e3f-9a1e-2eaa9949e553@github.com>
 <LH-bt0pVIhehB8HurvTFEH0N4JnXML38ttj6_DNOGaY=.4ddbfad4-7b85-4d21-9560-256d5e799269@github.com>
Message-ID: <_iLV5GoOQwmL2aHcR9GAj4Z1DHaJS9f_VHFFrbDZ0Tc=.008c63b7-7092-47a0-8847-ac13fedf613f@github.com>

On Tue, 8 Nov 2022 15:15:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/jdk/java/security/Exceptions/ChainingConstructors.java line 208:
>> 
>>> 206:             throw new SecurityException("Test 17 failed");
>>> 207:         }
>>> 208: */
>> 
>> I don't know why this is commented out, but when I uncomment it, the test still passes, so I would include a test for `SSLException` below.
>
> Hi Sean,  the summary says that the test is about  "java.security Exceptions" so  javax.net.ssl.SSLException.java from another package might not fit in, maybe that's why it was commented out.
> Should I still add it ? If so, the  summary comment might need a little bit adjustment, what about this "Test constructors for exception chaining of  security-related exceptions"  ?

Good point. I think it is ok to make an exception (no pun intended) for `SSLException` for this test. Changing the summary comment to your suggestion is fine with me.

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

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


From mbaesken at openjdk.org  Tue Nov  8 16:16:53 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Nov 2022 16:16:53 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication [v2]
In-Reply-To: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
Message-ID: <g6Fd8q6Gjec28g_hvP7XXe3K-AXE9SsvcUJ05ChIk6Y=.6b93e2ba-c950-4a22-9b15-7cc8a140bff4@github.com>

> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add SSLException test, adjust summary, add bug-id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11016/files
  - new: https://git.openjdk.org/jdk/pull/11016/files/b4df45d3..5e1c7155

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

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

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


From mbaesken at openjdk.org  Tue Nov  8 16:18:26 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Nov 2022 16:18:26 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
Message-ID: <3y1Uax-0N7zqbBrOFUbzdRONGDOyx0ICH3s_OT1Y95I=.decec1a7-6b42-41c9-8710-d86f356441d6@github.com>

On Mon, 7 Nov 2022 12:49:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.

I added the second bug id, adjusted the summary comment and added SSLException for this test.

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

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


From mullan at openjdk.org  Tue Nov  8 16:26:20 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 16:26:20 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v5]
In-Reply-To: <nNRUMHWFV-vlqOAlqxTfPUwMU1C9QtlqyiryyB4hM3Y=.e29af3f2-db9d-40fe-a77a-b8acf4026faf@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <nNRUMHWFV-vlqOAlqxTfPUwMU1C9QtlqyiryyB4hM3Y=.e29af3f2-db9d-40fe-a77a-b8acf4026faf@github.com>
Message-ID: <mVO-5Kl3kqBI7ySyCC03Zt32On-5XrHgPaMHllLhDeo=.9bf40963-129a-48bc-8d94-64f9ae3e8bbb@github.com>

On Fri, 4 Nov 2022 15:58:01 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:
> 
>   Further code review comments and new keytool test coverage with JFR

> 

My vote would be to leave it out. `keytool` already emits warnings when weak algorithms are used. It seems we both agree that few users, will likely enable JFR on `keytool`. We could always add these events later, but it is harder to remove them once they are in there.

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

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


From xuelei at openjdk.org  Tue Nov  8 16:44:47 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 16:44:47 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
Message-ID: <FfVUYgwI3-HDqr0WnmxhStKIJvoVZ70fp7FcnoE-bkM=.ed69e593-623d-4ad3-aaa8-b7a732cffe41@github.com>

On Tue, 8 Nov 2022 10:01:47 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> SubjectCodeSource is no longer used, Class should be deleted and all references updated
>
> Ryan Wallace 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 branch 'master' into 8294526
>  - Merge branch 'master' into 8294526
>  - Merge branch 'master' into 8294526
>  - 8294526: SubjectCodeSource is no longer referenced
>  - Merge branch 'master' into 8294526
>  - Merge branch 'openjdk:master' into 8294526
>  - 8294526: SubjectCodeSource is no longer used, removing class and all references

Changes requested by xuelei (Reviewer).

test/jdk/sun/security/provider/PolicyFile/Comparator.java line 36:

> 34:  *
> 35:  * Note: SubjectCodeSource removed, but PolicyFile might have the same problem. Keep the test as-is
> 36:  *

I may have the note in a bug description instead.  Is it safe to remove this test and related files?

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

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


From mpowers at openjdk.org  Tue Nov  8 16:55:29 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 8 Nov 2022 16:55:29 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
Message-ID: <TZw1t6bHlJGLfovQqmcDPbObz97g85QifROYuO_wwlA=.637592e9-c99c-4bb9-8daa-a9a5e99934cc@github.com>

On Mon, 7 Nov 2022 18:48:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> 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 four commits:
> 
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

I'll look at your CSR this morning. Make sure your SSLParameters additions look correct with JavaDoc. I always forget that step.

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

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


From mullan at openjdk.org  Tue Nov  8 17:37:18 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 17:37:18 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication [v2]
In-Reply-To: <g6Fd8q6Gjec28g_hvP7XXe3K-AXE9SsvcUJ05ChIk6Y=.6b93e2ba-c950-4a22-9b15-7cc8a140bff4@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
 <g6Fd8q6Gjec28g_hvP7XXe3K-AXE9SsvcUJ05ChIk6Y=.6b93e2ba-c950-4a22-9b15-7cc8a140bff4@github.com>
Message-ID: <V4n8SDKwmLjZXz4r9Yx3vUjvSRLUxJqrRMiakj99J1s=.d2fc5fb2-c41e-4a85-9acd-3947600949c6@github.com>

On Tue, 8 Nov 2022 16:16:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add SSLException test, adjust summary, add bug-id

Looks good!

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

Marked as reviewed by mullan (Reviewer).

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


From mullan at openjdk.org  Tue Nov  8 17:40:32 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 17:40:32 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v5]
In-Reply-To: <iPpgwYZSuI-9Lg9IZgL7SpvshS8wWsmw5gdolLtk-Kw=.f0e2df6b-772f-4e43-90b3-cfbb5575ea4c@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <iPpgwYZSuI-9Lg9IZgL7SpvshS8wWsmw5gdolLtk-Kw=.f0e2df6b-772f-4e43-90b3-cfbb5575ea4c@github.com>
Message-ID: <KCqZUOpI2Wu0qfYa3WSjOQLPRjfK2INy09xFyq09enA=.d4e19a27-3b73-4e28-97bb-7c4d807ed6aa@github.com>

On Sun, 6 Nov 2022 22:00:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
>> 
>> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
>> 
>> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
>> 
>> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
>> 
>> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
>> 
>> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return (abc) to return abc

src/java.base/share/classes/sun/security/x509/CertAttrSet.java line 35:

> 33:  * This interface defines a certificate attribute that can be DER-encoded.
> 34:  */
> 35: public interface CertAttrSet {

Should we rename this to "CertAttr" since I think it now supports a single attribute?

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

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


From weijun at openjdk.org  Tue Nov  8 17:52:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 17:52:27 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v5]
In-Reply-To: <KCqZUOpI2Wu0qfYa3WSjOQLPRjfK2INy09xFyq09enA=.d4e19a27-3b73-4e28-97bb-7c4d807ed6aa@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <iPpgwYZSuI-9Lg9IZgL7SpvshS8wWsmw5gdolLtk-Kw=.f0e2df6b-772f-4e43-90b3-cfbb5575ea4c@github.com>
 <KCqZUOpI2Wu0qfYa3WSjOQLPRjfK2INy09xFyq09enA=.d4e19a27-3b73-4e28-97bb-7c4d807ed6aa@github.com>
Message-ID: <SJwbEMMi1KujLVP_B15Xqe7hIbfU1HROfdtXhvTDobs=.3f02816d-be09-4f81-b64f-90b3ee18bd05@github.com>

On Tue, 8 Nov 2022 17:37:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   return (abc) to return abc
>
> src/java.base/share/classes/sun/security/x509/CertAttrSet.java line 35:
> 
>> 33:  * This interface defines a certificate attribute that can be DER-encoded.
>> 34:  */
>> 35: public interface CertAttrSet {
> 
> Should we rename this to "CertAttr" since I think it now supports a single attribute?

Since it only has `encode` now, I'll merge it with `DerEncoder` and remove it in my next step. Therefore I haven't cared about giving it a better name. I had thought about including the merge inside this change but there are a lot of `s/derEncode/encode/` renaming and it's better to be done separately.

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

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


From mullan at openjdk.org  Tue Nov  8 18:08:35 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 18:08:35 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v5]
In-Reply-To: <iPpgwYZSuI-9Lg9IZgL7SpvshS8wWsmw5gdolLtk-Kw=.f0e2df6b-772f-4e43-90b3-cfbb5575ea4c@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <iPpgwYZSuI-9Lg9IZgL7SpvshS8wWsmw5gdolLtk-Kw=.f0e2df6b-772f-4e43-90b3-cfbb5575ea4c@github.com>
Message-ID: <vXko8X4nPKGvqMFxvpg2nzQwj-EcxB7c5K2ruinYiB8=.a5b8bb76-47e7-46f3-8fc6-1160f1409093@github.com>

On Sun, 6 Nov 2022 22:00:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
>> 
>> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
>> 
>> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
>> 
>> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
>> 
>> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
>> 
>> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return (abc) to return abc

Great stuff, just a few minor comments.

src/java.base/share/classes/java/security/cert/X509CertSelector.java line 1313:

> 1311:      */
> 1312:     public byte[] getIssuerAsBytes() throws IOException {
> 1313:         return issuer == null ? null: issuer.getEncoded();

Nit, add space between "null" and ":".

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 686:

> 684:         String n = oid.toString();
> 685:         KnownOIDs os = KnownOIDs.findMatch(n);
> 686:         return os == null? n : os.stdName();

Nit: add space between "null" and "?".

src/java.base/share/classes/sun/security/provider/certpath/Builder.java line 207:

> 205:         case GeneralNameInterface.NAME_NARROWS:
> 206:             /* base is descendant of test */
> 207:             return test.subtreeDepth()-base.subtreeDepth();

Nit: add spaces around "-".

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1498:

> 1496: 
> 1497:         info.setKey(new CertificateX509Key(req.getSubjectPublicKeyInfo()));
> 1498:         info.setSubject(dname==null?req.getSubjectName():new X500Name(dname));

Add spaces between "?" and ":".

src/java.base/share/classes/sun/security/x509/CertificatePoliciesExtension.java line 185:

> 183:      */
> 184:     public List<PolicyInformation> getCertPolicies() {
> 185:         //XXXX May want to consider cloning this

I would remove this comment. This method is internal and as long as the List is not exposed via a public API (please double-check), a clone is not necessary.

src/java.base/share/classes/sun/security/x509/ExtendedKeyUsageExtension.java line 203:

> 201:      */
> 202:     public Vector<ObjectIdentifier> getUsages() {
> 203:         //XXXX May want to consider cloning this

Remove comment if returned Vector cannot be accessed via public APIs.

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

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


From xuelei at openjdk.org  Tue Nov  8 18:46:09 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 18:46:09 GMT
Subject: RFR: 8296591: Signature benchmark
Message-ID: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>

Hi,

May I have the micro-benchmark code reviewed for EC signature algorithms?  The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.

Thanks,
Xuelei

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

Commit messages:
 - 8296591: Signature benchmark

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

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


From weijun at openjdk.org  Tue Nov  8 19:48:48 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 19:48:48 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v6]
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <8z8_xhbFRmrLTFcvhMWiRD_RSkGju7tn7d20aVwQCnU=.50f1b3eb-d2d8-432d-98f1-878c333cc16d@github.com>

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

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

  more cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10959/files
  - new: https://git.openjdk.org/jdk/pull/10959/files/b4453f66..a62ef66d

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

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

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


From mullan at openjdk.org  Tue Nov  8 19:48:48 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 19:48:48 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v6]
In-Reply-To: <8z8_xhbFRmrLTFcvhMWiRD_RSkGju7tn7d20aVwQCnU=.50f1b3eb-d2d8-432d-98f1-878c333cc16d@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
 <8z8_xhbFRmrLTFcvhMWiRD_RSkGju7tn7d20aVwQCnU=.50f1b3eb-d2d8-432d-98f1-878c333cc16d@github.com>
Message-ID: <ei8eMsSJgyLIf-ePpKlU_nUL163rn8YMTWdpbFgF6HQ=.4f7ca9e5-2eb5-4c15-89c4-317094e6f6e2@github.com>

On Tue, 8 Nov 2022 19:45:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
>> 
>> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
>> 
>> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
>> 
>> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
>> 
>> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
>> 
>> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

Marked as reviewed by mullan (Reviewer).

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

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


From weijun at openjdk.org  Tue Nov  8 20:15:08 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 20:15:08 GMT
Subject: RFR: 8296591: Signature benchmark
In-Reply-To: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
Message-ID: <3_C3bZ0kcqB594kihv4O1nPNWBaz3eP1QbsZ1y2DcFo=.ecf9c432-d820-4feb-ae89-75edf3b9dfc9@github.com>

On Tue, 8 Nov 2022 18:38:59 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the micro-benchmark code reviewed for EC signature algorithms?  The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.
> 
> Thanks,
> Xuelei

One small comment.

test/micro/org/openjdk/bench/java/security/Signatures.java line 60:

> 58: 
> 59:         String signName = switch (curveName) {
> 60:             case "secp256r1" -> "Sha256WithECDSA";

We usually write "SHA256withECDSA".

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

Marked as reviewed by weijun (Reviewer).

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


From xuelei at openjdk.org  Tue Nov  8 20:40:49 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 20:40:49 GMT
Subject: RFR: 8296591: Signature benchmark [v2]
In-Reply-To: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
Message-ID: <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>

> Hi,
> 
> May I have the micro-benchmark code reviewed for EC signature algorithms?  The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.
> 
> Thanks,
> Xuelei

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

  use standard names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11043/files
  - new: https://git.openjdk.org/jdk/pull/11043/files/003d6f7f..fccfba96

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

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

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


From xuelei at openjdk.org  Tue Nov  8 20:40:50 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 20:40:50 GMT
Subject: RFR: 8296591: Signature benchmark [v2]
In-Reply-To: <3_C3bZ0kcqB594kihv4O1nPNWBaz3eP1QbsZ1y2DcFo=.ecf9c432-d820-4feb-ae89-75edf3b9dfc9@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
 <3_C3bZ0kcqB594kihv4O1nPNWBaz3eP1QbsZ1y2DcFo=.ecf9c432-d820-4feb-ae89-75edf3b9dfc9@github.com>
Message-ID: <7qMTvL1bDLT1rlWU4onLrDNs8-2vi6ku4_48txORqzE=.9caf9344-5e73-4296-bd03-d616c5be0ff4@github.com>

On Tue, 8 Nov 2022 20:10:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use standard names
>
> test/micro/org/openjdk/bench/java/security/Signatures.java line 60:
> 
>> 58: 
>> 59:         String signName = switch (curveName) {
>> 60:             case "secp256r1" -> "Sha256WithECDSA";
> 
> We usually write "SHA256withECDSA".

Yes, it makes sense to me.  Thanks!

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

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


From xuelei at openjdk.org  Tue Nov  8 20:55:24 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 20:55:24 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <TZw1t6bHlJGLfovQqmcDPbObz97g85QifROYuO_wwlA=.637592e9-c99c-4bb9-8daa-a9a5e99934cc@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <TZw1t6bHlJGLfovQqmcDPbObz97g85QifROYuO_wwlA=.637592e9-c99c-4bb9-8daa-a9a5e99934cc@github.com>
Message-ID: <lLF73OpYGmtilgUW2vxRmI1ZlcZlBivM0yLjwI7BRt8=.da96f190-d0b8-44ef-aa71-ae4621eb5e88@github.com>

On Tue, 8 Nov 2022 16:51:24 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> I'll look at your CSR this morning. Make sure your SSLParameters additions look correct with JavaDoc. I always forget that step.

Thank you for the suggestion.  I double checked the JavaDoc.  It looks good to me.

Please feel free to add your name as reviewer in the CSR and approve this PR when you are ready.

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

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


From mpowers at openjdk.org  Tue Nov  8 21:22:33 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 8 Nov 2022 21:22:33 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
Message-ID: <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>

On Mon, 7 Nov 2022 18:48:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> 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 four commits:
> 
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

Unfortunately, I only have author status and can only comment.

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

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


From weijun at openjdk.org  Tue Nov  8 21:36:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 21:36:10 GMT
Subject: RFR: 8296143: CertAttrSet's set/get mechanism is not type-safe
 [v7]
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <MO_CDicgBlzlzNPS42KFeK8rW91Xg1-UofmILlIwlcg=.d50f7a90-21d4-4fe8-8ab8-55d3125fc949@github.com>

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

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

  PKCS10Attributes::getElements still used by a test
  
  reverted:

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10959/files
  - new: https://git.openjdk.org/jdk/pull/10959/files/a62ef66d..c6ea9004

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

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

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


From duke at openjdk.org  Tue Nov  8 21:41:58 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 8 Nov 2022 21:41:58 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v8]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <hvPoXsSiGzJ9BPfCYeojijb4C7mkJ4lVMyWIOpZM5Fc=.ca0faad6-dcd8-4cf1-9f47-3213a15252f7@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

Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - make UsePolyIntrinsics option diagnostic
 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - iwanowww review
 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - address Jamil's review
 - invalidkeyexception and some review comments
 - extra whitespace character
 - assembler checks and test case fixes
 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - Merge remote-tracking branch 'origin' into avx512-poly
 - ... and 5 more: https://git.openjdk.org/jdk/compare/0ee25de7...120247d5

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

Changes: https://git.openjdk.org/jdk/pull/10582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=07
  Stats: 1814 lines in 32 files changed: 1777 ins; 3 del; 34 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  Tue Nov  8 21:42:03 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 8 Nov 2022 21:42:03 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v7]
In-Reply-To: <yakJWzO8mmn5VJ0WpAEAwo1DHqpq2xkkD-oQol0gEhA=.dc776ad9-a666-4928-b59c-087af1052508@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <tLmwiB4fMB94Svqu8YbprTU5DZjwVSoEdKys-Nn5N0M=.32d50548-56bf-4d77-8df9-cc86cec38023@github.com>
 <f0Bv-td_2zmCQ7F8RjVS-O5SK36DolXJt83FD34zsuY=.d5336884-e8ae-4f01-bf23-47f6fec785c7@github.com>
 <yakJWzO8mmn5VJ0WpAEAwo1DHqpq2xkkD-oQol0gEhA=.dc776ad9-a666-4928-b59c-087af1052508@github.com>
Message-ID: <Cr5sMZZzFMDx4R0I_zUtQHeKVdRx0ctdVWgl9VJQ6xA=.5ae8e681-acc2-4044-b29a-4ff70ebf98dd@github.com>

On Fri, 4 Nov 2022 17:25:16 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 7036:
>> 
>>> 7034:   assert(r_start, "r array is NULL");
>>> 7035: 
>>> 7036:   Node* call = make_runtime_call(RC_LEAF,
>> 
>> Can we safely change this to `RC_LEAF | RC_NO_FP`?  For the ChaCha20 block intrinsic I'm working on I've been using that parameter because I'm not touching the FP registers and that looks to be the case here (though your intrinsic is a lot more complicated than mine so I may have missed something).  I believe the GHASH and AES library call routines also call `make_runtime_call()` in this way.
>
> Makes sense to me, will put it in and re-test (no fp registers anywhere in the intrinsic). Thanks!

done

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

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


From duke at openjdk.org  Tue Nov  8 21:42:08 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 8 Nov 2022 21:42:08 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
 <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
Message-ID: <xOU5sYvutNsfaUK4Elp2mPQ1bXTLb0jksx97Z4zfRBE=.1c46e399-69d7-4ed4-9635-41129c0f379d@github.com>

On Tue, 1 Nov 2022 23:21:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   invalidkeyexception and some review comments
>
> src/hotspot/share/runtime/globals.hpp line 241:
> 
>> 239:           "Use intrinsics for java.util.Base64")                            \
>> 240:                                                                             \
>> 241:   product(bool, UsePolyIntrinsics, false,                                   \
> 
> I'm not a fan of introducing new flags for individual intrinsics (there's already `-XX:DisableIntrinsic=_name` specifically for that), but since we already have many, shouldn't it be declared as a diagnostic flag, at least?

Started removing the option, but its quite convenient to have the boolean global, so just made the option diagnostic. 
"done"

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

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


From xuelei at openjdk.org  Tue Nov  8 21:57:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 21:57:30 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
Message-ID: <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>

On Tue, 8 Nov 2022 21:18:20 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> Unfortunately, I only have author status and can only comment.

I think OpenJDK Author can approve as well.  I just need to get another Reviewer approval before integration.

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

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


From duke at openjdk.org  Tue Nov  8 22:03:20 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 8 Nov 2022 22:03:20 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
 <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
 <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>
Message-ID: <hFUaLY8cUCfXRbJCKtDcefgrwZvl2X53q1QPVUEosqc=.7980aa45-d193-49cc-b3f1-15a8eb45576e@github.com>

On Tue, 1 Nov 2022 23:49:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2002:
>> 
>>> 2000: }
>>> 2001: 
>>> 2002: address StubGenerator::generate_poly1305_masksCP() {
>> 
>> I suggest to turn it into a C++ literal constant and move the declaration next to `poly1305_process_blocks_avx512` where they are used. As an example, here's how it is handled in GHASH stubs:
>>   https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp#L35
>> 
>> That would allow to avoid to simplify the code a bit (no need in `StubRoutines::x86::_poly1305_mask_addr`/`poly1305_mask_addr()` and no need to generate the constants during VM startup).
>> 
>> You could split it into 3 constants, but then using a single base register (`polyCP`) won't work anymore.
>> Thinking more about it, I'm not sure why you can't just do the split and use address literals instead  to access individual constants (and repurpose `r13` to be used as a scratch register when RIP-relative addressing mode doesn't work).
>
> The case of AES stubs may be even a better fit here:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp#L47
> 
> It doesn't use/introduce any shared constants, so declaring a constant and a local accessor (to save on pointer to address casts at use sites) is enough.

@iwanowww moved to StubGenerator as suggested.. moving functions to the stubGenerator_x86_64.hpp header doesn't seem 'clean' but I think that's the pattern.

The constant pool.. stared at it for a while and ended up keeping it mostly intact (its now a static function, not a member function; header bit cleaner; followed AES pattern). 

Did not split it up into individual constants. The main 'problem' is that `Address` and `ExternalAddress` are not compatible. Most instructions do not take `AddressLiteral`, so can't use `ExternalAddress` to refer to those constants. (If I did get the instructions I use to take `AddressLiteral`, I think we would end up with more `lea(rscratch)`s generated; but that's more of a silver-lining)

I also thought of loading constants at run-time, (load and replicate for vector.. what I mentioned in my comment above) but that seems needlessly complicated in hindsight..

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

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


From mullan at openjdk.org  Tue Nov  8 22:11:39 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 22:11:39 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
 <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
Message-ID: <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>

On Tue, 8 Nov 2022 21:52:51 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > Unfortunately, I only have author status and can only comment.
> 
> I think OpenJDK Author can approve as well. I just need to get another Reviewer approval before integration.

For a CSR, I believe that is true. But you will need a Reviewer for the PR, and they may have comments on parts that are covered by the CSR.

I would suggest moving the CSR to Proposed (which doesn't require a Reviewer AFAIK). That will move it forward a bit.

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

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


From xuelei at openjdk.org  Tue Nov  8 22:35:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 22:35:32 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
 <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
 <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
Message-ID: <cTRH5KEFZzZ-ju6W_ELx5k5gHzBq9Ujv8AcAQVTJQGY=.88b6000a-a931-40fa-b888-4186a604773f@github.com>

On Tue, 8 Nov 2022 22:07:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Unfortunately, I only have author status and can only comment.
> > 
> > 
> > I think OpenJDK Author can approve as well. I just need to get another Reviewer approval before integration.
> 
> For a CSR, I believe that is true. But you will need a Reviewer for the PR, and they may have comments on parts that are covered by the CSR.
> 

+1.

> I would suggest moving the CSR to Proposed (which doesn't require a Reviewer AFAIK). That will move it forward a bit.

I changed the CSR to Proposed.  Thanks for the suggestion.

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

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


From weijun at openjdk.org  Tue Nov  8 22:39:01 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 22:39:01 GMT
Subject: Integrated: 8296143: CertAttrSet's set/get mechanism is not type-safe
In-Reply-To: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
References: <APTpz1uocWvOh0zbcExxz3ejswi084B2N2_zEbhgxyA=.1a92dc36-faca-486f-9e61-307e43faa0a5@github.com>
Message-ID: <34UGariEaE2EeQEX86lsROENQ3Hv3zyUQaB_Vvp6EeU=.5a3065ee-9b94-410d-8466-e227692012c2@github.com>

On Wed, 2 Nov 2022 19:52:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The major change is to remove the `get` and `set` methods in various `CertAttrSet` child classes and change them to `setXyz` and `getXyz` methods. The `Xyz` words might come from the field name or the attribute name. For example, `X509CertInfo` now has `setExtensions` and `setValidity` instead of `set("extensions", exts)` and `set("validity", validity)`. This also has the benefit to remove a lot of try-catch blocks on `IOException`s on "unknown attributes" because everything is known now. At the same time, all the identifier name and attribute names are removed from `CertAttrSet` child classes. The only left is `NAME` in extensions since it's still used as keys in `CertificateExtensions`.
> 
> Besides assigning a new value to an internal field, the original `set` methods might also re-encode by calling `encodeThis`, invalidate the cached encoding (in `X509CertInfo`), or check for read-only flag (in `X509CertImp`). Newly added `setXyz` methods are doing the same. This is one place that future new setter methods should remember.
> 
> Most `get` implementations simply return an internal field. One exception in `X509CertImpl` is that when getting something inside the `X509CertInfo`, it wraps exceptions into a new `CertificateParsingException`. This is actually related to the way `CertificateExtensions::get` is implemented where an exception is thrown when an extension does not exist. `CertificateExtensions::getExtension` has been rewritten to follow the `CRLExtensions::getExtension` style where `null` is returned in this case.
> 
> The only method left in `CertAttrSet` is `encode`, and it no longer throws a `CertificateException`.
> 
> Several classes do have their attributes, and still has get/set methods. This includes `CertificateExtensions`, `CRLExtensions`, `ReasonFlags`, `KeyUsageExtension`, and `NetscapeCertTypeExtensions`. Some methods are renamed to be clearer. For example, in `CertificateExtensions`, we have `getExtension` instead of `get`.
> 
> There are no more `AttributeNameEnumeration.java` and `X509AttributeName.java`.

This pull request has now been integrated.

Changeset: 671f84bd
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/671f84bd8625ea7e06fa8272ae629309df06e9ca
Stats:     2954 lines in 66 files changed: 63 ins; 2322 del; 569 mod

8296143: CertAttrSet's set/get mechanism is not type-safe

Reviewed-by: mullan

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

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


From weijun at openjdk.org  Tue Nov  8 22:48:56 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Nov 2022 22:48:56 GMT
Subject: RFR: 8296612: CertAttrSet is useless
Message-ID: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>

- All `CertAttrSet` child classes now implement `DerEncoder`
- `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate methods are removed
- `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need to implement it
- `X509CertImpl::encode(OutputStream out)` removed, used nowhere

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11048/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296612
  Stats: 207 lines in 52 files changed: 4 ins; 134 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/11048.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11048/head:pull/11048

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


From duke at openjdk.org  Tue Nov  8 23:21:58 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 8 Nov 2022 23:21:58 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@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

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  fix 32-bit build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/120247d5..da560452

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

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 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 vlivanov at openjdk.org  Wed Nov  9 00:29:32 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 9 Nov 2022 00:29:32 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
Message-ID: <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>

On Tue, 8 Nov 2022 23:21:58 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix 32-bit build

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 970:

> 968: 
> 969:   void addmq(int disp, Register r1, Register r2);
> 970: 

Leftover formatting changes.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 95:

> 93: 
> 94:   // OFFSET 64: mask_44
> 95:   0xfffffffffff, 0xfffffffffff,

Please, keep leading zeroes explicit in the constants.

src/hotspot/cpu/x86/stubRoutines_x86.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2013, 2022, Oracle and/or its affiliates. All rights reserved.

No changes in the file anymore.

src/hotspot/share/opto/library_call.cpp line 7014:

> 7012:   const TypeKlassPtr* rklass = TypeKlassPtr::make(instklass_ImmutableElement);
> 7013:   const TypeOopPtr* rtype = rklass->as_instance_type()->cast_to_ptr_type(TypePtr::NotNull);
> 7014:   Node* rObj = new CheckCastPPNode(control(), rFace, rtype);

FTR it's an unsafe cast since it  doesn't involve a runtime check from `IntegerModuloP` to `ImmutableElement`. Please, lift as much checks into Java wrapper as possible.

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 175:

> 173: 
> 174:         int blockMultipleLength = len & (~(BLOCK_LENGTH-1));
> 175:         Objects.checkFromIndexSize(offset, blockMultipleLength, input.length);

I suggest to move the checks into `processMultipleBlocks`, introduce new static helper method specifically for the intrinsic part, and lift more logic (e.g., field loads) from the intrinsic into Java code.

As an additional step, you can switch to double-register addressing mode (base + offset) for input data (`input`, `alimbs`, `rlimbs`) and simplify the intrinsic part even more (will involve a switch from `array_element_address` to `make_unsafe_address`).

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

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


From vlivanov at openjdk.org  Wed Nov  9 00:42:32 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 9 Nov 2022 00:42:32 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <hFUaLY8cUCfXRbJCKtDcefgrwZvl2X53q1QPVUEosqc=.7980aa45-d193-49cc-b3f1-15a8eb45576e@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
 <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
 <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>
 <hFUaLY8cUCfXRbJCKtDcefgrwZvl2X53q1QPVUEosqc=.7980aa45-d193-49cc-b3f1-15a8eb45576e@github.com>
Message-ID: <asa1G1rY6oVsgFHuXITPmNXCuryU8b5vJRNj8RMnZng=.f5f4e431-48c2-4896-998a-fb418992b581@github.com>

On Tue, 8 Nov 2022 22:01:19 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Did not split it up into individual constants. The main 'problem' is that Address and ExternalAddress are not compatible. 

There's a reason for that and it's because RIP-relative addressing doesn't always work, so additional register may be needed.

> Most instructions do not take AddressLiteral, so can't use ExternalAddress to refer to those constants. 

I counted 4 instructions accessing the constants (`evpandq`, `andq`, `evporq`, and `vpternlogq`) in your patch. 

`macroAssembler_x86.hpp` is the place for `AddressLiteral`-related overloads (there are already numerous cases present) and it's trivial to add new ones. 

> (If I did get the instructions I use to take AddressLiteral, I think we would end up with more lea(rscratch)s generated; but that's more of a silver-lining)

It depends on memory layout. If constants end up placed close enough in the address space, there'll be no additional instructions generated.

Anyway, it doesn't look like something important from throughput perspective. Overall, I find it clearer when the code refers to individual constants through `AddressLiteral`s, but I'm also fine with it as it is now.

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

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


From egahlin at openjdk.org  Wed Nov  9 01:14:54 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 9 Nov 2022 01:14:54 GMT
Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly
Message-ID: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>

Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool.

Testing:
test/jdk/jdk/jfr
test/jdk/jdk/security/logging/

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/11039/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11039&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296229
  Stats: 78 lines in 15 files changed: 36 ins; 1 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/11039.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11039/head:pull/11039

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


From duke at openjdk.org  Wed Nov  9 02:22:01 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 02:22:01 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <asa1G1rY6oVsgFHuXITPmNXCuryU8b5vJRNj8RMnZng=.f5f4e431-48c2-4896-998a-fb418992b581@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
 <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
 <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>
 <hFUaLY8cUCfXRbJCKtDcefgrwZvl2X53q1QPVUEosqc=.7980aa45-d193-49cc-b3f1-15a8eb45576e@github.com>
 <asa1G1rY6oVsgFHuXITPmNXCuryU8b5vJRNj8RMnZng=.f5f4e431-48c2-4896-998a-fb418992b581@github.com>
Message-ID: <EsOqIOc_ALMLS4KMPlFF7-_NDw8AkVUlla194C8zERY=.699e46f8-7c6c-4f4e-95d3-04ad0e3d13e2@github.com>

On Wed, 9 Nov 2022 00:38:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> @iwanowww moved to StubGenerator as suggested.. moving functions to the stubGenerator_x86_64.hpp header doesn't seem 'clean' but I think that's the pattern.
>> 
>> The constant pool.. stared at it for a while and ended up keeping it mostly intact (its now a static function, not a member function; header bit cleaner; followed AES pattern). 
>> 
>> Did not split it up into individual constants. The main 'problem' is that `Address` and `ExternalAddress` are not compatible. Most instructions do not take `AddressLiteral`, so can't use `ExternalAddress` to refer to those constants. (If I did get the instructions I use to take `AddressLiteral`, I think we would end up with more `lea(rscratch)`s generated; but that's more of a silver-lining)
>> 
>> I also thought of loading constants at run-time, (load and replicate for vector.. what I mentioned in my comment above) but that seems needlessly complicated in hindsight..
>
>> Did not split it up into individual constants. The main 'problem' is that Address and ExternalAddress are not compatible. 
> 
> There's a reason for that and it's because RIP-relative addressing doesn't always work, so additional register may be needed.
> 
>> Most instructions do not take AddressLiteral, so can't use ExternalAddress to refer to those constants. 
> 
> I counted 4 instructions accessing the constants (`evpandq`, `andq`, `evporq`, and `vpternlogq`) in your patch. 
> 
> `macroAssembler_x86.hpp` is the place for `AddressLiteral`-related overloads (there are already numerous cases present) and it's trivial to add new ones. 
> 
>> (If I did get the instructions I use to take AddressLiteral, I think we would end up with more lea(rscratch)s generated; but that's more of a silver-lining)
> 
> It depends on memory layout. If constants end up placed close enough in the address space, there'll be no additional instructions generated.
> 
> Anyway, it doesn't look like something important from throughput perspective. Overall, I find it clearer when the code refers to individual constants through `AddressLiteral`s, but I'm also fine with it as it is now.

Makes sense to me, that would indeed be cleaner, will add a couple more overloads. (Still getting used to what is 'clean' in this code base).

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

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


From duke at openjdk.org  Wed Nov  9 02:22:04 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 02:22:04 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
 <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
Message-ID: <9eURte9F6DahXze39MUQEegF0nNqZRfXh-au-mRNhpA=.b145ca11-9d61-4976-aece-4da91aa2f719@github.com>

On Wed, 9 Nov 2022 00:10:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix 32-bit build
>
> src/hotspot/share/opto/library_call.cpp line 7014:
> 
>> 7012:   const TypeKlassPtr* rklass = TypeKlassPtr::make(instklass_ImmutableElement);
>> 7013:   const TypeOopPtr* rtype = rklass->as_instance_type()->cast_to_ptr_type(TypePtr::NotNull);
>> 7014:   Node* rObj = new CheckCastPPNode(control(), rFace, rtype);
> 
> FTR it's an unsafe cast since it  doesn't involve a runtime check from `IntegerModuloP` to `ImmutableElement`. Please, lift as much checks into Java wrapper as possible.

Ah, yeah.. I quite suspected I didn't emulate all the bytecodes needed. Thanks for the info.

So this is a bit of a quandary.. I had done the intrinsic more in Java before, but it slows down the non-intrinsic path (This was the discussion we were having with Jamil).

In Java, the limbs are not 'accessible' per-se.. They are in a separate package hidden behind and interface.. and in a nested non-static class inside an abstract class... Its quite well designed. Its just makes what I want to do break most encapsulations.

There is a method (`asByteArray`) to extract the limbs that I was previously using, but that slows down non-intrinsic path (to be honest it slows down the intrinsic path too, but the assembler makes some of that back.. You can see that from the numbers I posted for Jamil, vs original in the PR header; originally I got 18x, and now with accessing limbs directly its 19x). 

If I had some way to check 'is intrinsic available', I could at least not slow down the current code. I would still have to break the encapsulation to do the checks/casts though. It all seems less-then-perfect.

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

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


From mbaesken at openjdk.org  Wed Nov  9 08:16:28 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Nov 2022 08:16:28 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication [v2]
In-Reply-To: <g6Fd8q6Gjec28g_hvP7XXe3K-AXE9SsvcUJ05ChIk6Y=.6b93e2ba-c950-4a22-9b15-7cc8a140bff4@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
 <g6Fd8q6Gjec28g_hvP7XXe3K-AXE9SsvcUJ05ChIk6Y=.6b93e2ba-c950-4a22-9b15-7cc8a140bff4@github.com>
Message-ID: <95vd4X1YjJnpCE-XAK5XpFAb-aQ0ufeff6l1CWxopP4=.3283dbb3-0ae5-4646-8c1e-a1ac350a2af3@github.com>

On Tue, 8 Nov 2022 16:16:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add SSLException test, adjust summary, add bug-id

Mark and Sean, thanks for the reviews !
Do I need another review ?
Best regards, Matthias

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

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


From coffeys at openjdk.org  Wed Nov  9 11:22:21 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 9 Nov 2022 11:22:21 GMT
Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly
In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
Message-ID: <s2gzCb0a4NZAray7911iONa1thKD5P8IuMkR9eRe3GU=.59512099-608b-4ed1-beac-6cd44d7c9876@github.com>

On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool.
> 
> Testing:
> test/jdk/jdk/jfr
> test/jdk/jdk/security/logging/
> 
> Thanks
> Erik

Marked as reviewed by coffeys (Reviewer).

LGTM

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

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


From mullan at openjdk.org  Wed Nov  9 13:03:12 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 9 Nov 2022 13:03:12 GMT
Subject: RFR: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication [v2]
In-Reply-To: <95vd4X1YjJnpCE-XAK5XpFAb-aQ0ufeff6l1CWxopP4=.3283dbb3-0ae5-4646-8c1e-a1ac350a2af3@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
 <g6Fd8q6Gjec28g_hvP7XXe3K-AXE9SsvcUJ05ChIk6Y=.6b93e2ba-c950-4a22-9b15-7cc8a140bff4@github.com>
 <95vd4X1YjJnpCE-XAK5XpFAb-aQ0ufeff6l1CWxopP4=.3283dbb3-0ae5-4646-8c1e-a1ac350a2af3@github.com>
Message-ID: <ZNY4jLABPC5_Menu9APTkuHVDR0mYgfUYUJuMfOGeBU=.3b82180e-fe7b-4601-b819-a723a76644d5@github.com>

On Wed, 9 Nov 2022 08:12:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Mark and Sean, thanks for the reviews ! Do I need another review ? Best regards, Matthias

No, you can integrate now.

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

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


From mgronlun at openjdk.org  Wed Nov  9 13:21:35 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 9 Nov 2022 13:21:35 GMT
Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly
In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
Message-ID: <KpOo72dhRFvyNdQrXE6M65B_InUACNwUdytYKeXL5vQ=.75af4f76-27fc-444d-b14c-09910560787e@github.com>

On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool.
> 
> Testing:
> test/jdk/jdk/jfr
> test/jdk/jdk/security/logging/
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

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


From mbaesken at openjdk.org  Wed Nov  9 13:53:12 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Nov 2022 13:53:12 GMT
Subject: Integrated: JDK-8296406: ChainingConstructors jtreg test reduce code
 duplication
In-Reply-To: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
References: <ssnX1xpueAbD0Nfa2QbEeEnpXR0AbQznsaA2RVjrwlQ=.0e41d2c5-de62-4286-9329-5c9fec80273c@github.com>
Message-ID: <8cOuWDR2Dl3hBcuLxu4u-wpe5cRIkMZpAYPoKM5GWnk=.71760ef4-587a-4a36-9064-4d5046a63482@github.com>

On Mon, 7 Nov 2022 12:49:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The java/security/Exceptions/ChainingConstructors jdk jtreg test shows quite a lot of code duplication. The test code can be simplified e.g. by using generics. Additionally the test failure output was improved and a test for the constructors of CertPathBuilderException was added.

This pull request has now been integrated.

Changeset: d4376f8b
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4376f8b55391485365797d1c4d0dbbc6ed2ad92
Stats:     179 lines in 1 file changed: 11 ins; 149 del; 19 mod

8296406: ChainingConstructors jtreg test reduce code duplication

Reviewed-by: mullan

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

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


From duke at openjdk.org  Wed Nov  9 14:31:29 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 9 Nov 2022 14:31:29 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v4]
In-Reply-To: <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>
Message-ID: <VA0UpcAvywz5icadjJCuh_I5tcdHuO1Am58oYU6XjU4=.4a6f2379-541e-4ff3-a649-6d260ccda9a5@github.com>

On Thu, 13 Oct 2022 18:15:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> 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/curve25519, [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: No update for Ed448 as using less limbs does not improve the performance for Ed448):
>> 
>> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
>> Signatures.sign    secp256r1               64  thrpt   15  1769.262 ?  4.251  ops/s
>> Signatures.sign    secp256r1              512  thrpt   15  1764.754 ? 12.185  ops/s
>> Signatures.sign    secp256r1             2048  thrpt   15  1737.499 ? 43.937  ops/s
>> Signatures.sign    secp256r1            16384  thrpt   15  1733.932 ?  7.938  ops/s
>> Signatures.sign    secp384r1               64  thrpt   15   636.614 ?  6.752  ops/s
>> Signatures.sign    secp384r1              512  thrpt   15   629.449 ?  8.000  ops/s
>> Signatures.sign    secp384r1             2048  thrpt   15   645.898 ?  5.655  ops/s
>> Signatures.sign    secp384r1            16384  thrpt   15   634.530 ? 11.846  ops/s
>> Signatures.sign    secp521r1               64  thrpt   15   334.413 ?  6.710  ops/s
>> Signatures.sign    secp521r1              512  thrpt   15   335.088 ?  6.630  ops/s
>> Signatures.sign    secp521r1             2048  thrpt   15   339.729 ?  1.450  ops/s
>> Signatures.sign    secp521r1            16384  thrpt   15   327.597 ?  2.341  ops/s
>> Signatures.sign      Ed25519               64  thrpt   15  1361.028 ?  2.338  ops/s
>> Signatures.sign      Ed25519              512  thrpt   15  1359.072 ?  3.748  ops/s
>> Signatures.sign      Ed25519             2048  thrpt   15  1347.409 ?  9.172  ops/s
>> Signatures.sign      Ed25519            16384  thrpt   15  1250.794 ? 11.750  ops/s
>> Signatures.sign        Ed448               64  thrpt   15   321.312 ?  5.826  ops/s
>> Signatures.sign        Ed448              512  thrpt   15   326.592 ?  4.213  ops/s
>> Signatures.sign        Ed448             2048  thrpt   15   322.183 ?  7.005  ops/s
>> Signatures.sign        Ed448            16384  thrpt   15   299.869 ? 16.594  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

The way I see it is this: as limbs are 64-bit wide, the only place where they can possibly overflow (during the computations they are used for) is the multiplication (including multiply by int and squaring). So I would first try to change the mult() and square() methods only in IntegerPolynomialP256.java (well, in the generator that creates it). 
 (It would also be nice to add comments to the various carry/reduce methods that explain what exactly they want to achieve -- although this is definitely something that doesn't have to be in this change set.)
I also think (agree with you) that the setReduced() method can be eliminated if you reduce the multiplicands conditionally (if numAdds > maxAdds) before the multiplication/squaring and unconditionally after it (this part is done in the generated functions already). But that assumes you change all subclasses of IntegerPolynomial that way (most conveniently in the set[Product,Square]() methods).

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

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


From coffeys at openjdk.org  Wed Nov  9 15:50:50 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 9 Nov 2022 15:50:50 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v6]
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: <0VY3Sv6D_4EN3R3cgc5__2XU_zOA-3v638rwyLwrG2I=.36792683-0ae1-41d3-9d25-c5a79e997e4b@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:

  Don't record certs directly from CertAndGen/keytool

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10422/files
  - new: https://git.openjdk.org/jdk/pull/10422/files/e3635647..dda445fd

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

  Stats: 34 lines in 3 files changed: 1 ins; 28 del; 5 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  Wed Nov  9 15:52:25 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 9 Nov 2022 15:52:25 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v5]
In-Reply-To: <mVO-5Kl3kqBI7ySyCC03Zt32On-5XrHgPaMHllLhDeo=.9bf40963-129a-48bc-8d94-64f9ae3e8bbb@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <nNRUMHWFV-vlqOAlqxTfPUwMU1C9QtlqyiryyB4hM3Y=.e29af3f2-db9d-40fe-a77a-b8acf4026faf@github.com>
 <mVO-5Kl3kqBI7ySyCC03Zt32On-5XrHgPaMHllLhDeo=.9bf40963-129a-48bc-8d94-64f9ae3e8bbb@github.com>
Message-ID: <KoSTBMg_QeQo_sTpbMEzQ_GOAVqqruW8v8fzIzxNreg=.b389ac4e-104a-4fe5-8005-223e1b52e3a4@github.com>

On Tue, 8 Nov 2022 16:22:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > 
> 
> My vote would be to leave it out. `keytool` already emits warnings when weak algorithms are used. It seems we both agree that few users, will likely enable JFR on `keytool`. We could always add these events later, but it is harder to remove them once they are in there.

I'm fine with that suggestion Sean. I've removed the event form the CertAndGen class. Turns out that the keytool will load the new cert via the standard `CertificateFactory.generateCertificate` call at a later stage anyhow! [1]

Tests modified also to capture this.

[1]

jdk.X509Certificate {
  startTime = 11:36:48.208 (2022-11-09)
  algorithm = "SHA384withRSA"
  serialNumber = "fe9b213c1345aadd"
  subject = "CN=8292033.oracle.com, OU=JPG, C=US"
  issuer = "CN=8292033.oracle.com, OU=JPG, C=US"
  keyType = "RSA"
  keyLength = 2048
  certificateId = -749360774
  validFrom = 11:36:48.000 (2022-11-09)
  validUntil = 11:36:48.000 (2023-11-09)
  eventThread = "main" (javaThreadId = 1)
  stackTrace = [
    sun.security.jca.JCAUtil.tryCommitCertEvent(Certificate) line: 126
    java.security.cert.CertificateFactory.generateCertificate(InputStream) line: 356
    sun.security.pkcs12.PKCS12KeyStore.loadSafeContents(DerInputStream) line: 2428
    sun.security.pkcs12.PKCS12KeyStore.lambda$engineLoad$1(AlgorithmParameters, byte[], char[]) line: 2127
    sun.security.pkcs12.PKCS12KeyStore$RetryWithZero.run(PKCS12KeyStore$RetryWithZero, char[]) line: 257
    sun.security.pkcs12.PKCS12KeyStore.engineLoad(InputStream, char[]) line: 2118
    sun.security.util.KeyStoreDelegator.engineLoad(InputStream, char[]) line: 228
    java.security.KeyStore.load(InputStream, char[]) line: 1500
    java.security.KeyStore.getInstance(File, char[], KeyStore$LoadStoreParameter, boolean) line: 1828
    java.security.KeyStore.getInstance(File, char[]) line: 1709
    sun.security.tools.keytool.Main.doCommands(PrintStream) line: 1390
    sun.security.tools.keytool.Main.run(String[], PrintStream) line: 419
    sun.security.tools.keytool.Main.main(String[]) line: 412

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

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


From jbhateja at openjdk.org  Wed Nov  9 15:59:27 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 9 Nov 2022 15:59:27 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
Message-ID: <jzdvvRS7lq0nJaImLvNtUm10ME5ZG5zIJlv6hZBe9oE=.9129c20d-5222-49f9-ac3f-bfa6142f4ce8@github.com>

On Tue, 8 Nov 2022 23:21:58 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix 32-bit build

src/hotspot/cpu/x86/vm_version_x86.cpp line 1181:

> 1179: #ifdef _LP64
> 1180:   if (supports_avx512ifma() & supports_avx512vlbw()) {
> 1181:     if (FLAG_IS_DEFAULT(UsePolyIntrinsics)) {

MaxVectorSize > 32 can be added along with feature checks your code mainly uses ZMMs

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

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


From weijun at openjdk.org  Wed Nov  9 16:09:54 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 16:09:54 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests
Message-ID: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>

The NSS tests do not work fine on linux-aarch64 now. Disable them at the moment.

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

Commit messages:
 - the fix

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

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


From weijun at openjdk.org  Wed Nov  9 16:09:54 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 16:09:54 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests
In-Reply-To: <nD-DdIKBh-A4aj1mvBWq4pC1kXSVM5noBy5G_w4aA1U=.51d07bec-35cc-43d2-8e0e-f59505381126@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
 <nD-DdIKBh-A4aj1mvBWq4pC1kXSVM5noBy5G_w4aA1U=.51d07bec-35cc-43d2-8e0e-f59505381126@github.com>
Message-ID: <cXh5_9IoIQRIUacSi9YoO4BwUKirYWCNqTNDzvxJDOM=.e3897404-6d6f-4322-8146-7d2e79d3d4db@github.com>

On Wed, 9 Nov 2022 16:03:16 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Do we know if these tests will also fail on linux-x64 OL9?

For linux-x64, we use libraries from the artifact server and they succeed on OL9.

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

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


From dcubed at openjdk.org  Wed Nov  9 16:09:54 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 9 Nov 2022 16:09:54 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests
In-Reply-To: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
Message-ID: <nD-DdIKBh-A4aj1mvBWq4pC1kXSVM5noBy5G_w4aA1U=.51d07bec-35cc-43d2-8e0e-f59505381126@github.com>

On Wed, 9 Nov 2022 16:01:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The NSS tests do not work fine on linux-aarch64 now. Disable them at the moment.

Thumbs up. This is a trivial fix.

Do we know if these tests will also fail on linux-x64 OL9?

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

Marked as reviewed by dcubed (Reviewer).

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


From mullan at openjdk.org  Wed Nov  9 16:15:31 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 9 Nov 2022 16:15:31 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests
In-Reply-To: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
Message-ID: <ZGUmtB3mbhyo1dkQzvu7ELzP66q9P6eVC0q2H8wMTAA=.4c252117-f042-4b55-b4bb-465f7bf18a61@github.com>

On Wed, 9 Nov 2022 16:01:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The NSS tests do not work fine on linux-aarch64 now. Disable them at the moment.

I guess it's not possible to ProblemList an OS/arch combo?

test/jdk/sun/security/pkcs11/PKCS11Test.java line 703:

> 701:                 "/usr/lib/arm-linux-gnueabi/nss/",
> 702:                 "/usr/lib/arm-linux-gnueabihf/nss/" });
> 703: //        osMap.put("Linux-aarch64-64", new String[] {

Perhaps add a comment above this noting why these are being excluded. Could include the bugid for now until it is fixed.

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

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


From weijun at openjdk.org  Wed Nov  9 16:18:20 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 16:18:20 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests
In-Reply-To: <ZGUmtB3mbhyo1dkQzvu7ELzP66q9P6eVC0q2H8wMTAA=.4c252117-f042-4b55-b4bb-465f7bf18a61@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
 <ZGUmtB3mbhyo1dkQzvu7ELzP66q9P6eVC0q2H8wMTAA=.4c252117-f042-4b55-b4bb-465f7bf18a61@github.com>
Message-ID: <mCzqhCAUQz3yiDpaFRM8xin4wR6FfjncVQp5lPiYUVY=.2a161a7f-49e7-4c89-95a9-4e6a3200d96a@github.com>

On Wed, 9 Nov 2022 16:09:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I guess it's not possible to ProblemList an OS/arch combo?

Yes, we can, but there are quite a lot of tests failing here.

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

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


From weijun at openjdk.org  Wed Nov  9 16:24:21 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 16:24:21 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests [v2]
In-Reply-To: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
Message-ID: <HfXdlMEjjzwUaQutenDRODyPHL92A0HFvBWngcYO134=.60291e5a-6541-44cd-b71d-16fc2ba83482@github.com>

> The NSS tests do not work fine on linux-aarch64 now. Disable them at the moment.

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

  add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11063/files
  - new: https://git.openjdk.org/jdk/pull/11063/files/4126608e..ebba8e7a

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

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

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


From weijun at openjdk.org  Wed Nov  9 16:24:23 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 16:24:23 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests [v2]
In-Reply-To: <ZGUmtB3mbhyo1dkQzvu7ELzP66q9P6eVC0q2H8wMTAA=.4c252117-f042-4b55-b4bb-465f7bf18a61@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
 <ZGUmtB3mbhyo1dkQzvu7ELzP66q9P6eVC0q2H8wMTAA=.4c252117-f042-4b55-b4bb-465f7bf18a61@github.com>
Message-ID: <26TWIZonWewQUwYf9hoCYQriTdXyy4Ln27aE19VgvKw=.93bf5514-0abb-417c-b14c-b118811bb27b@github.com>

On Wed, 9 Nov 2022 16:11:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comment
>
> test/jdk/sun/security/pkcs11/PKCS11Test.java line 703:
> 
>> 701:                 "/usr/lib/arm-linux-gnueabi/nss/",
>> 702:                 "/usr/lib/arm-linux-gnueabihf/nss/" });
>> 703: //        osMap.put("Linux-aarch64-64", new String[] {
> 
> Perhaps add a comment above this noting why these are being excluded. Could include the bugid for now until it is fixed.

Done.

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

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


From mullan at openjdk.org  Wed Nov  9 16:34:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 9 Nov 2022 16:34:46 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests [v2]
In-Reply-To: <HfXdlMEjjzwUaQutenDRODyPHL92A0HFvBWngcYO134=.60291e5a-6541-44cd-b71d-16fc2ba83482@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
 <HfXdlMEjjzwUaQutenDRODyPHL92A0HFvBWngcYO134=.60291e5a-6541-44cd-b71d-16fc2ba83482@github.com>
Message-ID: <ddMlYSy3vnYd3tgrlTjRzy6oT6xgii5th10BGdUFtyE=.e753c8d4-f1df-4db9-96ce-2bfa0984b3bb@github.com>

On Wed, 9 Nov 2022 16:24:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The NSS tests do not work fine on linux-aarch64 now. Disable them at the moment.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

Bug needs `noreg-self` label. Otherwise, looks good.

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

Marked as reviewed by mullan (Reviewer).

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


From mullan at openjdk.org  Wed Nov  9 16:34:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 9 Nov 2022 16:34:46 GMT
Subject: RFR: 8296675: Exclude linux-aarch64 in NSS tests
In-Reply-To: <mCzqhCAUQz3yiDpaFRM8xin4wR6FfjncVQp5lPiYUVY=.2a161a7f-49e7-4c89-95a9-4e6a3200d96a@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
 <ZGUmtB3mbhyo1dkQzvu7ELzP66q9P6eVC0q2H8wMTAA=.4c252117-f042-4b55-b4bb-465f7bf18a61@github.com>
 <mCzqhCAUQz3yiDpaFRM8xin4wR6FfjncVQp5lPiYUVY=.2a161a7f-49e7-4c89-95a9-4e6a3200d96a@github.com>
Message-ID: <VtI3s9fXCmTFRxRQL7glFwKLNbJ2_wWrjqzS2Jws64I=.82c01353-dc28-4752-b28a-cec2d42f4ff5@github.com>

On Wed, 9 Nov 2022 16:15:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > I guess it's not possible to ProblemList an OS/arch combo?
> 
> Yes, we can, but there are quite a lot of tests failing here.

Seems fine then.

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

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


From xuelei at openjdk.org  Wed Nov  9 16:42:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 9 Nov 2022 16:42:27 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v4]
In-Reply-To: <VA0UpcAvywz5icadjJCuh_I5tcdHuO1Am58oYU6XjU4=.4a6f2379-541e-4ff3-a649-6d260ccda9a5@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>
 <VA0UpcAvywz5icadjJCuh_I5tcdHuO1Am58oYU6XjU4=.4a6f2379-541e-4ff3-a649-6d260ccda9a5@github.com>
Message-ID: <MfxjLBJ-6T4hIOwPO5ZfjImmIPQ1t7dky89q15qkslg=.0a8700ec-6353-4722-8af6-b5a6bb0a77cf@github.com>

On Wed, 9 Nov 2022 14:27:26 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> The way I see it is this: as limbs are 64-bit wide, the only place where they can possibly overflow (during the computations they are used for) is the multiplication (including multiply by int and squaring). So I would first try to change the mult() and square() methods only in IntegerPolynomialP256.java (well, in the generator that creates it).

I agreed.  The addition and subtraction operations are limited as well.  Each limb cannot exceed 32 bits, otherwise the carry/reduce may not work as far as I can see.   It would be good the addition and subtraction was placed in IntegerPolynomialP256.java as well.  Otherwise, we have to check the the limits in the caller level, which is error-prone.

I will think about how to make this suggestion right.  It may be another PR for the restructure.

> (It would also be nice to add comments to the various carry/reduce methods that explain what exactly they want to achieve -- although this is definitely something that doesn't have to be in this change set.)

Yes, there are not much comment in the current code and hard to get the ideas.  I will see if I can add more in another PR.

> I also think (agree with you) that the setReduced() method can be eliminated if you reduce the multiplicands conditionally (if numAdds > maxAdds) before the multiplication/squaring and unconditionally after it (this part is done in the generated functions already). But that assumes you change all subclasses of IntegerPolynomial that way (most conveniently in the setProduct,Square methods).

The plan is to change all curves (curve448 may be an exception, but I still investigate on it.  I can see performance improvement for other curves).

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

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


From mseledtsov at openjdk.org  Wed Nov  9 16:48:31 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 9 Nov 2022 16:48:31 GMT
Subject: RFR: 8296611: Problemlist several sun/security and java/security tests
 until JDK-8295343 is resolved
Message-ID: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>

Trivial change, updated jdk problem list.

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

Commit messages:
 - Using linux-all since the same issue on aarch64
 - 8296611: Problemlist several sun/security and java/security tests until JDK-8295343 is resolved

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

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


From mseledtsov at openjdk.org  Wed Nov  9 16:48:32 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 9 Nov 2022 16:48:32 GMT
Subject: RFR: 8296611: Problemlist several sun/security and java/security
 tests until JDK-8295343 is resolved
In-Reply-To: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
Message-ID: <Do6odU9DfiqG-sA6w71oJ8jOT6tDKUutUeQcVLnzkpw=.1ad2975e-8703-4d28-bc70-91500dab5007@github.com>

On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Trivial change, updated jdk problem list.

@dcubed-ojdk Dan, could you please review this problem listing change ?

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

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


From weijun at openjdk.org  Wed Nov  9 16:51:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 16:51:47 GMT
Subject: Integrated: 8296675: Exclude linux-aarch64 in NSS tests
In-Reply-To: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
References: <sG_hq4LdtYqqj0x1nrJcHagFvrJNjG_tKzrqp3DPdCA=.f2a46366-429a-4696-b626-360dfb156a2d@github.com>
Message-ID: <1ZL8Tc_O0QxSApZfyJI5_x78pMQQP_Sa0MUDXOpXpGY=.fe33938b-d24b-45f7-8e7c-a3da547965e5@github.com>

On Wed, 9 Nov 2022 16:01:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The NSS tests do not work fine on linux-aarch64 now. Disable them at the moment.

This pull request has now been integrated.

Changeset: fa8a8668
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa8a8668a6656046d713a6b09244adfc81556d63
Stats:     7 lines in 1 file changed: 2 ins; 0 del; 5 mod

8296675: Exclude linux-aarch64 in NSS tests

Reviewed-by: dcubed, mullan

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

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


From mullan at openjdk.org  Wed Nov  9 17:01:32 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 9 Nov 2022 17:01:32 GMT
Subject: RFR: 8296611: Problemlist several sun/security and java/security
 tests until JDK-8295343 is resolved
In-Reply-To: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
Message-ID: <Qt5tlMItcCLu87PWxPvOKqX1XDe4ayhfLpEBGrN44c0=.68352353-18da-46bd-943e-9b0d90cde800@github.com>

On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Trivial change, updated jdk problem list.

The `java/security/cert/pkix/policyChanges/TestPolicy.java`  and `java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java` test failures are already fixed. There is no need to ProblemList them.

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

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


From mseledtsov at openjdk.org  Wed Nov  9 17:36:12 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 9 Nov 2022 17:36:12 GMT
Subject: RFR: 8296611: Problemlist several sun/security and java/security
 tests until JDK-8295343 is resolved [v2]
In-Reply-To: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
Message-ID: <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>

> Trivial change, updated jdk problem list.

Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11045/files
  - new: https://git.openjdk.org/jdk/pull/11045/files/8834f40e..54faacf5

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

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

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


From mseledtsov at openjdk.org  Wed Nov  9 17:36:14 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 9 Nov 2022 17:36:14 GMT
Subject: RFR: 8296611: Problemlist several sun/security and java/security
 tests until JDK-8295343 is resolved
In-Reply-To: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
Message-ID: <CxwwQN2AbgUSjAXbdGVK6OWSWxrvJgkenRpjauTAhAA=.3ba0270f-7510-4207-829e-0bb3aec5092a@github.com>

On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Trivial change, updated jdk problem list.

Thanks Sean. I will remove the fixed tests from the list.

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

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


From xuelei at openjdk.org  Wed Nov  9 17:38:41 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 9 Nov 2022 17:38:41 GMT
Subject: Integrated: 8296591: Signature benchmark
In-Reply-To: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
Message-ID: <eQjUTKt2HBWOaPnBPOkUdnEFBEtkoRNBtw1wvA7w8s8=.1208eb25-c4be-4674-b15e-e8b4a04618d4@github.com>

On Tue, 8 Nov 2022 18:38:59 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the micro-benchmark code reviewed for EC signature algorithms?  The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

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

8296591: Signature benchmark

Reviewed-by: weijun

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

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


From duke at openjdk.org  Wed Nov  9 17:53:21 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 17:53:21 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
 <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
Message-ID: <68kLqa_FyCKuyBqSpXlq_1QnR8I-HFL1aFr4uQ6DyoM=.817059a2-8945-44e7-9ce8-a5f5ee5a50c5@github.com>

On Wed, 9 Nov 2022 00:10:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix 32-bit build
>
> src/hotspot/share/opto/library_call.cpp line 7014:
> 
>> 7012:   const TypeKlassPtr* rklass = TypeKlassPtr::make(instklass_ImmutableElement);
>> 7013:   const TypeOopPtr* rtype = rklass->as_instance_type()->cast_to_ptr_type(TypePtr::NotNull);
>> 7014:   Node* rObj = new CheckCastPPNode(control(), rFace, rtype);
> 
> FTR it's an unsafe cast since it  doesn't involve a runtime check from `IntegerModuloP` to `ImmutableElement`. Please, lift as much checks into Java wrapper as possible.

@iwanowww just to save some of your time...  Sandhya suggested another way to move the checks to Java, hopefully without too much penalty to non-intrinsic path. Should upload it later today.

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

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


From xuelei at openjdk.org  Wed Nov  9 18:31:37 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 9 Nov 2022 18:31:37 GMT
Subject: RFR: 8293886: The abstract keyword can be removed in AESCipher
In-Reply-To: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
References: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
Message-ID: <ZdNotxkszvnKkAsYrB3abh3A-RMpFuUHUY75s-udJQA=.3691ddad-2476-40c4-8bc3-8dc02eb56740@github.com>

On Fri, 16 Sep 2022 00:27:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this simple fix for readability.
> 
> In the AES cipher implementation, the AESCipher class is defined as abstract.  As is not necessary as there is no abstract method in this class. Code reader may try to search for abstract methods if the abstract keyword is present.
> 
> BTW, I also added Override tags and make a few other cleanup, for example adding the 'final' keywords.
> 
> Thanks,
> Xuelei

ping ...

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

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


From xuelei at openjdk.org  Wed Nov  9 19:15:36 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 9 Nov 2022 19:15:36 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v4]
In-Reply-To: <MfxjLBJ-6T4hIOwPO5ZfjImmIPQ1t7dky89q15qkslg=.0a8700ec-6353-4722-8af6-b5a6bb0a77cf@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>
 <VA0UpcAvywz5icadjJCuh_I5tcdHuO1Am58oYU6XjU4=.4a6f2379-541e-4ff3-a649-6d260ccda9a5@github.com>
 <MfxjLBJ-6T4hIOwPO5ZfjImmIPQ1t7dky89q15qkslg=.0a8700ec-6353-4722-8af6-b5a6bb0a77cf@github.com>
Message-ID: <KCmXBhn1_5_IgEl0QwFAqIJ1jxMsCC8utwOR2Swl2vo=.6d378c5e-2e8f-4837-b469-bffade2b9101@github.com>

On Wed, 9 Nov 2022 16:38:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > The way I see it is this: as limbs are 64-bit wide, the only place where they can possibly overflow (during the computations they are used for) is the multiplication (including multiply by int and squaring). So I would first try to change the mult() and square() methods only in IntegerPolynomialP256.java (well, in the generator that creates it).
> 
> I agreed. The addition and subtraction operations are limited as well. Each limb cannot exceed 32 bits, otherwise the carry/reduce may not work as far as I can see. It would be good the addition and subtraction was placed in IntegerPolynomialP256.java as well. Otherwise, we have to check the the limits in the caller level, which is error-prone.
> 
> I will think about how to make this suggestion right. It may be another PR for the restructure.
> 

I had a further look at the current code structure.  The addition counter status is maintained in the caller level (IntegerPolynomial.java).  It is possible to re-org the code (the generator), but we may not like the scale of the update. It may not be the purpose of this update. I would like to defer to a separated PR later and keep this PR focus on performance improvement.

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

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


From weijun at openjdk.org  Wed Nov  9 20:09:20 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 20:09:20 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
Message-ID: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>

An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.

Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.

No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11067/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296442
  Stats: 131 lines in 5 files changed: 97 ins; 12 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11067.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11067/head:pull/11067

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


From weijun at openjdk.org  Wed Nov  9 20:19:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 20:19:11 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
Message-ID: <tgrDSays7U99ZTFFFBh4a7t_f4ByqZPLeiL19A-MjOE=.b9950f5a-4766-462f-9dc3-a78d6305cab6@github.com>

On Wed, 9 Nov 2022 19:59:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
> 
> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
> 
> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 423:

> 421:             // wrap everything into a SEQUENCE
> 422:             out.write(DerValue.tag_Sequence, tmp);
> 423:             return out.toByteArray();

I'd rather not cache the encoding. First, the cache makes the class mutable. Second, `getEncode` should usually only be called once and the cache is not so useful. Third, this avoids an unnecessary clone (on the line below).

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

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


From coffeys at openjdk.org  Wed Nov  9 21:14:08 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 9 Nov 2022 21:14:08 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v7]
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: <3gyy4itUwNLhaoFXauWPhpyOUvCk4d1l5XlWhbwFKtw=.9595ec88-1cc0-4a9b-8e61-5128a87daf3e@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 26 commits:

 - revert recording events in keytool
 - Merge with master
 - Merge branch 'master' into 8292033-x509Event
 - Don't record certs directly from CertAndGen/keytool
 - Further code review comments and new keytool test coverage with JFR
 - code clean up
 - funnel cert events via generateCertificate only
 - Revert use of x509 constructor helper in some areas. Clean up tests
 - modules fix up in test
 - Capture CertAndKeyGen certs
 - ... and 16 more: https://git.openjdk.org/jdk/compare/d4376f8b...d6faa84a

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

Changes: https://git.openjdk.org/jdk/pull/10422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10422&range=06
  Stats: 237 lines in 12 files changed: 151 ins; 53 del; 33 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 mullan at openjdk.org  Wed Nov  9 21:28:32 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 9 Nov 2022 21:28:32 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
 [v7]
In-Reply-To: <3gyy4itUwNLhaoFXauWPhpyOUvCk4d1l5XlWhbwFKtw=.9595ec88-1cc0-4a9b-8e61-5128a87daf3e@github.com>
References: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>
 <3gyy4itUwNLhaoFXauWPhpyOUvCk4d1l5XlWhbwFKtw=.9595ec88-1cc0-4a9b-8e61-5128a87daf3e@github.com>
Message-ID: <Zpb5Ss66dw0RQqZRBCv3Ey6q02LIr-MyT3hWAMVo9cc=.c0c1e54d-233c-437c-aa5c-fafc2e817ab9@github.com>

On Wed, 9 Nov 2022 21:14:08 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 26 commits:
> 
>  - revert recording events in keytool
>  - Merge with master
>  - Merge branch 'master' into 8292033-x509Event
>  - Don't record certs directly from CertAndGen/keytool
>  - Further code review comments and new keytool test coverage with JFR
>  - code clean up
>  - funnel cert events via generateCertificate only
>  - Revert use of x509 constructor helper in some areas. Clean up tests
>  - modules fix up in test
>  - Capture CertAndKeyGen certs
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/d4376f8b...d6faa84a

Marked as reviewed by mullan (Reviewer).

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

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


From duke at openjdk.org  Wed Nov  9 21:48:59 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 21:48:59 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v10]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <evP4X-nr21v4n0RcBZNOTast7N2BH82V3qfekaSCFP0=.dbe1d26e-1950-4c5d-8a0e-85a0a85c8aa8@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

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  add getLimbs to interface and reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/da560452..8b1b40f7

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

  Stats: 235 lines in 11 files changed: 103 ins; 79 del; 53 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  Wed Nov  9 21:49:09 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 21:49:09 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
 <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
Message-ID: <Q_0DbDYDLyHauXZO42I4-XZq0gig6-cSGDKNpN4qQWU=.afa82e7b-1ab9-4214-a1db-2bf8d7958d41@github.com>

On Wed, 9 Nov 2022 00:23:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix 32-bit build
>
> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 970:
> 
>> 968: 
>> 969:   void addmq(int disp, Register r1, Register r2);
>> 970: 
> 
> Leftover formatting changes.

done

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 95:
> 
>> 93: 
>> 94:   // OFFSET 64: mask_44
>> 95:   0xfffffffffff, 0xfffffffffff,
> 
> Please, keep leading zeroes explicit in the constants.

done. Also split things up and added ExternalAddress version of instructions.

> src/hotspot/cpu/x86/stubRoutines_x86.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2013, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> No changes in the file anymore.

done

> src/hotspot/share/opto/library_call.cpp line 7014:
> 
>> 7012:   const TypeKlassPtr* rklass = TypeKlassPtr::make(instklass_ImmutableElement);
>> 7013:   const TypeOopPtr* rtype = rklass->as_instance_type()->cast_to_ptr_type(TypePtr::NotNull);
>> 7014:   Node* rObj = new CheckCastPPNode(control(), rFace, rtype);
> 
> FTR it's an unsafe cast since it  doesn't involve a runtime check from `IntegerModuloP` to `ImmutableElement`. Please, lift as much checks into Java wrapper as possible.

@iwanowww Please have a look, just pushed a different way to fetch the limbs.

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

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


From duke at openjdk.org  Wed Nov  9 21:49:10 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 21:49:10 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <jzdvvRS7lq0nJaImLvNtUm10ME5ZG5zIJlv6hZBe9oE=.9129c20d-5222-49f9-ac3f-bfa6142f4ce8@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
 <jzdvvRS7lq0nJaImLvNtUm10ME5ZG5zIJlv6hZBe9oE=.9129c20d-5222-49f9-ac3f-bfa6142f4ce8@github.com>
Message-ID: <o7sZchJ_G720V14ob7l7gSAdxajqZR8yOl6B-aJ202U=.13bfb649-ff67-432c-929f-e0e4e5812d90@github.com>

On Wed, 9 Nov 2022 15:55:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix 32-bit build
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1181:
> 
>> 1179: #ifdef _LP64
>> 1180:   if (supports_avx512ifma() & supports_avx512vlbw()) {
>> 1181:     if (FLAG_IS_DEFAULT(UsePolyIntrinsics)) {
> 
> MaxVectorSize > 32 can be added along with feature checks your code mainly uses ZMMs

done (`MaxVectorSize >= 64`)

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

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


From coffeys at openjdk.org  Wed Nov  9 21:49:46 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 9 Nov 2022 21:49:46 GMT
Subject: Integrated: 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: <kbLomYVO_mj5U7tivhrMaLRvxtUJNipIIzHBOiGx0kk=.69c1097e-4c38-4a02-8106-370c0fe611c0@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

This pull request has now been integrated.

Changeset: 102b2b32
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/102b2b32feec4727145be4814eb1a69ef462ff16
Stats:     237 lines in 12 files changed: 151 ins; 53 del; 33 mod

8292033: Move jdk.X509Certificate event logic to JCA layer

Reviewed-by: mullan

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

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


From ascarpino at openjdk.org  Wed Nov  9 21:49:46 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 9 Nov 2022 21:49:46 GMT
Subject: RFR: 8293886: The abstract keyword can be removed in AESCipher
In-Reply-To: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
References: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
Message-ID: <iFX8RYI67zvycNDquhW5MKNzSeXl-vRJSEV4KM6LvQI=.2270820a-071a-4df0-9f71-bac64d338192@github.com>

On Fri, 16 Sep 2022 00:27:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this simple fix for readability.
> 
> In the AES cipher implementation, the AESCipher class is defined as abstract.  As is not necessary as there is no abstract method in this class. Code reader may try to search for abstract methods if the abstract keyword is present.
> 
> BTW, I also added Override tags and make a few other cleanup, for example adding the 'final' keywords.
> 
> Thanks,
> Xuelei

The change looks fine

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

Marked as reviewed by ascarpino (Reviewer).

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


From duke at openjdk.org  Wed Nov  9 21:57:46 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 21:57:46 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v9]
In-Reply-To: <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <Okq3ER5gNRyGhWX8ZRWmxDr0hyzs0DJ15EHul8xoloA=.6c7980ce-89da-4efa-80af-83e1da66945b@github.com>
 <cqMESA9bq6nErMs9ckafTqczQEz33XgEVax014m0hTM=.26c6bdfe-afb6-4406-941b-fc2ce1030389@github.com>
Message-ID: <9VOSld7kTyK9X5jTVkY2Dm_7CVOdZlHzOcoXSF8iLG4=.0fb02250-253e-4c1a-9c4e-b7e147c3e2b2@github.com>

On Tue, 8 Nov 2022 23:59:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix 32-bit build
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 175:
> 
>> 173: 
>> 174:         int blockMultipleLength = len & (~(BLOCK_LENGTH-1));
>> 175:         Objects.checkFromIndexSize(offset, blockMultipleLength, input.length);
> 
> I suggest to move the checks into `processMultipleBlocks`, introduce new static helper method specifically for the intrinsic part, and lift more logic (e.g., field loads) from the intrinsic into Java code.
> 
> As an additional step, you can switch to double-register addressing mode (base + offset) for input data (`input`, `alimbs`, `rlimbs`) and simplify the intrinsic part even more (will involve a switch from `array_element_address` to `make_unsafe_address`).

`array_element_address` vs `make_unsafe_address`. Don't know that I understood.. but going to guess :)
"It might be cleaner to encode base+offset into the instruction opcode, save some `lea`s" 

I think that ship has 'sailed'?
- `input`: I went and removed `offset` from intrinsic stub parameter list and instead passed it to `array_element_address`. But also, because I was really running out of GPRs, I had to do a `lea` before that at the function entry. Can't keep the offset register free for encoding..
- `alimbs`: offset already 0. Also, I mostly keep the actual value `a2:a1:a0` around. Just need address to write result back out.
- `rlimbs`: offset already 0 and address itself discarded right after loading the R value into 2 GPRs.

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

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


From duke at openjdk.org  Wed Nov  9 22:00:40 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 9 Nov 2022 22:00:40 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v6]
In-Reply-To: <EsOqIOc_ALMLS4KMPlFF7-_NDw8AkVUlla194C8zERY=.699e46f8-7c6c-4f4e-95d3-04ad0e3d13e2@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <hX0rCTuGOWiCCGiKC7anEoiNosHutI1kiWb9Z-plUSY=.d7a8c833-f3dd-4f3a-98bf-1975109de48c@github.com>
 <lyp-yeLzhgxWaDGBB7GvJPgtMn5u_1k823-GZLIZPKM=.fbdc9545-5e30-4919-880c-f377b13d31ee@github.com>
 <xVrQBy6-ShiXGeObsxEoYonfCQ8r7f7VebUjJI1zP64=.5ffcb66d-5662-4fd0-8b51-7ca621a69757@github.com>
 <hFUaLY8cUCfXRbJCKtDcefgrwZvl2X53q1QPVUEosqc=.7980aa45-d193-49cc-b3f1-15a8eb45576e@github.com>
 <asa1G1rY6oVsgFHuXITPmNXCuryU8b5vJRNj8RMnZng=.f5f4e431-48c2-4896-998a-fb418992b581@github.com>
 <EsOqIOc_ALMLS4KMPlFF7-_NDw8AkVUlla194C8zERY=.699e46f8-7c6c-4f4e-95d3-04ad0e3d13e2@github.com>
Message-ID: <k88mxyScYuDY8wmwiPM0Ey8o97ayPq-1qZvdXpRxei8=.b5e6c854-6669-4ee8-a6b8-212da546a672@github.com>

On Wed, 9 Nov 2022 02:19:29 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>>> Did not split it up into individual constants. The main 'problem' is that Address and ExternalAddress are not compatible. 
>> 
>> There's a reason for that and it's because RIP-relative addressing doesn't always work, so additional register may be needed.
>> 
>>> Most instructions do not take AddressLiteral, so can't use ExternalAddress to refer to those constants. 
>> 
>> I counted 4 instructions accessing the constants (`evpandq`, `andq`, `evporq`, and `vpternlogq`) in your patch. 
>> 
>> `macroAssembler_x86.hpp` is the place for `AddressLiteral`-related overloads (there are already numerous cases present) and it's trivial to add new ones. 
>> 
>>> (If I did get the instructions I use to take AddressLiteral, I think we would end up with more lea(rscratch)s generated; but that's more of a silver-lining)
>> 
>> It depends on memory layout. If constants end up placed close enough in the address space, there'll be no additional instructions generated.
>> 
>> Anyway, it doesn't look like something important from throughput perspective. Overall, I find it clearer when the code refers to individual constants through `AddressLiteral`s, but I'm also fine with it as it is now.
>
> Makes sense to me, that would indeed be cleaner, will add a couple more overloads. (Still getting used to what is 'clean' in this code base).

done

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

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


From weijun at openjdk.org  Wed Nov  9 22:02:54 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 22:02:54 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be encoded
Message-ID: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>

One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.

After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.

In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.

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

Commit messages:
 - avoid NPE
 - the fix

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

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


From weijun at openjdk.org  Wed Nov  9 22:38:31 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 22:38:31 GMT
Subject: RFR: 8296741: Illegal X400Address and EDIPartyName should not be
 created
Message-ID: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>

`EDIPartyName` should not have a null `partyName`.

Inside `X400Name` it should be a `DerValue` instead of arbitrary byte array. Note: in `GeneralSubtrees.java`, an `X400Name` is created with a null content. This would lead to an NPE anyway. A future fix might be needed.

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

Commit messages:
 - the fix

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

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


From mseledtsov at openjdk.org  Wed Nov  9 22:44:49 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 9 Nov 2022 22:44:49 GMT
Subject: RFR: 8296611: Problemlist several sun/security and java/security
 tests until JDK-8295343 is resolved [v2]
In-Reply-To: <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
 <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
Message-ID: <4u_8wPYcvjfXfUVTloEz4ZXev1APLsQ4db4uSIP2Lpk=.c1583cb8-eefc-4e22-a562-6a790d5eee20@github.com>

On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Trivial change, updated jdk problem list.
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review feedback

I have updated the problem list to exclude fixed tests. Please review when you have a chance.

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

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


From weijun at openjdk.org  Wed Nov  9 22:44:59 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Nov 2022 22:44:59 GMT
Subject: RFR: 8296741: Illegal X400Address and EDIPartyName should not be
 created [v2]
In-Reply-To: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
References: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
Message-ID: <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>

> `EDIPartyName` should not have a null `partyName`.
> 
> Inside `X400Name` it should be a `DerValue` instead of arbitrary byte array. Note: in `GeneralSubtrees.java`, an `X400Name` is created with a null content. This would lead to an NPE anyway. A future fix might be needed.

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

  add test
  
  only in patch2:
  unchanged:

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11071/files
  - new: https://git.openjdk.org/jdk/pull/11071/files/6fe354ef..46695903

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

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

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


From rhalade at openjdk.org  Wed Nov  9 23:48:36 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 9 Nov 2022 23:48:36 GMT
Subject: RFR: 8296611: Problemlist several sun/security and java/security
 tests until JDK-8295343 is resolved [v2]
In-Reply-To: <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
 <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
Message-ID: <CF6iG8Wxc5pv2AvG-oBgokY9ESo5CVpfV1k8rmo78Mc=.05e11541-4e48-48da-9208-d25fd206f399@github.com>

On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Trivial change, updated jdk problem list.
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review feedback

Please update the PR commit message in summary. I updated JBS bug summary to indicate only sun/security tests failed.

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

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


From rhalade at openjdk.org  Thu Nov 10 00:10:29 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 10 Nov 2022 00:10:29 GMT
Subject: RFR: 8296611: Problemlist several sun/security tests until
 JDK-8295343 is resolved [v2]
In-Reply-To: <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
 <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
Message-ID: <ICMfahNqZNp_ipkoMT7wiaDj-y9Tx7AGslCENYT145o=.abc5867b-e657-4b1d-99ca-7de8447ea2d1@github.com>

On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Trivial change, updated jdk problem list.
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review feedback

Marked as reviewed by rhalade (Reviewer).

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

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


From wetmore at openjdk.org  Thu Nov 10 00:29:43 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 10 Nov 2022 00:29:43 GMT
Subject: RFR: 8293886: The abstract keyword can be removed in AESCipher
In-Reply-To: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
References: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
Message-ID: <_PKKheNBUbwfD1AW_cwlBybLVKjcCimZ65czDSKZb_g=.a388a55c-41f0-40c0-8e8a-c5142487ef12@github.com>

On Fri, 16 Sep 2022 00:27:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this simple fix for readability.
> 
> In the AES cipher implementation, the AESCipher class is defined as abstract.  As is not necessary as there is no abstract method in this class. Code reader may try to search for abstract methods if the abstract keyword is present.
> 
> BTW, I also added Override tags and make a few other cleanup, for example adding the 'final' keywords.
> 
> Thanks,
> Xuelei

Two minor nits, but otherwise looks good.

src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 61:

> 59:  */
> 60: 
> 61: class AESCipher extends CipherSpi {

If you're doing general cleaning, line 33 import ByteBuffer can go, and there's an extra line in the javadoc at line 53 that could also go.

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

Marked as reviewed by wetmore (Reviewer).

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


From mseledtsov at openjdk.org  Thu Nov 10 00:44:31 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 10 Nov 2022 00:44:31 GMT
Subject: RFR: 8296611: Problemlist several sun/security tests until
 JDK-8295343 is resolved [v2]
In-Reply-To: <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
 <pwmx5i1YPVmRn-brJnT1gsx0KO6LUVbk85BAR5qAJiE=.85f90592-374b-4104-b904-e28ee60656fa@github.com>
Message-ID: <CRF7AQzO5LZwRoqUL4t1bLxyzeDBOlLq1NLSRVlPeIQ=.5cfb2b19-6d44-479a-b3a0-0e4b0ec738b9@github.com>

On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Trivial change, updated jdk problem list.
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review feedback

Thank you Rajan.

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

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


From mseledtsov at openjdk.org  Thu Nov 10 00:48:29 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 10 Nov 2022 00:48:29 GMT
Subject: Integrated: 8296611: Problemlist several sun/security tests until
 JDK-8295343 is resolved
In-Reply-To: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
References: <KskYA18cAxb5jRCJ_bIWIs3xNHXpY5OfQ8p3I3hEXIo=.423d2cfb-0507-47ae-8868-802e59bc2ecf@github.com>
Message-ID: <esIVLU6FQKBIsF8slDa_AllQYUhrqG9CIhE7VKf-YyQ=.fdd1ea4f-f5d6-4018-9d02-cde51c5a07fe@github.com>

On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Trivial change, updated jdk problem list.

This pull request has now been integrated.

Changeset: d6e2d0d0
Author:    Mikhailo Seledtsov <mseledtsov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6e2d0d03d2161f934474fa1d4299513d14cb9c5
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8296611: Problemlist several sun/security tests until JDK-8295343 is resolved

Reviewed-by: rhalade

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

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


From duke at openjdk.org  Thu Nov 10 01:09:26 2022
From: duke at openjdk.org (pandaapo)
Date: Thu, 10 Nov 2022 01:09:26 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in map
Message-ID: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>

The cache named `signerToCodeSource` is never used now.

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

Commit messages:
 - Make signerToCodeSource cache work.

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

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


From jjg at openjdk.org  Thu Nov 10 01:21:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 01:21:09 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
Message-ID: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>

Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.

"Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.

"Normalized" means...
* Use `https:` where possible (includes pretty much all cases)
* Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
* Point to the root page of a multi-page spec
* Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)

In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.

The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.

That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.

Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.

To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/

In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

Commit messages:
 - JDK-8296547: Add @spec tags to API

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

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


From duke at openjdk.org  Thu Nov 10 01:22:04 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 10 Nov 2022 01:22:04 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v11]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <actl_ZA8F_vYPeNjov0QcGklPyBQjm-geVl1rPLtFpU=.c440119c-5b4e-4c98-9a57-4fa36785bcbf@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

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  fix windows and 32b linux builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/8b1b40f7..abfc68f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=09-10

  Stats: 5 lines in 3 files changed: 4 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 duke at openjdk.org  Thu Nov 10 01:26:54 2022
From: duke at openjdk.org (Xubo Zhang)
Date: Thu, 10 Nov 2022 01:26:54 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
Message-ID: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>

NativePRNG SecureRandom doesn?t scale with number of threads. The performance starts dropping as we increase the number of threads. Even going from 1 thread to 2 threads shows significant drop. The bottleneck is the singleton RandomIO instance. Making the RandomIO ThreadLocal helps in removing this bottleneck.

Here are the jmh  thrpt ops/s data for SecureRandomBench.nextBytes, algorithm=NativePRNGNonBlocking, datasize=64, notshared:

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
<link rel=File-List
href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">



</head>

<body link="#0563C1" vlink="#954F72">



#threads | singleton RandomIO | ThreadLocal RandomIO
-- | -- | --
1 | 1269133 | 1279088
2 | 862923 | 1362066
3 | 819734 | 1630522
4 | 809128 | 1614500
5 | 821514 | 1594965
6 | 808795 | 1545045
7 | 783050 | 1499388
8 | 787236 | 1470004



</body>

</html>

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

Commit messages:
 - cleanup
 - removed print statements
 - Initial change with Sandhya's patch

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

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


From xuelei at openjdk.org  Thu Nov 10 01:35:31 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 01:35:31 GMT
Subject: RFR: 8293886: The abstract keyword can be removed in AESCipher
In-Reply-To: <_PKKheNBUbwfD1AW_cwlBybLVKjcCimZ65czDSKZb_g=.a388a55c-41f0-40c0-8e8a-c5142487ef12@github.com>
References: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
 <_PKKheNBUbwfD1AW_cwlBybLVKjcCimZ65czDSKZb_g=.a388a55c-41f0-40c0-8e8a-c5142487ef12@github.com>
Message-ID: <lRcGg2pvGNW5TTSRqKF_OahxZO5R77ACL-c4YEEXUwQ=.dab5f0a3-d227-4811-9839-97371f9907d4@github.com>

On Thu, 10 Nov 2022 00:23:47 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple fix for readability.
>> 
>> In the AES cipher implementation, the AESCipher class is defined as abstract.  As is not necessary as there is no abstract method in this class. Code reader may try to search for abstract methods if the abstract keyword is present.
>> 
>> BTW, I also added Override tags and make a few other cleanup, for example adding the 'final' keywords.
>> 
>> Thanks,
>> Xuelei
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 61:
> 
>> 59:  */
>> 60: 
>> 61: class AESCipher extends CipherSpi {
> 
> If you're doing general cleaning, line 33 import ByteBuffer can go, and there's an extra line in the javadoc at line 53 that could also go.

Yes. I will make the cleanup as well.

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

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


From xuelei at openjdk.org  Thu Nov 10 01:48:57 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 01:48:57 GMT
Subject: RFR: 8293886: The abstract keyword can be removed in AESCipher
 [v2]
In-Reply-To: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
References: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
Message-ID: <0Q3oSaWYpJpP_bKApyfr7BaKKC9LB-HGKP1BFIomPNU=.021ef7b9-6e94-4867-bada-0691971f71a3@github.com>

> Hi,
> 
> Please review this simple fix for readability.
> 
> In the AES cipher implementation, the AESCipher class is defined as abstract.  As is not necessary as there is no abstract method in this class. Code reader may try to search for abstract methods if the abstract keyword is present.
> 
> BTW, I also added Override tags and make a few other cleanup, for example adding the 'final' keywords.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan 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:

 - remove unused import
 - Merge
 - update copyright year
 - 8293886: The abstract keyword can be removed in AESCipher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10297/files
  - new: https://git.openjdk.org/jdk/pull/10297/files/defa6e5d..350bbe1b

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

  Stats: 277903 lines in 3883 files changed: 143337 ins; 88425 del; 46141 mod
  Patch: https://git.openjdk.org/jdk/pull/10297.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10297/head:pull/10297

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


From xuelei at openjdk.org  Thu Nov 10 02:05:31 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 02:05:31 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded
In-Reply-To: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
Message-ID: <r63wYTCCmADzhpAY91hoUEG9DrfRLHe2TiLzL4bjQ8o=.2cf83c79-29ab-4ce4-9dae-9e0e434e2b83@github.com>

On Wed, 9 Nov 2022 21:54:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.
> 
> After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.
> 
> In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.

Is it a real problem reported in productive environment?  I was just wondering if it is a feature that nobody used it yet.

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 628:

> 626:             // break unnecessary
> 627: 
> 628:         case 16:    // SigningCertificate

I may prefer to use enum for PKCS9_OIDS so that we don't worry about if 16 is mapping to SigningCertificate while reading the code.  But it is not in the scope of this PR.

src/java.base/share/classes/sun/security/pkcs/SigningCertificateInfo.java line 92:

> 90:     }
> 91: 
> 92:     public byte[] toByteArray() {

Is it possible to have the method package private?

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

Changes requested by xuelei (Reviewer).

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


From weijun at openjdk.org  Thu Nov 10 02:10:57 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 02:10:57 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded
In-Reply-To: <r63wYTCCmADzhpAY91hoUEG9DrfRLHe2TiLzL4bjQ8o=.2cf83c79-29ab-4ce4-9dae-9e0e434e2b83@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <r63wYTCCmADzhpAY91hoUEG9DrfRLHe2TiLzL4bjQ8o=.2cf83c79-29ab-4ce4-9dae-9e0e434e2b83@github.com>
Message-ID: <CpTHCVXbhptOyQnUh0nRtIJne9XHH_ooWkwo1LZxhpw=.7af83560-8665-4db2-a61c-23475a6c2ec5@github.com>

On Thu, 10 Nov 2022 01:56:29 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.
>> 
>> After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.
>> 
>> In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.
>
> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 628:
> 
>> 626:             // break unnecessary
>> 627: 
>> 628:         case 16:    // SigningCertificate
> 
> I may prefer to use enum for PKCS9_OIDS so that we don't worry about if 16 is mapping to SigningCertificate while reading the code.  But it is not in the scope of this PR.

Totally agree.

> src/java.base/share/classes/sun/security/pkcs/SigningCertificateInfo.java line 92:
> 
>> 90:     }
>> 91: 
>> 92:     public byte[] toByteArray() {
> 
> Is it possible to have the method package private?

The whole class is only used in the same package at the moment. Making only one method package private is not fair.

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

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


From weijun at openjdk.org  Thu Nov 10 02:14:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 02:14:05 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded
In-Reply-To: <r63wYTCCmADzhpAY91hoUEG9DrfRLHe2TiLzL4bjQ8o=.2cf83c79-29ab-4ce4-9dae-9e0e434e2b83@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <r63wYTCCmADzhpAY91hoUEG9DrfRLHe2TiLzL4bjQ8o=.2cf83c79-29ab-4ce4-9dae-9e0e434e2b83@github.com>
Message-ID: <He9GoTkgvdaVCIUfHcOhQjmTxjh2jMB-gq7pDHSDECo=.240fa4dc-782f-4546-81f9-81d8c8d9b303@github.com>

On Thu, 10 Nov 2022 02:01:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Is it a real problem reported in productive environment?

No. I am just cleaning up the code to make encoding and decoding symmetric and consistent. You can see I'm working on several PRs at the same time.

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

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


From xuelei at openjdk.org  Thu Nov 10 02:18:29 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 02:18:29 GMT
Subject: RFR: 8296741: Illegal X400Address and EDIPartyName should not be
 created [v2]
In-Reply-To: <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
References: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
 <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
Message-ID: <BtIWs7BPr-UjeAiqNp7BeMrdj5aKveDD233i17m3SCE=.f52a869d-810a-4847-bdcf-22e69175a2de@github.com>

On Wed, 9 Nov 2022 22:44:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> `EDIPartyName` should not have a null `partyName`.
>> 
>> Inside `X400Name` it should be a `DerValue` instead of arbitrary byte array. Note: in `GeneralSubtrees.java`, an `X400Name` is created with a null content. This would lead to an NPE anyway. A future fix might be needed.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test
>   
>   only in patch2:
>   unchanged:

src/java.base/share/classes/sun/security/x509/EDIPartyName.java line 66:

> 64:     public EDIPartyName(String assignerName, String partyName) {
> 65:         this.assigner = assignerName;
> 66:         this.party = Objects.requireNonNull(partyName);

It looks like this constructor is not used.  Is if safe to remove it?

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

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


From xuelei at openjdk.org  Thu Nov 10 02:20:42 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 02:20:42 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded
In-Reply-To: <CpTHCVXbhptOyQnUh0nRtIJne9XHH_ooWkwo1LZxhpw=.7af83560-8665-4db2-a61c-23475a6c2ec5@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <r63wYTCCmADzhpAY91hoUEG9DrfRLHe2TiLzL4bjQ8o=.2cf83c79-29ab-4ce4-9dae-9e0e434e2b83@github.com>
 <CpTHCVXbhptOyQnUh0nRtIJne9XHH_ooWkwo1LZxhpw=.7af83560-8665-4db2-a61c-23475a6c2ec5@github.com>
Message-ID: <bAGfk6GTzzehkXb47LI3qhBMGmLmokP2PMhaU4nP-fw=.be23dbfe-2cf3-4f74-9b2e-f5cd616ad6c5@github.com>

On Thu, 10 Nov 2022 02:08:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/SigningCertificateInfo.java line 92:
>> 
>>> 90:     }
>>> 91: 
>>> 92:     public byte[] toByteArray() {
>> 
>> Is it possible to have the method package private?
>
> The whole class is only used in the same package at the moment. Making only one method package private is not fair.

Hm, maybe making this class package private as well?  The returned array is not cloned.   It may not worthy of a clone as it is used just once in the package.  But if it is public, a lot of time would be costed in the future to check if is a potential issue.

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

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


From weijun at openjdk.org  Thu Nov 10 02:35:26 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 02:35:26 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded
In-Reply-To: <bAGfk6GTzzehkXb47LI3qhBMGmLmokP2PMhaU4nP-fw=.be23dbfe-2cf3-4f74-9b2e-f5cd616ad6c5@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <r63wYTCCmADzhpAY91hoUEG9DrfRLHe2TiLzL4bjQ8o=.2cf83c79-29ab-4ce4-9dae-9e0e434e2b83@github.com>
 <CpTHCVXbhptOyQnUh0nRtIJne9XHH_ooWkwo1LZxhpw=.7af83560-8665-4db2-a61c-23475a6c2ec5@github.com>
 <bAGfk6GTzzehkXb47LI3qhBMGmLmokP2PMhaU4nP-fw=.be23dbfe-2cf3-4f74-9b2e-f5cd616ad6c5@github.com>
Message-ID: <BGM_g-eVo7_nlI9AstfyeeWVvbQEDJ59F-D18xBpYmo=.bc32c793-7fb9-4745-a54f-081e8795bde8@github.com>

On Thu, 10 Nov 2022 02:18:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The whole class is only used in the same package at the moment. Making only one method package private is not fair.
>
> Hm, maybe making this class package private as well?  The returned array is not cloned.   It may not worthy of a clone as it is used just once in the package.  But if it is public, a lot of time would be costed in the future to check if is a potential issue.

Fair enough. I'll fix it.

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

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


From weijun at openjdk.org  Thu Nov 10 02:36:21 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 02:36:21 GMT
Subject: RFR: 8296741: Illegal X400Address and EDIPartyName should not be
 created [v2]
In-Reply-To: <BtIWs7BPr-UjeAiqNp7BeMrdj5aKveDD233i17m3SCE=.f52a869d-810a-4847-bdcf-22e69175a2de@github.com>
References: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
 <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
 <BtIWs7BPr-UjeAiqNp7BeMrdj5aKveDD233i17m3SCE=.f52a869d-810a-4847-bdcf-22e69175a2de@github.com>
Message-ID: <M2Xv4oGhaeuVm_cOQFqr3zGJXjo2cWM_Gp2-u4PhAIQ=.8369173b-5a86-4183-8566-a02df09dcf24@github.com>

On Thu, 10 Nov 2022 02:14:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test
>>   
>>   only in patch2:
>>   unchanged:
>
> src/java.base/share/classes/sun/security/x509/EDIPartyName.java line 66:
> 
>> 64:     public EDIPartyName(String assignerName, String partyName) {
>> 65:         this.assigner = assignerName;
>> 66:         this.party = Objects.requireNonNull(partyName);
> 
> It looks like this constructor is not used.  Is if safe to remove it?

It's not used inside JDK. But for completeness it sounds there should be a way to create one with an assigner.

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

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


From weijun at openjdk.org  Thu Nov 10 02:43:21 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 02:43:21 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v2]
In-Reply-To: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
Message-ID: <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>

> One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.
> 
> After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.
> 
> In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.

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

  make class package private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11070/files
  - new: https://git.openjdk.org/jdk/pull/11070/files/b80a7805..8765c136

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

  Stats: 42 lines in 1 file changed: 6 ins; 4 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/11070.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11070/head:pull/11070

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


From weijun at openjdk.org  Thu Nov 10 02:43:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 02:43:22 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded
In-Reply-To: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
Message-ID: <0x9kiWgTvi46ux_bLSlF5cO95sRg2XvArr10SyNhWtU=.5afc918c-10b7-4e62-878e-a5bb00cb6dbf@github.com>

On Wed, 9 Nov 2022 21:54:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.
> 
> After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.
> 
> In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.

New commit. I also put `ESSCertId` as an inner class. Having 2 top level classes in the same file feel weird.

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

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


From duke at openjdk.org  Thu Nov 10 03:09:43 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 10 Nov 2022 03:09:43 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v11]
In-Reply-To: <actl_ZA8F_vYPeNjov0QcGklPyBQjm-geVl1rPLtFpU=.c440119c-5b4e-4c98-9a57-4fa36785bcbf@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <actl_ZA8F_vYPeNjov0QcGklPyBQjm-geVl1rPLtFpU=.c440119c-5b4e-4c98-9a57-4fa36785bcbf@github.com>
Message-ID: <9Ststt1zBbU04qp9Ilb7zPQx3bA5uIQEi-TtbpiMn1s=.01700387-0a3b-4f47-9daa-1febc7230539@github.com>

On Thu, 10 Nov 2022 01:22:04 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix windows and 32b linux builds

Revised numbers with `getLimbs()` interface change. Compared to previous version that got limbs in IR, change is within deviation.. (mostly -1%)
datasize | master | optimized | disabled | opt/mst | dis/mst
-- | -- | -- | -- | -- | --
32 | 3218169 | 3651078 | 3116558 | 1.13 | 0.97
64 | 2858030 | 3407518 | 2824903 | 1.19 | 0.99
128 | 2396796 | 3357224 | 2394802 | 1.40 | 1.00
256 | 1780679 | 3050142 | 1751130 | 1.71 | 0.98
512 | 1168824 | 2938952 | 1148479 | 2.51 | 0.98
1024 | 648772.1 | 2728454 | 687016.7 | 4.21 | 1.06
2048 | 357009 | 2393507 | 392928.2 | 6.70 | 1.10
16384 | 48854.33 | 903175.4 | 52874.78 | 18.49 | 1.08
1048576 | 771.461 | 14951.24 | 840.792 | 19.38 | 1.09

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

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


From xuelei at openjdk.org  Thu Nov 10 03:55:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 03:55:28 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v2]
In-Reply-To: <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>
Message-ID: <rM-cWwDjnT4wI62fECw9ZTkiCEunAlw9Z2oArz3l-J8=.724bc385-68cb-4772-ba0b-d4dae2542d27@github.com>

On Thu, 10 Nov 2022 02:43:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.
>> 
>> After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.
>> 
>> In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make class package private

Looks good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

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


From xuelei at openjdk.org  Thu Nov 10 03:56:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 03:56:28 GMT
Subject: RFR: 8296741: Illegal X400Address and EDIPartyName should not be
 created [v2]
In-Reply-To: <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
References: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
 <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
Message-ID: <l3DoM2B3z1EkeeWXo0mIPxE9_PAuGy_FFfqDTkBMkr0=.ded697fb-3e2a-422b-964b-2bf9a9b46e2e@github.com>

On Wed, 9 Nov 2022 22:44:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> `EDIPartyName` should not have a null `partyName`.
>> 
>> Inside `X400Name` it should be a `DerValue` instead of arbitrary byte array. Note: in `GeneralSubtrees.java`, an `X400Name` is created with a null content. This would lead to an NPE anyway. A future fix might be needed.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test
>   
>   only in patch2:
>   unchanged:

Marked as reviewed by xuelei (Reviewer).

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

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


From xuelei at openjdk.org  Thu Nov 10 03:56:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 03:56:28 GMT
Subject: RFR: 8296741: Illegal X400Address and EDIPartyName should not be
 created [v2]
In-Reply-To: <M2Xv4oGhaeuVm_cOQFqr3zGJXjo2cWM_Gp2-u4PhAIQ=.8369173b-5a86-4183-8566-a02df09dcf24@github.com>
References: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
 <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
 <BtIWs7BPr-UjeAiqNp7BeMrdj5aKveDD233i17m3SCE=.f52a869d-810a-4847-bdcf-22e69175a2de@github.com>
 <M2Xv4oGhaeuVm_cOQFqr3zGJXjo2cWM_Gp2-u4PhAIQ=.8369173b-5a86-4183-8566-a02df09dcf24@github.com>
Message-ID: <KHgTx0D5F9lWE_rNq2PPcLoOBsLf2u33Adx_IASrf4w=.c6228b8e-bd9c-408d-8ae0-e2a979de2f63@github.com>

On Thu, 10 Nov 2022 02:32:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/EDIPartyName.java line 66:
>> 
>>> 64:     public EDIPartyName(String assignerName, String partyName) {
>>> 65:         this.assigner = assignerName;
>>> 66:         this.party = Objects.requireNonNull(partyName);
>> 
>> It looks like this constructor is not used.  Is if safe to remove it?
>
> It's not used inside JDK. But for completeness it sounds there should be a way to create one with an assigner.

Unused code means useless cost.  For private package, it may be nice to keep compact and no unused code.  As the class is public, I'm fine to leave as it is if you want to.

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

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


From xuelei at openjdk.org  Thu Nov 10 06:18:35 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 06:18:35 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
Message-ID: <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>

On Wed, 9 Nov 2022 19:59:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
> 
> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
> 
> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.

Changes requested by xuelei (Reviewer).

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 192:

> 190:             // create an AlgorithmId from it. This should usually be true
> 191:             // since we already require its getEncoded() returning the
> 192:             // encoded bytes of it.

It looks like the comment implies there is no need of  the catch block.  Did you want to add something like "But it may be not true if ..."?  Or, is the comment belong to AlgorithmId?

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 199:

> 197:         if (tmp != null) {
> 198:             this.algid = tmp;
> 199:             this.params = null;

There is a getAlgParameters() method in the class.  Does it make sense to cache the params?

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 238:

> 236:      */
> 237:     public AlgorithmParameters getAlgParameters() {
> 238:         return algid == null ? params : algid.getParameters();

Does it make sense to keep the params from constructor and return the field here?

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 412:

> 410:                 try {
> 411:                     // Let's hope params has been initialized by now.
> 412:                     AlgorithmId.get(params).encode(tmp);

It looks like that you want to take care of the cases that the AlgorithmId did not initialize yet.  See comments in  AlgorithmId.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 437:

> 435: 
> 436:     @SuppressWarnings("fallthrough")
> 437:     private static PKCS8EncodedKeySpec pKCS8EncodingToSpec(byte[] encodedKey)

Does "pkcs8..." (will lowercase) look like a better name for the method?

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 113:

> 111:             } catch (IOException ioe) {
> 112:                 throw new IllegalStateException(
> 113:                         "AlgorithmParameters not initialized", ioe);

Did you have a chance to look at the caller and make sure this behavioral update is safe?

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 177:

> 175:             // If still not initialized. Let the IOE be thrown.
> 176:         }
> 177: 

This could be a risk change if the caller was not coded like what you do in the EncryptedPrivateKeyInfo.java update.   Did you have a chance to check all caller codes and make sure it is a safe update.

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

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


From xuelei at openjdk.org  Thu Nov 10 06:18:35 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 06:18:35 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <tgrDSays7U99ZTFFFBh4a7t_f4ByqZPLeiL19A-MjOE=.b9950f5a-4766-462f-9dc3-a78d6305cab6@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <tgrDSays7U99ZTFFFBh4a7t_f4ByqZPLeiL19A-MjOE=.b9950f5a-4766-462f-9dc3-a78d6305cab6@github.com>
Message-ID: <aou4sdYL-TdZNeXQ9kouu7NF18241y_7VaFDDhyFXkg=.4856f99c-0e34-45ed-883c-ed2afde4d73f@github.com>

On Wed, 9 Nov 2022 20:15:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 423:
> 
>> 421:             // wrap everything into a SEQUENCE
>> 422:             out.write(DerValue.tag_Sequence, tmp);
>> 423:             return out.toByteArray();
> 
> I'd rather not cache the encoding. First, the cache makes the class mutable. Second, `getEncode` should usually only be called once and the cache is not so useful. Third, this avoids an unnecessary clone (on the line below).

I'm not very sure of the 2nd point.  Is it possible the class could be a long term object, and used multiple time?  Anyway, the encoding should be fast and may not worthy of a mutable design.

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

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


From dfuchs at openjdk.org  Thu Nov 10 11:34:25 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Nov 2022 11:34:25 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html

External Specifications
    [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)

You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing.
Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

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

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


From alanb at openjdk.org  Thu Nov 10 11:49:21 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 11:49:21 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

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

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


From alanb at openjdk.org  Thu Nov 10 12:04:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 12:04:51 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I'm just trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same will spec linked from "See also" and "External Specifications", e.g.
http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY
so the `@see` ref can be dropped.

In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?

There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

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

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


From mstjohns at comcast.net  Thu Nov 10 13:35:20 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 10 Nov 2022 08:35:20 -0500
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <87c80e83-af71-d9dd-75f6-49770fb37817@comcast.net>

Daniel et al -

Please avoid using ietf.org as the cite location for RFCs

The preferred cite for RFCs is generally via 
www.rfc-editor.org/info/rfc<number> - that will get you to the info 
page, but with links to pdf, html, and a clean .txt.

Cf https://www.rfc-editor.org/info/rfc4180 - "Cite this RFC"? -

> Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, October 2005,<https://www.rfc-editor.org/info/rfc4180>.

Note that the most stable cite might be the DOI cite, but the above is 
going to be fairly useful for a long time to come.

Mike


On 11/10/2022 6:34 AM, Daniel Fuchs wrote:
> On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons<jjg at openjdk.org>  wrote:
>
>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>>
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>>
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>>
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>>
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>>
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>>
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>>
>> To see the effect of all these new `@spec` tags, seehttp://cr.openjdk.java.net/~jjg/8296546/api.00/
>>
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
> Hi Jon,
>
> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
>
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html
>
> External Specifications
>      [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)
>
> You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing.
> Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.
>
> -------------
>
> PR:https://git.openjdk.org/jdk/pull/11073

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221110/3423e68e/attachment.htm>

From weijun at openjdk.org  Thu Nov 10 14:39:20 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 14:39:20 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <aou4sdYL-TdZNeXQ9kouu7NF18241y_7VaFDDhyFXkg=.4856f99c-0e34-45ed-883c-ed2afde4d73f@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <tgrDSays7U99ZTFFFBh4a7t_f4ByqZPLeiL19A-MjOE=.b9950f5a-4766-462f-9dc3-a78d6305cab6@github.com>
 <aou4sdYL-TdZNeXQ9kouu7NF18241y_7VaFDDhyFXkg=.4856f99c-0e34-45ed-883c-ed2afde4d73f@github.com>
Message-ID: <eHM7i4j7MzwFI0mapYNpzKg5rrJB0gbZ7nmV2tqcYTw=.6829b8ff-c1b4-4668-9f20-ac3953537e82@github.com>

On Thu, 10 Nov 2022 05:42:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 423:
>> 
>>> 421:             // wrap everything into a SEQUENCE
>>> 422:             out.write(DerValue.tag_Sequence, tmp);
>>> 423:             return out.toByteArray();
>> 
>> I'd rather not cache the encoding. First, the cache makes the class mutable. Second, `getEncode` should usually only be called once and the cache is not so useful. Third, this avoids an unnecessary clone (on the line below).
>
> I'm not very sure of the 2nd point.  Is it possible the class could be a long term object, and used multiple time?  Anyway, the encoding should be fast and may not worthy of a mutable design.

Well, maybe not very sure. IMO, the class itself only does decryption so most likely one reads the encrypted key from a file and then call one of the `getKeySpec` methods to extract the key inside. If doing an encryption, user has to encrypt it on their own and then call one of the constructors with 2 arguments, and then might call `getEncoded` to store it somewhere. This only needs to be done once.

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

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


From weijun at openjdk.org  Thu Nov 10 14:47:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 14:47:27 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
Message-ID: <u1gvz2UYhTIgLq3liqAecjlQMZDxjclfV--8BoQZNKU=.39d1530b-d6b4-4550-8839-12ceaac467f5@github.com>

On Thu, 10 Nov 2022 05:49:12 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 192:
> 
>> 190:             // create an AlgorithmId from it. This should usually be true
>> 191:             // since we already require its getEncoded() returning the
>> 192:             // encoded bytes of it.
> 
> It looks like the comment implies there is no need of  the catch block.  Did you want to add something like "But it may be not true if ..."?  Or, is the comment belong to AlgorithmId?

This comment is for this class. The spec mentions `{@code algParams.getEncoded()} should return` so one can say that it already implied that the params has already been initialized. This is a little subtle and given that real world developer might first create this subject with an uninitialized params and then initialize it before calling `getEncoded`, I decide to support this case as well. I'll think about how to describe it better.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 199:
> 
>> 197:         if (tmp != null) {
>> 198:             this.algid = tmp;
>> 199:             this.params = null;
> 
> There is a getAlgParameters() method in the class.  Does it make sense to cache the params?

OK. Thanks.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 437:
> 
>> 435: 
>> 436:     @SuppressWarnings("fallthrough")
>> 437:     private static PKCS8EncodedKeySpec pKCS8EncodingToSpec(byte[] encodedKey)
> 
> Does "pkcs8..." (will lowercase) look like a better name for the method?

OK.

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

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


From weijun at openjdk.org  Thu Nov 10 14:57:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 14:57:11 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
Message-ID: <2iQ6KeJVGxMH9HD1ovaH86gKEnEHMns4LOtFJomGML8=.6c6caf9b-07f1-4589-aee1-8d88d8e8ce6c@github.com>

On Thu, 10 Nov 2022 06:14:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 412:
> 
>> 410:                 try {
>> 411:                     // Let's hope params has been initialized by now.
>> 412:                     AlgorithmId.get(params).encode(tmp);
> 
> It looks like that you want to take care of the cases that the AlgorithmId did not initialize yet.  See comments in  AlgorithmId.

This is just a last try. The same IOE is thrown just like before. The difference is that the exception was thrown in `encode` but now in `get`.

> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 177:
> 
>> 175:             // If still not initialized. Let the IOE be thrown.
>> 176:         }
>> 177: 
> 
> This could be a risk change if the caller was not coded like what you do in the EncryptedPrivateKeyInfo.java update.   Did you have a chance to check all caller codes and make sure it is a safe update.

I double checked again. In all other cases, the params is either explicitly initialized right before the call, or it's retrieved from an initialized signature/cipher or another `AlgorithmId`. There is only one case that does not have an origin but the method is not called anywhere. I'll remove that method in my next commit.

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

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


From weijun at openjdk.org  Thu Nov 10 15:05:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 15:05:51 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
Message-ID: <rhrLPtqZOaCLSOWjbRGiv98a0tKlzffr1tuLRDS-2Hc=.29658a4a-aeb0-4481-99ad-3009c0d1bc9c@github.com>

On Thu, 10 Nov 2022 06:15:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 113:
> 
>> 111:             } catch (IOException ioe) {
>> 112:                 throw new IllegalStateException(
>> 113:                         "AlgorithmParameters not initialized", ioe);
> 
> Did you have a chance to look at the caller and make sure this behavioral update is safe?

The only left caller is `EncryptedPrivateKeyInfo`. If new callers start using this constructor, this will be the expected behavior. The message can be enhanced a little since there could be other reasons. (Ex: `PSSParameters` with unknown hash algorithms).

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

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


From weijun at openjdk.org  Thu Nov 10 15:20:30 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 15:20:30 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters
In-Reply-To: <u1gvz2UYhTIgLq3liqAecjlQMZDxjclfV--8BoQZNKU=.39d1530b-d6b4-4550-8839-12ceaac467f5@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
 <u1gvz2UYhTIgLq3liqAecjlQMZDxjclfV--8BoQZNKU=.39d1530b-d6b4-4550-8839-12ceaac467f5@github.com>
Message-ID: <78jndyx6LiVfXPKRi8EeBdztjx9ZBBpDTkRstuFxr_Y=.05b7ee8b-036a-47d9-9999-57ce3439c63f@github.com>

On Thu, 10 Nov 2022 14:43:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 199:
>> 
>>> 197:         if (tmp != null) {
>>> 198:             this.algid = tmp;
>>> 199:             this.params = null;
>> 
>> There is a getAlgParameters() method in the class.  Does it make sense to cache the params?
>
> OK. Thanks.

I rethink about this. More logic is needed when both can be non-null. On the other hand, `algid.getParameters()` just returns a field. I'd rather keep my original code.

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

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


From weijun at openjdk.org  Thu Nov 10 15:27:52 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 15:27:52 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v2]
In-Reply-To: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
Message-ID: <0qHiYKpUgkuf18QMddCZNU2aJ4a72KyNLqwIJXYWt4k=.16d3128e-1147-4c4a-8fce-3d85cba1824e@github.com>

> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
> 
> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
> 
> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.

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

  address xuelei's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11067/files
  - new: https://git.openjdk.org/jdk/pull/11067/files/f80794c4..499f50a8

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

  Stats: 50 lines in 2 files changed: 6 ins; 37 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11067.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11067/head:pull/11067

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


From mullan at openjdk.org  Thu Nov 10 15:35:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 15:35:30 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
Message-ID: <lnH8lsGsP0sRLWUGmddbSM9UzhX_K7-Bw5T630BuVB0=.8520b429-86fc-4397-8e27-5a65528b9e1c@github.com>

On Tue, 8 Nov 2022 10:01:47 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> SubjectCodeSource is no longer used, Class should be deleted and all references updated
>
> Ryan Wallace 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 branch 'master' into 8294526
>  - Merge branch 'master' into 8294526
>  - Merge branch 'master' into 8294526
>  - 8294526: SubjectCodeSource is no longer referenced
>  - Merge branch 'master' into 8294526
>  - Merge branch 'openjdk:master' into 8294526
>  - 8294526: SubjectCodeSource is no longer used, removing class and all references

@ryawalla Have you or your company signed the OCA? I do not see `/signed` or `/covered` actions in this PR.

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

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


From duke at openjdk.org  Thu Nov 10 15:56:32 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Thu, 10 Nov 2022 15:56:32 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <lnH8lsGsP0sRLWUGmddbSM9UzhX_K7-Bw5T630BuVB0=.8520b429-86fc-4397-8e27-5a65528b9e1c@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
 <lnH8lsGsP0sRLWUGmddbSM9UzhX_K7-Bw5T630BuVB0=.8520b429-86fc-4397-8e27-5a65528b9e1c@github.com>
Message-ID: <xxS2MCd9QqjDAwRMFWToOvDhg-7APaQMIXi0MeNsdwo=.5563db11-c318-4e49-a1f2-91b2d143da11@github.com>

On Thu, 10 Nov 2022 15:33:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ryan Wallace 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 branch 'master' into 8294526
>>  - Merge branch 'master' into 8294526
>>  - Merge branch 'master' into 8294526
>>  - 8294526: SubjectCodeSource is no longer referenced
>>  - Merge branch 'master' into 8294526
>>  - Merge branch 'openjdk:master' into 8294526
>>  - 8294526: SubjectCodeSource is no longer used, removing class and all references
>
> @ryawalla Have you or your company signed the OCA? I do not see `/signed` or `/covered` actions in this PR.

@seanjmullan I thought I had resolved this as previously the OCA was failing jcheck, I am an Oracle employee.  Should I still be adding /signed or /covered actions? 
This is my first change in the openjdk so my account may not be linked to the org correctly.

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

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


From weijun at openjdk.org  Thu Nov 10 16:09:29 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 16:09:29 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <RI9NJkzhfEQwL5lJLL-73QcVEOlkTxVGmp5TvGi6ue4=.bc7e0260-fbeb-4dbd-811b-16e47ee0b3f1@github.com>

On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo <duke at openjdk.org> wrote:

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

The method is not called since JDK 9, and that's why I set Affected Version/s to 8-pool. We don't intend to fix this in the current release.

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

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


From weijun at openjdk.org  Thu Nov 10 16:24:26 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 16:24:26 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <YsQZKL7FoweoqYLwGrMarDb92lTrfeAWksgmD2tTktc=.424afc93-1eb4-42ef-8f1a-81a9db5e000e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I see https://www.ietf.org/rfc/rfc0822.html. Should be https://www.ietf.org/rfc/rfc822.html

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

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


From duke at openjdk.org  Thu Nov 10 16:26:38 2022
From: duke at openjdk.org (pandaapo)
Date: Thu, 10 Nov 2022 16:26:38 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <RI9NJkzhfEQwL5lJLL-73QcVEOlkTxVGmp5TvGi6ue4=.bc7e0260-fbeb-4dbd-811b-16e47ee0b3f1@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <RI9NJkzhfEQwL5lJLL-73QcVEOlkTxVGmp5TvGi6ue4=.bc7e0260-fbeb-4dbd-811b-16e47ee0b3f1@github.com>
Message-ID: <hREsOvHynke2NR7rwucTPOo7dCutxSKSz3LMO1i1vbw=.31550da5-b433-4d31-93df-434839b6d9d4@github.com>

On Thu, 10 Nov 2022 16:05:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The method is not called since JDK 9, and that's why I set Affected Version/s to 8-pool. We don't intend to fix this in the current release.

Oh. Could you tell me where I should submit this PR? `jdk8u`?

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

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


From duke at openjdk.org  Thu Nov 10 16:35:32 2022
From: duke at openjdk.org (AJ1062910)
Date: Thu, 10 Nov 2022 16:35:32 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

did you changed 420 files ?

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

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


From kdriver at openjdk.org  Thu Nov 10 16:43:32 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 10 Nov 2022 16:43:32 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v2]
In-Reply-To: <0qHiYKpUgkuf18QMddCZNU2aJ4a72KyNLqwIJXYWt4k=.16d3128e-1147-4c4a-8fce-3d85cba1824e@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <0qHiYKpUgkuf18QMddCZNU2aJ4a72KyNLqwIJXYWt4k=.16d3128e-1147-4c4a-8fce-3d85cba1824e@github.com>
Message-ID: <s82qtZaoWyWNmlGqjl6zCIu6urnMs96AOqynYC1SB1I=.1d275424-2867-44d4-9eba-1bddf3c5ddff@github.com>

On Thu, 10 Nov 2022 15:27:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address xuelei's comments

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 187:

> 185:             throw new NullPointerException("algParams must be non-null");
> 186:         }
> 187:         AlgorithmId tmp;

style-comment: meaningful variable names should be preferred (ie- choose something other than `tmp`)

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

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


From kdriver at openjdk.org  Thu Nov 10 17:11:31 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 10 Nov 2022 17:11:31 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v2]
In-Reply-To: <0qHiYKpUgkuf18QMddCZNU2aJ4a72KyNLqwIJXYWt4k=.16d3128e-1147-4c4a-8fce-3d85cba1824e@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <0qHiYKpUgkuf18QMddCZNU2aJ4a72KyNLqwIJXYWt4k=.16d3128e-1147-4c4a-8fce-3d85cba1824e@github.com>
Message-ID: <PpVZ2qPZjZG8M6w4QVDSmeP5CxaGiN4P43J7L8ce3rM=.a39405cf-5115-45f0-8c72-8c498e613933@github.com>

On Thu, 10 Nov 2022 15:27:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address xuelei's comments

test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetAlgName.java line 72:

> 70:             epki = new EncryptedPrivateKeyInfo(ap2, BYTES);
> 71:             if (!epki.getAlgName().equalsIgnoreCase(algo)) {
> 72:                 System.out.println("...expect: " + algo);

should be "...expected: "

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

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


From weijun at openjdk.org  Thu Nov 10 17:52:36 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 17:52:36 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v2]
In-Reply-To: <s82qtZaoWyWNmlGqjl6zCIu6urnMs96AOqynYC1SB1I=.1d275424-2867-44d4-9eba-1bddf3c5ddff@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <0qHiYKpUgkuf18QMddCZNU2aJ4a72KyNLqwIJXYWt4k=.16d3128e-1147-4c4a-8fce-3d85cba1824e@github.com>
 <s82qtZaoWyWNmlGqjl6zCIu6urnMs96AOqynYC1SB1I=.1d275424-2867-44d4-9eba-1bddf3c5ddff@github.com>
Message-ID: <lutWl4JHud1dl_w1cVy8TdculwfRjnkMbIrUHUUUcLY=.c17a62ff-188a-4b62-86c6-028066327fee@github.com>

On Thu, 10 Nov 2022 16:41:13 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address xuelei's comments
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 187:
> 
>> 185:             throw new NullPointerException("algParams must be non-null");
>> 186:         }
>> 187:         AlgorithmId tmp;
> 
> style-comment: meaningful variable names should be preferred (ie- choose something other than `tmp`)

I don't usually use tmp as variable names, but when I do, it's indeed temporary and will be discarded within 8 lines (comment and empty lines not counted). :-D

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

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


From xuelei at openjdk.org  Thu Nov 10 17:55:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 17:55:30 GMT
Subject: Integrated: 8293886: The abstract keyword can be removed in AESCipher
In-Reply-To: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
References: <KT9HeD7H0VnC7W7Tlb-HaUu-q93ooODbNcoCpGwQRYw=.448f15df-3670-4a35-956b-768a8d7e2830@github.com>
Message-ID: <OqvWhVQSDc5T5WYcOsFDSZt6iJeBwgRKhDRTRHeO4ZE=.9bc2dc1c-a657-486f-8fb9-5141868d7768@github.com>

On Fri, 16 Sep 2022 00:27:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review this simple fix for readability.
> 
> In the AES cipher implementation, the AESCipher class is defined as abstract.  As is not necessary as there is no abstract method in this class. Code reader may try to search for abstract methods if the abstract keyword is present.
> 
> BTW, I also added Override tags and make a few other cleanup, for example adding the 'final' keywords.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

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

8293886: The abstract keyword can be removed in AESCipher

Reviewed-by: ascarpino, wetmore

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

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


From weijun at openjdk.org  Thu Nov 10 17:59:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 17:59:44 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
Message-ID: <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>

> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
> 
> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
> 
> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.

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

  expected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11067/files
  - new: https://git.openjdk.org/jdk/pull/11067/files/499f50a8..619c6f44

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

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

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


From weijun at openjdk.org  Thu Nov 10 17:59:45 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 17:59:45 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v2]
In-Reply-To: <PpVZ2qPZjZG8M6w4QVDSmeP5CxaGiN4P43J7L8ce3rM=.a39405cf-5115-45f0-8c72-8c498e613933@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <0qHiYKpUgkuf18QMddCZNU2aJ4a72KyNLqwIJXYWt4k=.16d3128e-1147-4c4a-8fce-3d85cba1824e@github.com>
 <PpVZ2qPZjZG8M6w4QVDSmeP5CxaGiN4P43J7L8ce3rM=.a39405cf-5115-45f0-8c72-8c498e613933@github.com>
Message-ID: <bdacWt8au874vRnboHJKv5YkrSZvmiAgN9mlHUar8cE=.46b75df9-9c00-45d4-860e-2692e1912f35@github.com>

On Thu, 10 Nov 2022 17:07:45 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address xuelei's comments
>
> test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetAlgName.java line 72:
> 
>> 70:             epki = new EncryptedPrivateKeyInfo(ap2, BYTES);
>> 71:             if (!epki.getAlgName().equalsIgnoreCase(algo)) {
>> 72:                 System.out.println("...expect: " + algo);
> 
> should be "...expected: "

Will fix. Thanks.

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

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


From mpowers at openjdk.org  Thu Nov 10 18:13:33 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 10 Nov 2022 18:13:33 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v2]
In-Reply-To: <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>
Message-ID: <1d37d2epeD8-ox2dYEwjozm27uGa43hdssroZrXjYR0=.14c9ecf4-d2ea-46c0-8acc-5eec8df6a0dc@github.com>

On Thu, 10 Nov 2022 02:43:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> One `PKCS9Attribute` can be created but cannot be encoded. Since the `SigningCertificateInfo::parse` method has not fully parsed the data (`PolicyInformation` is left out), this code change add the encoding itself as a field to the `SigningCertificateInfo` class so we can encode it.
>> 
>> After this change, unsupported `PKCSAttribute` object simply cannot be created. The `new(DerValue)` constructor rejects them (type 9-13, 15) in a `switch` block, and the `new(ObjectIdentifier, Object)` constructor rejects them because `VALUE_CLASSES` for them are null.
>> 
>> In the `encode()` method, we now throw `IllegalArgumentException` for these types and they will not happen.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make class package private

Late to the party: Looks Good To Me.

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

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


From xuelei at openjdk.org  Thu Nov 10 18:14:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 18:14:30 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
Message-ID: <fAbH91Msf6cfVJFtvX7G5gTknQS-40_6zQH0N-nULAo=.6c0727bd-57a3-461b-9364-7dfbd2ea6f82@github.com>

On Thu, 10 Nov 2022 17:59:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   expected

Looks good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

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


From xuelei at openjdk.org  Thu Nov 10 18:37:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 18:37:16 GMT
Subject: RFR: 8296809: KeyPairGenerator benchmark
Message-ID: <_NjvHR31wUV6k9GdXHO5wy8F_H-AwrbZ6141poHbxsM=.811c8a84-4d75-4b3f-813e-656160bb1c2f@github.com>

Hi,

May I have the micro-benchmark code reviewed for EC key pair generation algorithms? The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.

Thanks,
Xuelei

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

Commit messages:
 - 8296809: KeyPairGenerator benchmark

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

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


From jnimeh at openjdk.org  Thu Nov 10 20:11:46 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 10 Nov 2022 20:11:46 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v3]
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <L1ZTSckdP_iY9bvifRX-00Qqw6VLq3sWU9k93TrLW_w=.fc29ffb4-78dc-4d31-b36c-c296e3f48a91@github.com>

> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
> 
> - x86_64: AVX, AVX2 and AVX512
> - aarch64: platforms that support the advanced SIMD instructions
> 
> Note: Microbenchmark results moved to a comment in the PR so we don't have to see it in every email.
> 
> Special thanks to the folks who have made many helpful comments while this PR was in draft form.

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  replace hi/lo word shuffles and left-right shift/or operations for vpshufd on byte-aligned rotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7702/files
  - new: https://git.openjdk.org/jdk/pull/7702/files/53b432e5..8d4b7ba7

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

  Stats: 66 lines in 2 files changed: 42 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/7702.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7702/head:pull/7702

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


From kdriver at openjdk.org  Thu Nov 10 20:14:34 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 10 Nov 2022 20:14:34 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
Message-ID: <fVA-ZqsPl__KNVc3Jz7AQqmKrOSwuAqiIutfwnUUyxE=.8918f59e-c2cc-4c5a-b507-3048740cadd5@github.com>

On Thu, 10 Nov 2022 17:59:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized `AlgorithmParameters`, but before you call `getEncoded` on it you need to remember to initialize the params. This is unfortunate but since this is a public API, I hesitate to make a change.
>> 
>> Instead, this code change fixes the much more widely used internal class `AlgorithmId` so that it cannot be created with an uninitialized `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both initialized and uninitialized params, and it's immutable.
>> 
>> No intention to make `AlgorithmId` immutable this time. It has a child class named `AlgIdDSA` which makes things complicated.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   expected

Marked as reviewed by kdriver (Author).

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

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


From jnimeh at openjdk.org  Thu Nov 10 20:15:14 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 10 Nov 2022 20:15:14 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v3]
In-Reply-To: <L1ZTSckdP_iY9bvifRX-00Qqw6VLq3sWU9k93TrLW_w=.fc29ffb4-78dc-4d31-b36c-c296e3f48a91@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <L1ZTSckdP_iY9bvifRX-00Qqw6VLq3sWU9k93TrLW_w=.fc29ffb4-78dc-4d31-b36c-c296e3f48a91@github.com>
Message-ID: <5clqVh13SSlaNtPkBJ67ufP2DF9vOWyPdWml63Zwbxs=.d0e836cf-15c7-4e3e-aace-2c2aabc2d345@github.com>

On Thu, 10 Nov 2022 20:11:46 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This PR delivers ChaCha20 intrinsics that accelerate the core block function that generates key stream from the key, counter and nonce.  Intrinsics have been written for the following platforms and instruction sets:
>> 
>> - x86_64: AVX, AVX2 and AVX512
>> - aarch64: platforms that support the advanced SIMD instructions
>> 
>> Note: Microbenchmark results moved to a comment in the PR so we don't have to see it in every email.
>> 
>> Special thanks to the folks who have made many helpful comments while this PR was in draft form.
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace hi/lo word shuffles and left-right shift/or operations for vpshufd on byte-aligned rotations

using vpshufb (not vpshufd as I typo'ed on my commit message) on AVX/AVX2 for 8-bit and 16-bit left rotations has given us some modest speed gains:
Before (with intrinsics):

AVX=1
ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s

AVX=2
ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s

After (using vpshufb):

AVX=1
Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
ChaCha20.encrypt                  256    thrpt   40  1447416.349 ? 14054.478  ops/s
ChaCha20.encrypt                 1024    thrpt   40   495844.721 ?  1949.237  ops/s
ChaCha20.encrypt                 4096    thrpt   40   138154.478 ?   411.707  ops/s         
ChaCha20.encrypt                16384    thrpt   40    35165.143 ?   110.483  ops/s

AVX=2
ChaCha20.encrypt                  256    thrpt   40  2020170.211 ? 10507.466  ops/s
ChaCha20.encrypt                 1024    thrpt   40   829644.325 ?  6452.931  ops/s
ChaCha20.encrypt                 4096    thrpt   40   246066.542 ?  1052.905  ops/s
ChaCha20.encrypt                16384    thrpt   40    64021.363 ?   468.979  ops/s

This was done on the same system that the original benchmarks were done on.  None of these changes affect AVX512.

I'm working on a hybrid intrinsic approach to get the best of both worlds for those smaller single-part jobs.

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

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


From sviswanathan at openjdk.org  Thu Nov 10 20:27:37 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 10 Nov 2022 20:27:37 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v3]
In-Reply-To: <5clqVh13SSlaNtPkBJ67ufP2DF9vOWyPdWml63Zwbxs=.d0e836cf-15c7-4e3e-aace-2c2aabc2d345@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <L1ZTSckdP_iY9bvifRX-00Qqw6VLq3sWU9k93TrLW_w=.fc29ffb4-78dc-4d31-b36c-c296e3f48a91@github.com>
 <5clqVh13SSlaNtPkBJ67ufP2DF9vOWyPdWml63Zwbxs=.d0e836cf-15c7-4e3e-aace-2c2aabc2d345@github.com>
Message-ID: <rSxsGLEA_OBsxEgEODIXOkRXAsRX6NqxBeg0FVDNUXs=.6bfa5642-750d-46f2-b74d-3e224690632b@github.com>

On Thu, 10 Nov 2022 20:12:30 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace hi/lo word shuffles and left-right shift/or operations for vpshufd on byte-aligned rotations
>
> using vpshufb (not vpshufd as I typo'ed on my commit message) on AVX/AVX2 for 8-bit and 16-bit left rotations has given us some modest speed gains:
> Before (with intrinsics):
> 
> AVX=1
> ChaCha20.encrypt                  256    thrpt   40  1338667.215 ? 12012.240  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   453682.363 ?  2559.322  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   124785.645 ?   394.535  ops/s
> ChaCha20.encrypt                16384    thrpt   40    31788.969 ?    90.770  ops/s
> 
> AVX=2
> ChaCha20.encrypt                  256    thrpt   40  1893810.127 ? 21870.718  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   758024.511 ?  5414.552  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   224032.805 ?   935.309  ops/s
> ChaCha20.encrypt                16384    thrpt   40    58112.296 ?   498.048  ops/s
> 
> After (using vpshufb):
> 
> AVX=1
> Benchmark                  (dataSize)     Mode  Cnt        Score       Error  Units
> ChaCha20.encrypt                  256    thrpt   40  1447416.349 ? 14054.478  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   495844.721 ?  1949.237  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   138154.478 ?   411.707  ops/s         
> ChaCha20.encrypt                16384    thrpt   40    35165.143 ?   110.483  ops/s
> 
> AVX=2
> ChaCha20.encrypt                  256    thrpt   40  2020170.211 ? 10507.466  ops/s
> ChaCha20.encrypt                 1024    thrpt   40   829644.325 ?  6452.931  ops/s
> ChaCha20.encrypt                 4096    thrpt   40   246066.542 ?  1052.905  ops/s
> ChaCha20.encrypt                16384    thrpt   40    64021.363 ?   468.979  ops/s
> 
> This was done on the same system that the original benchmarks were done on.  None of these changes affect AVX512.
> 
> I'm working on a hybrid intrinsic approach to get the best of both worlds for those smaller single-part jobs.

@jnimeh Very nice work overall. I think it would be ok to get this PR integrated and do the hybrid approach as a follow on PR. Your work in general shows very good improvement over base.

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

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


From mullan at openjdk.org  Thu Nov 10 20:28:54 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 20:28:54 GMT
Subject: RFR: 8296612: CertAttrSet is useless
In-Reply-To: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
References: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
Message-ID: <bH0wF2ND01uaH6GSYFqdArCOZ0VEB3QSgri2tpXQ-Lc=.2499e678-c341-41df-8fb6-5c57a533751f@github.com>

On Tue, 8 Nov 2022 22:42:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> - All `CertAttrSet` child classes now implement `DerEncoder`
> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate methods are removed
> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need to implement it
> - `X509CertImpl::encode(OutputStream out)` removed, used nowhere

Looks good. Issue should probably have `noreg-cleanup` label.

src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 220:

> 218:      * @exception IOException on encoding error.
> 219:      */
> 220:     public void encode(DerOutputStream out) throws IOException {

Add `@Override`.

src/java.base/share/classes/sun/security/pkcs10/PKCS10Attribute.java line 110:

> 108:      * @exception IOException on encoding errors.
> 109:      */
> 110:     public void encode(DerOutputStream out) throws IOException {

Add `@Override`.

src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 97:

> 95:      * @exception IOException on encoding errors.
> 96:      */
> 97:     public void encode(DerOutputStream out) throws IOException {

Add `@Override`.

src/java.base/share/classes/sun/security/util/DerEncoder.java line 43:

> 41:      * @param out  the stream on which the DER encoding is written.
> 42:      */
> 43:     void encode(DerOutputStream out)

Add `@Override`.

src/java.base/share/classes/sun/security/util/DerOutputStream.java line 585:

> 583:      *  @exception IOException on output error.
> 584:      */
> 585:     public void encode(DerOutputStream out) throws IOException {

Add `@Override`.

src/java.base/share/classes/sun/security/x509/AVA.java line 628:

> 626:      * @exception IOException on encoding error.
> 627:      */
> 628:     public void encode(DerOutputStream out) throws IOException {

Add `@Override`.

src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 276:

> 274:      * @exception IOException on encoding error.
> 275:      */
> 276:     public void encode(DerOutputStream out) throws IOException {

Add `@Override`.

test/langtools/tools/jdeps/jdkinternals/src/q/NoRepl.java line 31:

> 29: 
> 30: public class NoRepl implements DerEncoder {
> 31:     public void encode(DerOutputStream out) throws IOException {

Add `@Override`.

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

Marked as reviewed by mullan (Reviewer).

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


From mullan at openjdk.org  Thu Nov 10 20:43:39 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 20:43:39 GMT
Subject: RFR: 8296591: Signature benchmark [v2]
In-Reply-To: <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
 <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>
Message-ID: <MGIRX5HiDclFWmW-rCjI0s_kVgNuBuxI-fM7I0OIaPQ=.e9beb1ac-296c-4d63-b151-2ac1e1bf56f1@github.com>

On Tue, 8 Nov 2022 20:40:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the micro-benchmark code reviewed for EC signature algorithms?  The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use standard names

Since this test is named "Signatures", I have filed a follow-on issue to enhance this benchmark to support non-EC signatures: https://bugs.openjdk.org/browse/JDK-8296818. I would like to have that in the system, so that we don't forget about it.

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

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


From weijun at openjdk.org  Thu Nov 10 20:48:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 20:48:40 GMT
Subject: RFR: 8296612: CertAttrSet is useless
In-Reply-To: <bH0wF2ND01uaH6GSYFqdArCOZ0VEB3QSgri2tpXQ-Lc=.2499e678-c341-41df-8fb6-5c57a533751f@github.com>
References: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
 <bH0wF2ND01uaH6GSYFqdArCOZ0VEB3QSgri2tpXQ-Lc=.2499e678-c341-41df-8fb6-5c57a533751f@github.com>
Message-ID: <Mz_Ob9kyTPMUnp9ShC8jKcPlgWWYk7nsBUwJ1VrXoOY=.8f49b816-f472-479f-90d3-a8d7fdac92cb@github.com>

On Thu, 10 Nov 2022 20:24:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> - All `CertAttrSet` child classes now implement `DerEncoder`
>> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate methods are removed
>> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need to implement it
>> - `X509CertImpl::encode(OutputStream out)` removed, used nowhere
>
> src/java.base/share/classes/sun/security/util/DerEncoder.java line 43:
> 
>> 41:      * @param out  the stream on which the DER encoding is written.
>> 42:      */
>> 43:     void encode(DerOutputStream out)
> 
> Add `@Override`.

Not this one. :-)

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

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


From weijun at openjdk.org  Thu Nov 10 20:51:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 20:51:40 GMT
Subject: RFR: 8296612: CertAttrSet is useless [v2]
In-Reply-To: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
References: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
Message-ID: <u_FZA0hRwzFczvMrmwh8LDwZ1OlqkoF_vaTEUwTMhrg=.4a1c089a-d201-406c-a5cd-3f680567a210@github.com>

> - All `CertAttrSet` child classes now implement `DerEncoder`
> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate methods are removed
> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need to implement it
> - `X509CertImpl::encode(OutputStream out)` removed, used nowhere

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

  overrides

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11048/files
  - new: https://git.openjdk.org/jdk/pull/11048/files/889e728e..8ae5fcd0

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

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

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


From weijun at openjdk.org  Thu Nov 10 21:01:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 21:01:27 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <KnT1Xe8fsKw4L2GwAwVhhUZR7VS6hdyUYNiSc0WPrGE=.2e676597-2ec4-4733-8f1b-8406e3fbbcd2@github.com>

On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo <duke at openjdk.org> wrote:

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

I'm not sure. You can probably ask on jdk8u-dev at openjdk.java.net.

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

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


From mullan at openjdk.org  Thu Nov 10 21:12:31 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 21:12:31 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <ZIyMVSrvrcJL7cCkfeYGEo1Ti0uc8r--9seOCzpSTos=.12290c69-ddac-4f2a-a572-9f02d815d679@github.com>

On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo <duke at openjdk.org> wrote:

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

If you want to instead do some general cleanup in this class for JDK 20, you could instead remove this method and several other unused methods from `JarVerifier`.

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

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


From mullan at openjdk.org  Thu Nov 10 21:34:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 21:34:30 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <9dD51N9kpu4MV5_oJ1e6lxsYLxnk6mG5mQeH_SAzWqA=.71dcec22-0ad2-41f2-89e3-8c9964db61cb@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link.

+1.

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

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


From mullan at openjdk.org  Thu Nov 10 21:51:33 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 21:51:33 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <lnH8lsGsP0sRLWUGmddbSM9UzhX_K7-Bw5T630BuVB0=.8520b429-86fc-4397-8e27-5a65528b9e1c@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
 <lnH8lsGsP0sRLWUGmddbSM9UzhX_K7-Bw5T630BuVB0=.8520b429-86fc-4397-8e27-5a65528b9e1c@github.com>
Message-ID: <V9M6jc_CkPoqdIB55zd9mtBr8s1AuzCXcuRTWf70itU=.c5f3082c-5295-413f-a2f5-aad288476704@github.com>

On Thu, 10 Nov 2022 15:33:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ryan Wallace 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 branch 'master' into 8294526
>>  - Merge branch 'master' into 8294526
>>  - Merge branch 'master' into 8294526
>>  - 8294526: SubjectCodeSource is no longer referenced
>>  - Merge branch 'master' into 8294526
>>  - Merge branch 'openjdk:master' into 8294526
>>  - 8294526: SubjectCodeSource is no longer used, removing class and all references
>
> @ryawalla Have you or your company signed the OCA? I do not see `/signed` or `/covered` actions in this PR.

> @seanjmullan I thought I had resolved this as previously the OCA was failing jcheck, I am an Oracle employee. Should I still be adding /signed or /covered actions? This is my first change in the openjdk so my account may not be linked to the org correctly.

No, sorry for the false alarm, you should be all set then.

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

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


From mullan at openjdk.org  Thu Nov 10 21:53:33 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 21:53:33 GMT
Subject: RFR: 8296612: CertAttrSet is useless [v2]
In-Reply-To: <u_FZA0hRwzFczvMrmwh8LDwZ1OlqkoF_vaTEUwTMhrg=.4a1c089a-d201-406c-a5cd-3f680567a210@github.com>
References: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
 <u_FZA0hRwzFczvMrmwh8LDwZ1OlqkoF_vaTEUwTMhrg=.4a1c089a-d201-406c-a5cd-3f680567a210@github.com>
Message-ID: <JDZdFhPxRkNTpRjv2Faug6mcvrQ8MKBTMClCgQdWexk=.9d3eeccd-6e00-4bfc-8af7-fddf50bb7003@github.com>

On Thu, 10 Nov 2022 20:51:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> - All `CertAttrSet` child classes now implement `DerEncoder`
>> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate methods are removed
>> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need to implement it
>> - `X509CertImpl::encode(OutputStream out)` removed, used nowhere
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   overrides

Marked as reviewed by mullan (Reviewer).

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

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


From jjg at openjdk.org  Thu Nov 10 21:58:28 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 21:58:28 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Jon,
> 
> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html
> 
> External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)
> 
> You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

On keeping RFC in the title, I'll go with the team preference. I note that not all spec authorities have such a well-defined naming/numbering scheme, so it does make the summary page a bit inconsistent. Also, the entries under "R" dominate the list, which may not be what you want.

On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

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

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


From jjg at openjdk.org  Thu Nov 10 22:03:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:03:32 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <jribbsj15UipAgtqxLmb156zaVOdJJU4zaukxrE-8Bg=.7b4f4219-ceb9-4173-a341-6d6fe2229ddd@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

I can change the doclet to use a bulleted list when any spec titles contain a comma.

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

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


From xuelei at openjdk.org  Thu Nov 10 22:08:40 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 10 Nov 2022 22:08:40 GMT
Subject: RFR: 8296591: Signature benchmark [v2]
In-Reply-To: <MGIRX5HiDclFWmW-rCjI0s_kVgNuBuxI-fM7I0OIaPQ=.e9beb1ac-296c-4d63-b151-2ac1e1bf56f1@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
 <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>
 <MGIRX5HiDclFWmW-rCjI0s_kVgNuBuxI-fM7I0OIaPQ=.e9beb1ac-296c-4d63-b151-2ac1e1bf56f1@github.com>
Message-ID: <Er0Z1Ocsx8twYifPOz0pmsDZJfgAb4pSqRqR0d_bw60=.c11c0428-4ba1-4458-8edd-13f8f1fc7ae1@github.com>

On Thu, 10 Nov 2022 20:41:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Since this test is named "Signatures", I have filed a follow-on issue to enhance this benchmark to support non-EC signatures: https://bugs.openjdk.org/browse/JDK-8296818. I would like to have that in the system, so that we don't forget about it.

Thanks!

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

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


From jjg at openjdk.org  Thu Nov 10 22:11:30 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:11:30 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
Message-ID: <K4Z5QVATg9JlpZKp2HyIaHcMz_u24yhBOmw7RFkVmMo=.58dbad2c-e6cb-4fa5-857b-8c5bfb5007f0@github.com>

On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same spec will be linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped.
> 
> In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?
> 
> There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

The utility I mentioned has the (optional) ability to remove `@see` links when the text of the link exactly matches that used by the `@spec` tag.  Unfortunately, the text is typically not exactly the same, and would require manual analysis to see if the `@see` tag can be removed.

When inline references are used, the wording is very rarely the primary title of the spec: it is more likely to be a word or phrase that makes sense in the context of the enclosing sentence.

_History: version 1 of this feature tried replacing inline links and `@see` tags with a bi-modal `@spec` tag. The results were "not good", especially in the generated external-specs page.  Version 2 used a side file to provide the definitive title for each spec, but that was deemed to be too much of a maintenance issue. This is version 3, in which we've eliminated the side-file in favor of duplicating the title in each `@spec` tag._

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

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


From sviswanathan at openjdk.org  Thu Nov 10 22:14:36 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 10 Nov 2022 22:14:36 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v11]
In-Reply-To: <actl_ZA8F_vYPeNjov0QcGklPyBQjm-geVl1rPLtFpU=.c440119c-5b4e-4c98-9a57-4fa36785bcbf@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <actl_ZA8F_vYPeNjov0QcGklPyBQjm-geVl1rPLtFpU=.c440119c-5b4e-4c98-9a57-4fa36785bcbf@github.com>
Message-ID: <Jfk4uciCLP7dRECbUamzrwiLx1QFOjVUA5zXdSL8YCA=.2304f245-f6c2-4337-990e-b05749628b0f@github.com>

On Thu, 10 Nov 2022 01:22:04 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix windows and 32b linux builds

src/hotspot/share/opto/library_call.cpp line 6981:

> 6979: 
> 6980:   if (!stubAddr) return false;
> 6981:   Node* polyObj = argument(0);

Minor cleanup: This could be removed as it is not used.

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 28:

> 26: package com.sun.crypto.provider;
> 27: 
> 28: import java.lang.reflect.Field;

Minor cleanup: This could be removed.

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 249:

> 247:     @ForceInline
> 248:     @IntrinsicCandidate
> 249:     private void processMultipleBlocks(byte[] input, int offset, int length, long[] aLimbs, long[] rLimbs) {

A comment here to indicate aLimbs and rLimbs are part of a and r and used in intrinsic.

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 253:

> 251:             n.setValue(input, offset, BLOCK_LENGTH, (byte)0x01);
> 252:             a.setSum(n);                    // A += (temp | 0x01)
> 253:             a.setProduct(r);                // A =  (A * R) % p

Comment needs update to match code.

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

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


From jjg at openjdk.org  Thu Nov 10 22:19:26 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:19:26 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
Message-ID: <Dt2pqnepgR8UMT5ypzYkvgJRKKxNg8K8m-vu3OdEFg4=.2c04027c-f939-4972-8eca-345fc6f923bc@github.com>

On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 <duke at openjdk.org> wrote:

> did you changed 420 files ?

I ran a custom utility that edited these files, yes.

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

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


From weijun at openjdk.org  Thu Nov 10 22:28:33 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 22:28:33 GMT
Subject: Integrated: 8296612: CertAttrSet is useless
In-Reply-To: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
References: <X5ZKDO4bWiTUanXpUXntHzQzCNeZn_R6h1VByjEz4m4=.bd018a66-f15f-4d1a-b749-2fc6b0bb46ff@github.com>
Message-ID: <WA4C97M7JkeEhSjDqXZ5u919DzcoIBm74RnXP9fU6A4=.ff7208aa-aa78-49a9-a87e-9d2b6ec9f6bb@github.com>

On Tue, 8 Nov 2022 22:42:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> - All `CertAttrSet` child classes now implement `DerEncoder`
> - `DerEncoder::derEncode` is renamed to `DerEncoder::encode`, and duplicate methods are removed
> - `s.s.x.Extension` now implements `DerEncoder`, so its child classes no need to implement it
> - `X509CertImpl::encode(OutputStream out)` removed, used nowhere

This pull request has now been integrated.

Changeset: 27527b49
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27527b49752110fcfca285a1b6dd995d5d103fe5
Stats:     214 lines in 52 files changed: 11 ins; 134 del; 69 mod

8296612: CertAttrSet is useless

Reviewed-by: mullan

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

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


From duke at openjdk.org  Thu Nov 10 22:48:37 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 10 Nov 2022 22:48:37 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v12]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <URDJbHxq9xXluD7xtzFW3JoR3vFeEqFhIlcgCOV7ymQ=.e006e025-1c1e-4e24-b4c2-1ce834b1525b@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

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  Sandhya's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/abfc68f4..2176caf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=10-11

  Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 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  Thu Nov 10 22:48:38 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 10 Nov 2022 22:48:38 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v11]
In-Reply-To: <Jfk4uciCLP7dRECbUamzrwiLx1QFOjVUA5zXdSL8YCA=.2304f245-f6c2-4337-990e-b05749628b0f@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <actl_ZA8F_vYPeNjov0QcGklPyBQjm-geVl1rPLtFpU=.c440119c-5b4e-4c98-9a57-4fa36785bcbf@github.com>
 <Jfk4uciCLP7dRECbUamzrwiLx1QFOjVUA5zXdSL8YCA=.2304f245-f6c2-4337-990e-b05749628b0f@github.com>
Message-ID: <jvw805Op3RYdMVfMo_5yaK6RIEXNaLrKwPpSbB5leOI=.00976a93-ff6b-4d51-ac49-33b253fcd47a@github.com>

On Thu, 10 Nov 2022 22:03:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix windows and 32b linux builds
>
> src/hotspot/share/opto/library_call.cpp line 6981:
> 
>> 6979: 
>> 6980:   if (!stubAddr) return false;
>> 6981:   Node* polyObj = argument(0);
> 
> Minor cleanup: This could be removed as it is not used.

done

> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 28:
> 
>> 26: package com.sun.crypto.provider;
>> 27: 
>> 28: import java.lang.reflect.Field;
> 
> Minor cleanup: This could be removed.

done

> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 249:
> 
>> 247:     @ForceInline
>> 248:     @IntrinsicCandidate
>> 249:     private void processMultipleBlocks(byte[] input, int offset, int length, long[] aLimbs, long[] rLimbs) {
> 
> A comment here to indicate aLimbs and rLimbs are part of a and r and used in intrinsic.

done

> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 253:
> 
>> 251:             n.setValue(input, offset, BLOCK_LENGTH, (byte)0x01);
>> 252:             a.setSum(n);                    // A += (temp | 0x01)
>> 253:             a.setProduct(r);                // A =  (A * R) % p
> 
> Comment needs update to match code.

done

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

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


From duke at openjdk.org  Thu Nov 10 22:59:52 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 10 Nov 2022 22:59:52 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v13]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <AdNrtqNSMPZSK_Tfbr4q-YNlelgx8AEVeDtn-4EoV6Y=.15cead8f-06fd-40bd-9e39-fbb7ecc2cbd6@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

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  jcheck

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/2176caf8..196ee35b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=11-12

  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 naoto at openjdk.org  Thu Nov 10 23:55:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Nov 2022 23:55:34 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/java.base/share/classes/java/lang/Character.java line 172:

> 170:  * occur. For example, in a future release, synchronization may fail.
> 171:  *
> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0

This should probably be removed, as the original link (explaining `U+n` notation) is broken.

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

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


From egahlin at openjdk.org  Fri Nov 11 00:17:07 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Nov 2022 00:17:07 GMT
Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly
 [v2]
In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
Message-ID: <ftvUWPh0MP_iEeiswUa4oQjwsXiF9BlXoJifuSeuLWY=.1971f488-23c4-4243-9768-299532be3fe4@github.com>

> Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool.
> 
> Testing:
> test/jdk/jdk/jfr
> test/jdk/jdk/security/logging/
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - Initial

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

Changes: https://git.openjdk.org/jdk/pull/11039/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11039&range=01
  Stats: 77 lines in 15 files changed: 37 ins; 1 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/11039.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11039/head:pull/11039

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


From egahlin at openjdk.org  Fri Nov 11 00:24:38 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Nov 2022 00:24:38 GMT
Subject: Withdrawn: 8296229: JFR: jfr tool should print unsigned values
 correctly
In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com>
Message-ID: <20MAo47rnhTgoC4A5u1zUZ2IlUgV8WaJN8CnNA2z-ck=.aacf45b6-8987-43b6-91eb-cb8c6a92bf7c@github.com>

On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool.
> 
> Testing:
> test/jdk/jdk/jfr
> test/jdk/jdk/security/logging/
> 
> Thanks
> Erik

This pull request has been closed without being integrated.

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

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


From valeriep at openjdk.org  Fri Nov 11 00:33:16 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 11 Nov 2022 00:33:16 GMT
Subject: RFR: 8296741: Illegal X400Address and EDIPartyName should not be
 created [v2]
In-Reply-To: <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
References: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
 <9Dn9TG-sG7-9sNGgjOFCwj3swSCo5KQIBLnA-TWXUJM=.8ff4e916-3b2e-4bfc-a7e2-a642234e251a@github.com>
Message-ID: <2hBSZVkT7T4NczyjvEh8vORpO3gm04nDK2LgAPwOLqs=.408a76aa-6bee-4cd2-8b8a-76721f4a105e@github.com>

On Wed, 9 Nov 2022 22:44:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> `EDIPartyName` should not have a null `partyName`.
>> 
>> Inside `X400Name` it should be a `DerValue` instead of arbitrary byte array. Note: in `GeneralSubtrees.java`, an `X400Name` is created with a null content. This would lead to an NPE anyway. A future fix might be needed.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test
>   
>   only in patch2:
>   unchanged:

Marked as reviewed by valeriep (Reviewer).

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

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


From mpowers at openjdk.org  Fri Nov 11 01:13:55 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 11 Nov 2022 01:13:55 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <SNE_8TXNUBXglCojrEvU0VW4SA3Dp7JkmFXBrS7YESE=.cef7eab7-d034-4c76-8d5b-7b19594c2d61@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
 <SNE_8TXNUBXglCojrEvU0VW4SA3Dp7JkmFXBrS7YESE=.cef7eab7-d034-4c76-8d5b-7b19594c2d61@github.com>
Message-ID: <Q_2RkU3VdDzS4pQoLPqSkdvMbWpwG0GPIqBMVO1HmaA=.264f5672-2990-4439-9ce2-a7bf52ebd0b2@github.com>

On Mon, 31 Oct 2022 07:48:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293412
>
> 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.

Backing out change.

> 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

Backing out change. I hadn't considered the fact that this test might be run on slower hardware.

> 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

Backing out change.

> 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

Backing out change.

> 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

Backing out change.

> 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

Backing out change.

> 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

Backing out change.

> 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

Backing out change.

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

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


From duke at openjdk.org  Fri Nov 11 01:14:05 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 11 Nov 2022 01:14:05 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@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

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  live review with Sandhya

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/196ee35b..835fbe3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=12-13

  Stats: 32 lines in 3 files changed: 17 ins; 5 del; 10 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  Fri Nov 11 01:15:50 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 11 Nov 2022 01:15:50 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
Message-ID: <u8IaTPa5e5J-O6dtaDV9-zOuUUHPoQ3AchQ6qLSS2dM=.a38d7196-3013-4b39-9041-fed05a7eaf53@github.com>

On Fri, 11 Nov 2022 01:14:05 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   live review with Sandhya

Marked as reviewed by sviswanathan (Reviewer).

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

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


From sviswanathan at openjdk.org  Fri Nov 11 01:21:42 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 11 Nov 2022 01:21:42 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
Message-ID: <yhyVyecBWACPQcMw06SAb-j6RE57JMuoaphKaXnsWOY=.6ee2397b-c367-403b-af10-4da77da67171@github.com>

On Fri, 11 Nov 2022 01:14:05 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   live review with Sandhya

The PR looks good to me.
@ascarpino Please let us know if the Java side changes look good to you.
@iwanowww Please let us know if the compiler side changes look good to you.

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

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


From mpowers at openjdk.org  Fri Nov 11 01:24:46 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 11 Nov 2022 01:24:46 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <Q_2RkU3VdDzS4pQoLPqSkdvMbWpwG0GPIqBMVO1HmaA=.264f5672-2990-4439-9ce2-a7bf52ebd0b2@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
 <SNE_8TXNUBXglCojrEvU0VW4SA3Dp7JkmFXBrS7YESE=.cef7eab7-d034-4c76-8d5b-7b19594c2d61@github.com>
 <Q_2RkU3VdDzS4pQoLPqSkdvMbWpwG0GPIqBMVO1HmaA=.264f5672-2990-4439-9ce2-a7bf52ebd0b2@github.com>
Message-ID: <E1_4ycMBNEtrx2visvqKUlyf-CWg6_m3-_tW8yOIR7A=.cab7ecd6-c1e8-47b6-9b53-674c1cb6654e@github.com>

On Fri, 11 Nov 2022 01:10:54 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> 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
>
> Backing out change.

Changed to /dev/urandom.

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

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


From vlivanov at openjdk.org  Fri Nov 11 01:47:41 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 11 Nov 2022 01:47:41 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
Message-ID: <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>

On Fri, 11 Nov 2022 01:14:05 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   live review with Sandhya

Overall, it looks good.

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 733:

> 731:   void andptr(Register src1, Register src2) { LP64_ONLY(andq(src1, src2)) NOT_LP64(andl(src1, src2)) ; }
> 732: 
> 733: #ifdef _LP64

Why is it x64-specific?

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 161:

> 159:   const XMMRegister P2_H = xmm5;
> 160:   const XMMRegister TMP1 = xmm6;
> 161:   const Register polyCP = r13;

Could be renamed to `rscratch` (or `tmp`) since it doesn't hold constant base address anymore.

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

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


From vlivanov at openjdk.org  Fri Nov 11 01:47:41 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 11 Nov 2022 01:47:41 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v11]
In-Reply-To: <jvw805Op3RYdMVfMo_5yaK6RIEXNaLrKwPpSbB5leOI=.00976a93-ff6b-4d51-ac49-33b253fcd47a@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <actl_ZA8F_vYPeNjov0QcGklPyBQjm-geVl1rPLtFpU=.c440119c-5b4e-4c98-9a57-4fa36785bcbf@github.com>
 <Jfk4uciCLP7dRECbUamzrwiLx1QFOjVUA5zXdSL8YCA=.2304f245-f6c2-4337-990e-b05749628b0f@github.com>
 <jvw805Op3RYdMVfMo_5yaK6RIEXNaLrKwPpSbB5leOI=.00976a93-ff6b-4d51-ac49-33b253fcd47a@github.com>
Message-ID: <CiSy3vj4B8bpA2sKwl4_wy3aLJimuejwiOR0VyHmTzU=.0141180c-780c-49fd-8ce5-b5879a629242@github.com>

On Thu, 10 Nov 2022 22:41:31 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 249:
>> 
>>> 247:     @ForceInline
>>> 248:     @IntrinsicCandidate
>>> 249:     private void processMultipleBlocks(byte[] input, int offset, int length, long[] aLimbs, long[] rLimbs) {
>> 
>> A comment here to indicate aLimbs and rLimbs are part of a and r and used in intrinsic.
>
> done

Overall, it looks weird to see aLimbs/rLimbs being unused, but I see why it is so. If security folks are fine with that, I'm OK with it as well.

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

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


From vlivanov at openjdk.org  Fri Nov 11 01:47:42 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 11 Nov 2022 01:47:42 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v13]
In-Reply-To: <AdNrtqNSMPZSK_Tfbr4q-YNlelgx8AEVeDtn-4EoV6Y=.15cead8f-06fd-40bd-9e39-fbb7ecc2cbd6@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <AdNrtqNSMPZSK_Tfbr4q-YNlelgx8AEVeDtn-4EoV6Y=.15cead8f-06fd-40bd-9e39-fbb7ecc2cbd6@github.com>
Message-ID: <S8GnNjm6Y0ggYmpkr3b0rCYNnOIm0zyZoUqwGA-MAbk=.4fffdc3e-e5f3-498c-84c0-3c3719cc9e14@github.com>

On Thu, 10 Nov 2022 22:59:52 GMT, Volodymyr Paprotski <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
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 252:

> 250:     private void processMultipleBlocks(byte[] input, int offset, int length, long[] aLimbs, long[] rLimbs) {
> 251:         while (length >= BLOCK_LENGTH) {
> 252:             n.setValue(input, offset, BLOCK_LENGTH, (byte)0x01);

You could call `processBlock(input, offset, BLOCK_LENGTH);` here.

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

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


From cjplummer at openjdk.org  Fri Nov 11 04:18:30 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Nov 2022 04:18:30 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <FVrTbaSxMtpBDeg9b-elYkMoCM_M72PLSAQGVplwe1Q=.44879b38-e84d-436d-a23c-43f2522acf9e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java line 105:

> 103:      *          If the length of the packet (as indictaed by the first
> 104:      *          4 bytes) is less than 11 bytes, or an I/O error occurs.
> 105:      * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/com/sun/jdi/connect/spi/Connection.html#readPacket()

Within this javadoc page the jdwp-spec.html references are titled "JDWP Specification", but these `@spec` references are titled "Java Debug Wire Protocol". I suggest making them more consistent. There is one more case below and this same issue also applies to TransportService.java. Perhaps the title in jdwp-spec.html should be updated. I think "Java Debug Wire Protocol (JDWP) Specification" would be good.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java line 79:

> 77:  * target VM.
> 78:  *
> 79:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

See above comment for Connection.java.

src/jdk.jdi/share/classes/module-info.java line 107:

> 105:  *
> 106:  *
> 107:  * @spec jpda/jpda.html Java Platform Debugger Architecture

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/module-summary.html

`@spec` and `@see` sections end up one right after the other with the same content, except the `@see` section has the preferred hyperlink title. Suggest you remove the `@see` section and also update `@spec` hyperlink title to include "(JPDA)", or update the actual title in the jpda.html doc so it includes "(JPDA)" in it and then rerun your tool.

src/jdk.jdwp.agent/share/classes/module-info.java line 30:

> 28:  *
> 29:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 30:  * @spec jdwp/jdwp-transport.html Java Debug Wire Protocol Transport Interface (jdwpTransport)

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdwp.agent/module-summary.html

The end result here is not very clean. You have the same two specs being referred to just a few lines apart, and the hyperlink titles are not even close to be the same, even though the links are the same. Maybe the "@see" section should be removed.

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

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


From dfuchs at openjdk.org  Fri Nov 11 10:29:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 10:29:33 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
Message-ID: <WspQupF8fnStNO87pH42-2xTdbEwWYmiAcWuG2m3PSQ=.2d639a08-534c-4e41-aef9-287e4ab11a54@github.com>

On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

It's not uncommon for a newer version of a RFC to change its number but keep its title. I see that the links in the class level API documentation both have the RFC number in their link text. Somehow that was stripped by your tool - possibly because it tried to extract some meta information from the linked page itself?

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

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


From lancea at openjdk.org  Fri Nov 11 11:49:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 11 Nov 2022 11:49:32 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

I only looked at the jar specific updates but there is some duplication leftovers.

It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

src/java.base/share/classes/java/util/jar/Attributes.java line 58:

> 56:  * order that keys were inserted into the map, as with {@link LinkedHashMap}.
> 57:  *
> 58:  * @spec jar/jar.html JAR File Specification

Line 52 should be removed

src/java.base/share/classes/java/util/jar/Attributes.java line 450:

> 448:      * <a href="{@docRoot}/../specs/jar/jar.html">JAR File Specification</a>
> 449:      * for more information about valid attribute names and values.
> 450:      * @spec jar/jar.html JAR File Specification

Line 448 should be removed

src/java.base/share/classes/java/util/jar/Manifest.java line 47:

> 45:  * Manifest format specification</a>.
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 44 should be removed

src/java.base/share/classes/java/util/jar/package-info.java line 47:

> 45:  * </ul>
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 43 should be removed

src/java.base/share/classes/java/util/zip/package-info.java line 75:

> 73:  * </ul>
> 74:  *
> 75:  * @spec https://www.ietf.org/rfc/rfc1951.html DEFLATE Compressed Data Format Specification version 1.3

The above references should be removed as they duplicate the` @spec` tags

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

Changes requested by lancea (Reviewer).

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


From dfuchs at openjdk.org  Fri Nov 11 12:01:42 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 12:01:42 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
Message-ID: <siwyjzUschdL9bJ_M4fdQDfY59oCJ0aAZGwncWho3cM=.8fd36fb3-4f95-4f55-a353-d15df9e4078f@github.com>

On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

Leaving out the non-public and non-exported classes would also reduce the PR size.

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

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


From duke at openjdk.org  Fri Nov 11 14:01:02 2022
From: duke at openjdk.org (pandaapo)
Date: Fri, 11 Nov 2022 14:01:02 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <ZIyMVSrvrcJL7cCkfeYGEo1Ti0uc8r--9seOCzpSTos=.12290c69-ddac-4f2a-a572-9f02d815d679@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <ZIyMVSrvrcJL7cCkfeYGEo1Ti0uc8r--9seOCzpSTos=.12290c69-ddac-4f2a-a572-9f02d815d679@github.com>
Message-ID: <1SgjlQatBEnDkM7SKknVvONQZlTwxTM_1fQemk4-MbY=.14a019db-58c0-4dc8-af74-2b7d294c766c@github.com>

On Thu, 10 Nov 2022 21:08:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If you want to instead do some general cleanup in this class for JDK 20, you could instead remove this method and several other unused methods from `JarVerifier`.

Before I began to make general cleanup, I looked up from this unused method `JarVerifier#mapSignersToCodeSource()`and found all related call stacks:
![?????](https://user-images.githubusercontent.com/35672972/201353836-9151ddfa-10c5-4ecc-96f8-f8aa0c7e2798.png)
Can I remove these methods in `JarFile`, `JavaUtilJarAccess` and its only implementation `JavaUtilJarAccessImpl`?

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

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


From duke at openjdk.org  Fri Nov 11 17:56:55 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 11 Nov 2022 17:56:55 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v15]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <g9b4K88VLczZ7zoHN0oisP9Qju0EvlQWW5voCyJlGPQ=.6363291f-20aa-4fbc-9a81-96af9b54c76f@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

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  Vladimir's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/835fbe3a..2a225e42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=13-14

  Stats: 23 lines in 2 files changed: 0 ins; 2 del; 21 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 Nov 11 18:12:20 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 11 Nov 2022 18:12:20 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
 <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>
Message-ID: <IgOknAH9HUWa5VQropGAIp7I5QXLUGf6IspI_QVEe-Q=.85cfcc50-3c66-4fd3-b23a-65c40bb87423@github.com>

On Fri, 11 Nov 2022 01:26:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   live review with Sandhya
>
> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 733:
> 
>> 731:   void andptr(Register src1, Register src2) { LP64_ONLY(andq(src1, src2)) NOT_LP64(andl(src1, src2)) ; }
>> 732: 
>> 733: #ifdef _LP64
> 
> Why is it x64-specific?

I believe its needed.

TLDR.. Couple of check ins ago, I broke the 32-bit build, and that was the 'easy' fix..

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 161:
> 
>> 159:   const XMMRegister P2_H = xmm5;
>> 160:   const XMMRegister TMP1 = xmm6;
>> 161:   const Register polyCP = r13;
> 
> Could be renamed to `rscratch` (or `tmp`) since it doesn't hold constant base address anymore.

done

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

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


From duke at openjdk.org  Fri Nov 11 18:12:23 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 11 Nov 2022 18:12:23 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v13]
In-Reply-To: <S8GnNjm6Y0ggYmpkr3b0rCYNnOIm0zyZoUqwGA-MAbk=.4fffdc3e-e5f3-498c-84c0-3c3719cc9e14@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <AdNrtqNSMPZSK_Tfbr4q-YNlelgx8AEVeDtn-4EoV6Y=.15cead8f-06fd-40bd-9e39-fbb7ecc2cbd6@github.com>
 <S8GnNjm6Y0ggYmpkr3b0rCYNnOIm0zyZoUqwGA-MAbk=.4fffdc3e-e5f3-498c-84c0-3c3719cc9e14@github.com>
Message-ID: <Une2D1sgxDyIg6YkPyIWxOg4MwrnGeWYw8TeRrlwIk0=.363a0d24-6822-49b9-962a-338d5f784b37@github.com>

On Fri, 11 Nov 2022 01:25:07 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jcheck
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 252:
> 
>> 250:     private void processMultipleBlocks(byte[] input, int offset, int length, long[] aLimbs, long[] rLimbs) {
>> 251:         while (length >= BLOCK_LENGTH) {
>> 252:             n.setValue(input, offset, BLOCK_LENGTH, (byte)0x01);
> 
> You could call `processBlock(input, offset, BLOCK_LENGTH);` here.

done (duh.. thanks, neater code)

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

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


From vlivanov at openjdk.org  Fri Nov 11 20:01:34 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 11 Nov 2022 20:01:34 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <IgOknAH9HUWa5VQropGAIp7I5QXLUGf6IspI_QVEe-Q=.85cfcc50-3c66-4fd3-b23a-65c40bb87423@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
 <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>
 <IgOknAH9HUWa5VQropGAIp7I5QXLUGf6IspI_QVEe-Q=.85cfcc50-3c66-4fd3-b23a-65c40bb87423@github.com>
Message-ID: <orY8dXwBoWdbN04iP_wTouuDWQl9aqjOFV9APiHY3Dc=.32ab3d07-8d44-4f04-85bd-cc51eb61f414@github.com>

On Fri, 11 Nov 2022 18:08:50 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 733:
>> 
>>> 731:   void andptr(Register src1, Register src2) { LP64_ONLY(andq(src1, src2)) NOT_LP64(andl(src1, src2)) ; }
>>> 732: 
>>> 733: #ifdef _LP64
>> 
>> Why is it x64-specific?
>
> I believe its needed.
> 
> TLDR.. Couple of check ins ago, I broke the 32-bit build, and that was the 'easy' fix..

Right, `addq` instructions are x64-specific. I was confused because `assembler_x86.hpp` doesn't declare them as such which is a bug.

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

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


From duke at openjdk.org  Fri Nov 11 20:10:33 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 11 Nov 2022 20:10:33 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <orY8dXwBoWdbN04iP_wTouuDWQl9aqjOFV9APiHY3Dc=.32ab3d07-8d44-4f04-85bd-cc51eb61f414@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
 <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>
 <IgOknAH9HUWa5VQropGAIp7I5QXLUGf6IspI_QVEe-Q=.85cfcc50-3c66-4fd3-b23a-65c40bb87423@github.com>
 <orY8dXwBoWdbN04iP_wTouuDWQl9aqjOFV9APiHY3Dc=.32ab3d07-8d44-4f04-85bd-cc51eb61f414@github.com>
Message-ID: <ocwevLqOwgHaiJ46CLgPJFVvDcalz4PWPjREnWQ20A4=.187a1435-ee73-44a5-a15f-f4dc2e9e4a2e@github.com>

On Fri, 11 Nov 2022 19:56:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I believe its needed.
>> 
>> TLDR.. Couple of check ins ago, I broke the 32-bit build, and that was the 'easy' fix..
>
> Right, `addq` instructions are x64-specific. I was confused because `assembler_x86.hpp` doesn't declare them as such which is a bug.

I am mystified at how it actually gets removed from the `assembler_x86.o` object on 32-bit.. The only reliable/portable way _would_ be with `#ifdef` but its not there.. so.. code-generation? `sed`-like preprocessing? Can one edit object files after the gcc ran? The build must be doing something clever!! Haven't seen it yet.. 

Whatever the trick is, `assembler_x86.hpp` gets it, but not `macroAssembler_x86.hpp`.

If it doesn't ring any bells, maybe I will spend some more time looking at the traces, maybe can figure out what the build script is doing to remove the symbol.

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

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


From vlivanov at openjdk.org  Fri Nov 11 20:38:33 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 11 Nov 2022 20:38:33 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <ocwevLqOwgHaiJ46CLgPJFVvDcalz4PWPjREnWQ20A4=.187a1435-ee73-44a5-a15f-f4dc2e9e4a2e@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
 <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>
 <IgOknAH9HUWa5VQropGAIp7I5QXLUGf6IspI_QVEe-Q=.85cfcc50-3c66-4fd3-b23a-65c40bb87423@github.com>
 <orY8dXwBoWdbN04iP_wTouuDWQl9aqjOFV9APiHY3Dc=.32ab3d07-8d44-4f04-85bd-cc51eb61f414@github.com>
 <ocwevLqOwgHaiJ46CLgPJFVvDcalz4PWPjREnWQ20A4=.187a1435-ee73-44a5-a15f-f4dc2e9e4a2e@github.com>
Message-ID: <pYQs4FMpxhCrhceVFxyy7tvGrPG3t8RzbKfSOSPyzbs=.e3b7e01d-bbd7-4f73-bf57-245389bd5ec1@github.com>

On Fri, 11 Nov 2022 20:08:27 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Right, `addq` instructions are x64-specific. I was confused because `assembler_x86.hpp` doesn't declare them as such which is a bug.
>
> I am mystified at how it actually gets removed from the `assembler_x86.o` object on 32-bit.. The only reliable/portable way _would_ be with `#ifdef` but its not there.. so.. code-generation? `sed`-like preprocessing? Can one edit object files after the gcc ran? The build must be doing something clever!! Haven't seen it yet.. 
> 
> Whatever the trick is, `assembler_x86.hpp` gets it, but not `macroAssembler_x86.hpp`.
> 
> If it doesn't ring any bells, maybe I will spend some more time looking at the traces, maybe can figure out what the build script is doing to remove the symbol.

It's not specific to `andq`: there's a huge `#ifdef` block around the definitions in `assembler_x86.hpp` (lines 12201 - 13773; and there's even a nested `#ifdef _LP64` (lines 13515-13585)!) , but declarations aren't guarded by `#ifdef _LP64`.

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

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


From duke at openjdk.org  Fri Nov 11 20:49:40 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 11 Nov 2022 20:49:40 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <pYQs4FMpxhCrhceVFxyy7tvGrPG3t8RzbKfSOSPyzbs=.e3b7e01d-bbd7-4f73-bf57-245389bd5ec1@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
 <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>
 <IgOknAH9HUWa5VQropGAIp7I5QXLUGf6IspI_QVEe-Q=.85cfcc50-3c66-4fd3-b23a-65c40bb87423@github.com>
 <orY8dXwBoWdbN04iP_wTouuDWQl9aqjOFV9APiHY3Dc=.32ab3d07-8d44-4f04-85bd-cc51eb61f414@github.com>
 <ocwevLqOwgHaiJ46CLgPJFVvDcalz4PWPjREnWQ20A4=.187a1435-ee73-44a5-a15f-f4dc2e9e4a2e@github.com>
 <pYQs4FMpxhCrhceVFxyy7tvGrPG3t8RzbKfSOSPyzbs=.e3b7e01d-bbd7-4f73-bf57-245389bd5ec1@github.com>
Message-ID: <hp3DuRUsHA39f-YoJ2AuxY-7ZcVPKDTFXFVB46xsDBo=.d077e145-3b07-43c5-93f4-6d00c29f101f@github.com>

On Fri, 11 Nov 2022 20:34:34 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I am mystified at how it actually gets removed from the `assembler_x86.o` object on 32-bit.. The only reliable/portable way _would_ be with `#ifdef` but its not there.. so.. code-generation? `sed`-like preprocessing? Can one edit object files after the gcc ran? The build must be doing something clever!! Haven't seen it yet.. 
>> 
>> Whatever the trick is, `assembler_x86.hpp` gets it, but not `macroAssembler_x86.hpp`.
>> 
>> If it doesn't ring any bells, maybe I will spend some more time looking at the traces, maybe can figure out what the build script is doing to remove the symbol.
>
> It's not specific to `andq`: there's a huge `#ifdef` block around the definitions in `assembler_x86.hpp` (lines 12201 - 13773; and there's even a nested `#ifdef _LP64` (lines 13515-13585)!) , but declarations aren't guarded by `#ifdef _LP64`.

Yeah, just got to about the same conclusion by looking at the preprocessor `-E` output.. its declared in the header, but not defined in the 'cpp' file.. One would think that that's a compile error, but its been more then a decade since I looked at the C++ spec; 'C++ compiler is always right'.

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

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


From ascarpino at openjdk.org  Fri Nov 11 23:26:38 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 11 Nov 2022 23:26:38 GMT
Subject: RFR: 8296591: Signature benchmark [v2]
In-Reply-To: <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
 <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>
Message-ID: <rLFKf9nnXrIIhO7speTUBQBDL4BLRtMIZYhuc4wDm70=.c90e9756-5ce4-45c3-8890-f02520654a7c@github.com>

On Tue, 8 Nov 2022 20:40:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the micro-benchmark code reviewed for EC signature algorithms?  The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use standard names

Unfortunately I didn't catch this until it was too late.  There is an existing signature test that now there is overlap with  javax.crypto.SignatureBench, which supported secp256, Ed25519 & Ed448, as well as RSA and DSA

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

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


From xuelei at openjdk.org  Sat Nov 12 02:06:39 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 12 Nov 2022 02:06:39 GMT
Subject: RFR: 8296591: Signature benchmark [v2]
In-Reply-To: <rLFKf9nnXrIIhO7speTUBQBDL4BLRtMIZYhuc4wDm70=.c90e9756-5ce4-45c3-8890-f02520654a7c@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
 <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>
 <rLFKf9nnXrIIhO7speTUBQBDL4BLRtMIZYhuc4wDm70=.c90e9756-5ce4-45c3-8890-f02520654a7c@github.com>
Message-ID: <ZH6TtAUSCBsILD8gx7dClgtHGlO9efa6Jr8WbGNCNzs=.2b5c33ad-fb00-45a9-a38b-c6c882ba9cfb@github.com>

On Fri, 11 Nov 2022 23:22:42 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Unfortunately I didn't catch this until it was too late. There is an existing signature test, javax.crypto.[small | full].SignatureBench, which supported secp256, Ed25519 & Ed448, as well as RSA and DSA

Thanks for the information.   I will see if I could merge them into one.  Thanks!

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

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


From xuelei at openjdk.org  Sat Nov 12 02:38:40 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 12 Nov 2022 02:38:40 GMT
Subject: RFR: 8296591: Signature benchmark [v2]
In-Reply-To: <ZH6TtAUSCBsILD8gx7dClgtHGlO9efa6Jr8WbGNCNzs=.2b5c33ad-fb00-45a9-a38b-c6c882ba9cfb@github.com>
References: <s_w8cKoQ3mU-_xsDZBo0iI55CWxhudGHMEv93XU28tY=.e57de890-17b7-41d0-ba89-e1578314f63a@github.com>
 <UHnWWhUmDrtUCyvkJSBE2GPd6m_yhWY6gC4uHtAlfM4=.48badda7-6547-458e-b535-1e973165251c@github.com>
 <rLFKf9nnXrIIhO7speTUBQBDL4BLRtMIZYhuc4wDm70=.c90e9756-5ce4-45c3-8890-f02520654a7c@github.com>
 <ZH6TtAUSCBsILD8gx7dClgtHGlO9efa6Jr8WbGNCNzs=.2b5c33ad-fb00-45a9-a38b-c6c882ba9cfb@github.com>
Message-ID: <zROzU1qFXZdgnAkoTVFkVclBvS5TY9q_jd9zOeTlk0M=.363d8b18-23dd-4867-8d89-c2ce83a57774@github.com>

On Sat, 12 Nov 2022 02:01:50 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > Unfortunately I didn't catch this until it was too late. There is an existing signature test, javax.crypto.[small | full].SignatureBench, which supported secp256, Ed25519 & Ed448, as well as RSA and DSA
> 
> Thanks for the information. I will see if I could merge them into one. Thanks!

The javax.crypto.[small | full].SignatureBench measure the multiple signature operations (create object, initialization, sign, etc).  The new only measure the sign operation.  I would like to have both.

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

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


From jwaters at openjdk.org  Sat Nov 12 16:45:19 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 12 Nov 2022 16:45:19 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language features
Message-ID: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>

After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cases were caught by the very briefly integrated 8296115

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

Commit messages:
 - More Style Changes
 - Minor Style Changes
 - Merge remote-tracking branch 'upstream/master' into conformance
 - Missed an attribute
 - Oops v2
 - Resolve Conflict
 - This will likely fail, but that's not important
 - Further formatting
 - Merge jdkMerge remote-tracking branch 'upstream/master' into warnings
 - Code style
 - ... and 53 more: https://git.openjdk.org/jdk/compare/657a0b2f...6d85c432

Changes: https://git.openjdk.org/jdk/pull/11081/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295146
  Stats: 254 lines in 48 files changed: 100 ins; 23 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/11081.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11081/head:pull/11081

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


From xuelei at openjdk.org  Sat Nov 12 18:26:37 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 12 Nov 2022 18:26:37 GMT
Subject: RFR: 8296809: KeyPairGenerator benchmark
In-Reply-To: <_NjvHR31wUV6k9GdXHO5wy8F_H-AwrbZ6141poHbxsM=.811c8a84-4d75-4b3f-813e-656160bb1c2f@github.com>
References: <_NjvHR31wUV6k9GdXHO5wy8F_H-AwrbZ6141poHbxsM=.811c8a84-4d75-4b3f-813e-656160bb1c2f@github.com>
Message-ID: <qhJNDADRk9DAfP79L3rwIr9cNtC6cm9aIXRNEXLwtT0=.c73805f4-9fbf-4065-9b6c-b54fff536ca7@github.com>

On Thu, 10 Nov 2022 18:31:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the micro-benchmark code reviewed for EC key pair generation algorithms? The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.
> 
> Thanks,
> Xuelei

There are existing benchmarking cases for key pair generation (test/micro/org/openjdk/bench/javax/crypto/full/KeyPairGeneratorBench.java).

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

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


From xuelei at openjdk.org  Sat Nov 12 18:26:37 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 12 Nov 2022 18:26:37 GMT
Subject: Withdrawn: 8296809: KeyPairGenerator benchmark
In-Reply-To: <_NjvHR31wUV6k9GdXHO5wy8F_H-AwrbZ6141poHbxsM=.811c8a84-4d75-4b3f-813e-656160bb1c2f@github.com>
References: <_NjvHR31wUV6k9GdXHO5wy8F_H-AwrbZ6141poHbxsM=.811c8a84-4d75-4b3f-813e-656160bb1c2f@github.com>
Message-ID: <m86gzn7b8_5fTzYFNebR2nTWi3AxnkyVR-87LsGTZ7c=.a8d374dc-f2fe-4c22-ba55-06f9c4b740be@github.com>

On Thu, 10 Nov 2022 18:31:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have the micro-benchmark code reviewed for EC key pair generation algorithms? The benchmarking now is focused on EC algorithms, more algorithms (e.g., RSA/PSS based) may be added later if needed.
> 
> Thanks,
> Xuelei

This pull request has been closed without being integrated.

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

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


From xuelei at openjdk.org  Sat Nov 12 18:50:48 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 12 Nov 2022 18:50:48 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v5]
In-Reply-To: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
Message-ID: <zy3TTIXRNVqYtClcyBxzO2NaeLQ3EePn803l5IlwyRA=.0f81351c-9ed9-42a3-9f33-475bcb408da4@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:

  remove duplicated benchmark case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10544/files
  - new: https://git.openjdk.org/jdk/pull/10544/files/79fe697f..395d6e86

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

  Stats: 73 lines in 1 file changed: 0 ins; 73 del; 0 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 Nov 12 18:52:59 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 12 Nov 2022 18:52:59 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v6]
In-Reply-To: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
Message-ID: <bJZOGjoJ-Kk-F9Dx-BqdGvgmQWiXZ2akSKt4eV5I1bg=.cb342702-8c72-4bc3-a890-41e0aff4ba20@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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge
 - remove duplicated benchmark case
 - remove unnecessary comment
 - more improvement
 - more performance improvement
 - 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=05
  Stats: 201 lines in 1 file changed: 199 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 aturbanov at openjdk.org  Sun Nov 13 16:29:26 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 13 Nov 2022 16:29:26 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
In-Reply-To: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
Message-ID: <kfv92An6BunB-5D2WMHMUQlQqfHRu5cJ9zaU96iEOBM=.a6ae524d-f1df-4317-9b7a-7f27e08b3378@github.com>

On Wed, 9 Nov 2022 20:15:57 GMT, Xubo Zhang <duke at openjdk.org> wrote:

> NativePRNG SecureRandom doesn?t scale with number of threads. The performance starts dropping as we increase the number of threads. Even going from 1 thread to 2 threads shows significant drop. The bottleneck is the singleton RandomIO instance. Making the RandomIO ThreadLocal helps in removing this bottleneck.
> 
> Here are the jmh  thrpt ops/s data for SecureRandomBench.nextBytes, algorithm=NativePRNGNonBlocking, datasize=64, notshared:
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> #threads | singleton RandomIO | ThreadLocal RandomIO
> -- | -- | --
> 1 | 1269133 | 1279088
> 2 | 862923 | 1362066
> 3 | 819734 | 1630522
> 4 | 809128 | 1614500
> 5 | 821514 | 1594965
> 6 | 808795 | 1545045
> 7 | 783050 | 1499388
> 8 | 787236 | 1470004
> 
> 
> 
> </body>
> 
> </html>

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 194:

> 192:                         try {
> 193:                             return new RandomIO(seedFile, nextFile);
> 194:                         } catch (Exception e)  {

Suggestion:

                        } catch (Exception e) {

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

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


From xuelei at openjdk.org  Sun Nov 13 18:44:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sun, 13 Nov 2022 18:44:30 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
In-Reply-To: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
Message-ID: <cgb-UWcOL-HHdjpF5_X90LdlBSo9vtLPKp5KSRgJbAU=.83dab5d1-578c-4a4b-b47d-7bd175e43391@github.com>

On Wed, 9 Nov 2022 20:15:57 GMT, Xubo Zhang <duke at openjdk.org> wrote:

> NativePRNG SecureRandom doesn?t scale with number of threads. The performance starts dropping as we increase the number of threads. Even going from 1 thread to 2 threads shows significant drop. The bottleneck is the singleton RandomIO instance. Making the RandomIO ThreadLocal helps in removing this bottleneck.
> 
> Here are the jmh  thrpt ops/s data for SecureRandomBench.nextBytes, algorithm=NativePRNGNonBlocking, datasize=64, notshared:
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> #threads | singleton RandomIO | ThreadLocal RandomIO
> -- | -- | --
> 1 | 1269133 | 1279088
> 2 | 862923 | 1362066
> 3 | 819734 | 1630522
> 4 | 809128 | 1614500
> 5 | 821514 | 1594965
> 6 | 808795 | 1545045
> 7 | 783050 | 1499388
> 8 | 787236 | 1470004
> 
> 
> 
> </body>
> 
> </html>

By using thread-local, is it possible to get the same random number in two threads?

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

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


From weijun at openjdk.org  Sun Nov 13 21:40:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 13 Nov 2022 21:40:44 GMT
Subject: RFR: 8296900: CertificateValidity fields are not be optional
Message-ID: <GrpTWAat7jsVx8gZV15A3uAkA1Xlz9UhcYa7SVYR9yo=.5787ba48-7be6-4a5b-856c-9171b8a1e2a8@github.com>

Make two fields inside `CertificateValidity` final.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11126/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296900
  Stats: 112 lines in 2 files changed: 71 ins; 37 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11126/head:pull/11126

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


From dholmes at openjdk.org  Sun Nov 13 23:29:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 13 Nov 2022 23:29:06 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>

On Thu, 10 Nov 2022 06:20:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

This looks good in general. It is a pity there is so much simple moving of where "attributes" are listed, as it makes it look like the changes are more extensive than they really are - that said I prefer to see the attributes appear before a function/method signature rather than after, or somewhere in-between.

A few other comments below.

Thanks.

make/autoconf/flags-cflags.m4 line 632:

> 630:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
> 631:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
> 632:       -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'"

So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right?

src/hotspot/os/linux/os_perf_linux.cpp line 233:

> 231:  *  Ensure that 'fmt' does _NOT_ contain the first two "%d %s"
> 232:  */
> 233: SCANF_ARGS(2, 0) static int vread_statdata(const char* procfile, _SCANFMT_ const char* fmt, va_list args) {

If `SCANF_ARGS` can/must come first then I suggest adding a newline after it so the method signature is easier to spot. Applied everywhere of course.

src/hotspot/os/windows/os_windows.hpp line 35:

> 33: class Thread;
> 34: 
> 35: static unsigned __stdcall thread_native_entry(Thread*);

Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

src/hotspot/share/cds/filemap.hpp line 482:

> 480: 
> 481:   // Errors.
> 482:   ATTRIBUTE_PRINTF(1, 2) static void fail_stop(const char *msg, ...);

Again I suggest a newline after `ATTRIBUTE_PRINTF`

src/hotspot/share/utilities/compilerWarnings.hpp line 47:

> 45: #endif
> 46: 
> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING

Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`.
Update: I see the inconsistency with `compilerWarnings_visCPP.hpp`

src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:

> 35: #endif
> 36: 
> 37: #if defined(__clang_major__) && \

Not clear why this was moved ??

src/hotspot/share/utilities/debug.hpp line 172:

> 170: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);
> 171: void report_vm_out_of_memory(const char* file, int line, size_t size, VMErrorType vm_err_type,
> 172:                              const char* detail_fmt, ...) ATTRIBUTE_PRINTF(5, 6);

Why were the ATTRIBUTE_PRINTFs removed?

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

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


From jwaters at openjdk.org  Mon Nov 14 01:22:47 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:22:47 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>

On Sun, 13 Nov 2022 22:59:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> src/hotspot/os/windows/os_windows.hpp line 35:
> 
>> 33: class Thread;
>> 34: 
>> 35: static unsigned __stdcall thread_native_entry(Thread*);
> 
> Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`:
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

I'm not sure I follow, I didn't remove anything here?

> src/hotspot/share/utilities/compilerWarnings.hpp line 47:
> 
>> 45: #endif
>> 46: 
>> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING
> 
> Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`.
> Update: I see the inconsistency with `compilerWarnings_visCPP.hpp`

Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change

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

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


From jwaters at openjdk.org  Mon Nov 14 01:38:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:38:18 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <jxCazhUqSAhkx-jLo3Y1rBwdhQmzGYKEzUzIKRDbZms=.117eb027-ed31-422a-af60-2b40f3ae1cce@github.com>

On Sun, 13 Nov 2022 23:07:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:
> 
>> 35: #endif
>> 36: 
>> 37: #if defined(__clang_major__) && \
> 
> Not clear why this was moved ??

I'm not sure which one you're referring to, but the PRAGMA_DIAG_PUSH/POP was moved up to the top of the header to match compilerWarnings_visCPP.hpp, and PRAGMA_DISABLE_GCC_WARNING_AUX was moved to macros.hpp as the more general PRAGMA macro, since it's useful for all compilers and not just gcc

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

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


From jwaters at openjdk.org  Mon Nov 14 01:41:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:41:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>

On Sun, 13 Nov 2022 23:08:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> src/hotspot/share/utilities/debug.hpp line 172:
> 
>> 170: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);
>> 171: void report_vm_out_of_memory(const char* file, int line, size_t size, VMErrorType vm_err_type,
>> 172:                              const char* detail_fmt, ...) ATTRIBUTE_PRINTF(5, 6);
> 
> Why were the ATTRIBUTE_PRINTFs removed?

The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods

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

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


From jwaters at openjdk.org  Mon Nov 14 01:46:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:46:16 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <cvaF0K8j70TF2vlmgBHzQYAOiYSeP7uZ_Y4yavC0J2w=.e69dd78a-7b52-4a00-969e-e4a195623c2b@github.com>

On Sun, 13 Nov 2022 23:16:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> make/autoconf/flags-cflags.m4 line 632:
> 
>> 630:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>> 631:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
>> 632:       -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'"
> 
> So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right?

Yep, just something that C++ does a little neater, at least in my view

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

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


From jwaters at openjdk.org  Mon Nov 14 04:14:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 04:14:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  ATTRIBUTE_SCANF

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11081/files
  - new: https://git.openjdk.org/jdk/pull/11081/files/6d85c432..bb3ef0dd

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

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

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


From jwaters at openjdk.org  Mon Nov 14 04:14:26 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 04:14:26 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <xa0OxJAKuXs1pITkUZKcljgKl00lHRp9XUdMrknO9J4=.6aa6f913-0739-4bf8-a05a-bd77a7e8bfdd@github.com>

On Sun, 13 Nov 2022 22:58:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ATTRIBUTE_SCANF
>
> src/hotspot/os/linux/os_perf_linux.cpp line 233:
> 
>> 231:  *  Ensure that 'fmt' does _NOT_ contain the first two "%d %s"
>> 232:  */
>> 233: SCANF_ARGS(2, 0) static int vread_statdata(const char* procfile, _SCANFMT_ const char* fmt, va_list args) {
> 
> If `SCANF_ARGS` can/must come first then I suggest adding a newline after it so the method signature is easier to spot. Applied everywhere of course.

Resolved, thanks

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

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


From xuelei at openjdk.org  Mon Nov 14 06:23:22 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 14 Nov 2022 06:23:22 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <mvKHMwxZPHZlO2FmO7nG1UyUxszVY5yn1pO6mUdBxPc=.480a8543-4b3f-4156-8ef9-61819ede17e8@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
 <4Bor4yGVSimu9ZwZ-tK4JSizWjYPZpfXYtHqZ0ubbBU=.a33e76d7-b10a-4304-a572-9ca6a4dc32be@github.com>
 <JzBO24xeWli6rmwHEWpBD-bScVheXwWr8ZFLh8l-gGE=.bbafcedf-8343-40e1-b055-80b9894f30c2@github.com>
 <mvKHMwxZPHZlO2FmO7nG1UyUxszVY5yn1pO6mUdBxPc=.480a8543-4b3f-4156-8ef9-61819ede17e8@github.com>
Message-ID: <Flm1ErReYx7RsbQJJOtTPWeyr9NwdfWjSjRZ6s2ui0s=.051e72da-5245-41eb-88f8-a6bdec98da7a@github.com>

On Wed, 21 Sep 2022 18:29:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev Good points and I agree with them.
>> 
>>> Are you getting +0.8% throughput on microbenchmarks?
>> 
>> Yes, I got it a few times. I tested on MacOS/M1 and Linux/AMD for 64/512/2048/16384 bytes.  As the improvement is not significant, the number was impacted by the platforms status/loading.  I can see improvement, but I did not get a stable +0.8%.
>> 
>> I got a more than +1% improvement in another algorithm implementation (SM3).  That's the reason I want to check out the JDK implementations.  But you let me convinced that this may not be worthy of the effort.  Thank you so much!
>> 
>>> https://bugs.openjdk.org/browse/JDK-8256523
>> 
>> Thank you so much for pointing this out.  From it, I learned something new that the Java inline may not work in some circumstance.  Impressed PR description!
>
>> But you let me convinced that this may not be worthy of the effort.
> 
> Let's think about it and not discount it right away. 1% improvement on OpenJDK scale is still quite significant, if we can show the non-interpreter modes benefit from it. Maybe older X86 and AArch64 are our targets, since it is not guaranteed to have SHA hardware intrinsics?

@shipilev Did you have further comment?  Thanks!

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

PR: https://git.openjdk.org/jdk/pull/10365


From xuelei at openjdk.org  Mon Nov 14 06:27:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 14 Nov 2022 06:27:28 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v2]
In-Reply-To: <gf7boGy8yDbTX774E7awreNc11bPFdmuuD-2Zyn6WBo=.f226a43a-6f18-4412-ba0d-581b0c4c4b87@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>
 <gf7boGy8yDbTX774E7awreNc11bPFdmuuD-2Zyn6WBo=.f226a43a-6f18-4412-ba0d-581b0c4c4b87@github.com>
Message-ID: <S_8anxAkBJ15podIeWYgt37DrKMjGN5ZmdGhzNbCuJM=.c2d5d97a-f491-4486-9a64-5ef46cea6676@github.com>

On Wed, 2 Nov 2022 14:44:30 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.
>
>> > ... 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.
> 
> Well, I doubt this would be one of those cases you have in mind...
> Your method of computing the inverse looks good to me, but I still think that if we can achieve a better result with an existing general method then we should do that instead of writing special ones for every curve. 
> I think there is a risk in having more code, too.

@ferakocz Did you have further comment?  What do you think if we integrate the update?

-------------

PR: https://git.openjdk.org/jdk/pull/10544


From dholmes at openjdk.org  Mon Nov 14 08:07:34 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Nov 2022 08:07:34 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
Message-ID: <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>

On Mon, 14 Nov 2022 01:17:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.hpp line 35:
>> 
>>> 33: class Thread;
>>> 34: 
>>> 35: static unsigned __stdcall thread_native_entry(Thread*);
>> 
>> Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`:
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170
>
> I'm not sure I follow, I didn't remove anything here?

Sorry my eyes must be playing tricks on me. ??

Why did you need to add this here?

>> src/hotspot/share/utilities/compilerWarnings.hpp line 47:
>> 
>>> 45: #endif
>>> 46: 
>>> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING
>> 
>> Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`.
>> Update: I see the inconsistency with `compilerWarnings_visCPP.hpp`
>
> Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change

I think it is the file that has the "bad" name in this case. :( But okay.

>> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:
>> 
>>> 35: #endif
>>> 36: 
>>> 37: #if defined(__clang_major__) && \
>> 
>> Not clear why this was moved ??
>
> I'm not sure which one you're referring to, but the PRAGMA_DIAG_PUSH/POP was moved up to the top of the header to match compilerWarnings_visCPP.hpp, and PRAGMA_DISABLE_GCC_WARNING_AUX was moved to macros.hpp as the more general PRAGMA macro, since it's useful for all compilers and not just gcc

Okay

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From dholmes at openjdk.org  Mon Nov 14 08:10:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Nov 2022 08:10:45 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>
Message-ID: <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com>

On Mon, 14 Nov 2022 01:39:17 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/share/utilities/debug.hpp line 172:
>> 
>>> 170:                             int status, const char* detail);
>>> 171: ATTRIBUTE_PRINTF(4, 5)
>>> 172: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...);
>> 
>> Why were the ATTRIBUTE_PRINTFs removed?
>
> The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods

Wow I'm really having eyesight problems today! Sorry about that.

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From stuefe at openjdk.org  Mon Nov 14 08:30:35 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 14 Nov 2022 08:30:35 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
Message-ID: <vIdqGyQkQAXZauPAFCN2CkP_sG-N2nN90_HYrOHisYA=.e704c782-83d0-4464-b646-75f2cda0b686@github.com>

On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ATTRIBUTE_SCANF

Hi Julian,

unfortunately, your patch will make backporting more difficult. We cannot downport it to older releases compiled with older compilers. But since it touches a lot of files it will sit smack in the middle of patch sequences, requiring manual merges for patches after it.

Is there any benefit to using the new syntax compared to the old one? It does seem similar verbose, so I don't see any benefit there.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From benjamin.marwell at f-i.de  Mon Nov 14 08:36:42 2022
From: benjamin.marwell at f-i.de (benjamin.marwell at f-i.de)
Date: Mon, 14 Nov 2022 08:36:42 +0000
Subject: Undo deprecation of brainpool EC
Message-ID: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>

Hello everyone!

To our surprise, brainpool EC have been deprecated with Java 14+ [1].
However, JDK-8234924 [1] does not add any information on WHY they would have been deprecated.
In fact, neither NIST (USA) nor BSI (Germany) list them as deprecated.
On the contrary, both institutions list them as an acceptable cipher.

As a matter of fact, the deprecation notice seem to have originated by bad wording.
Please read this quote from Manfred Lochter, how works at the BSI:

> The unfortunate wording about the brainpool curves originated in TLS 1.3, 
> however RFC 8734 makes the curves usable for TLS again.
> We will continue to recommend the Brainpool curves.
> It should also be noted that the arguments for the "modern formulas" have all been refuted by now.
> Especially the implementation of Curve 25519 requires more effort to protect against SCA; 
> the deterministic signatures are vulnerable to fault injection.
> In the medium term, however, the switch to post-quantum cryptography is necessary; 
> there are comprehensive recommendations on this at [2]

Now, european banking and health industry still do rely heavily on brainpool curves.
Given all these facts, I hereby request to undo the depracation of brainpool EC in OpenJDK.

Please let me know what lead to the assumption that brainpool ciphers were deprecated.
Neither NIST nor BSI seems to be the source. Given all the facts, it should still be included.

References:

[1]: https://bugs.openjdk.org/browse/JDK-8234924
[2]: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html 

Mit freundlichen Gr??en 

Benjamin Marwell 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5591 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221114/d5a3ed55/smime.p7s>

From aph at openjdk.org  Mon Nov 14 11:11:27 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Nov 2022 11:11:27 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <vIdqGyQkQAXZauPAFCN2CkP_sG-N2nN90_HYrOHisYA=.e704c782-83d0-4464-b646-75f2cda0b686@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <vIdqGyQkQAXZauPAFCN2CkP_sG-N2nN90_HYrOHisYA=.e704c782-83d0-4464-b646-75f2cda0b686@github.com>
Message-ID: <SRjjAqG5gAsvlkrnUTYFXBwO_Urv7DC1Z3yse50RPb4=.c7a1f821-af0b-4383-a69a-612585ebc17c@github.com>

On Mon, 14 Nov 2022 08:28:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> unfortunately, your patch will make backporting more difficult. We cannot downport it to older releases compiled with older compilers. But since it touches a lot of files it will sit smack in the middle of patch sequences, requiring manual merges for patches after it.
> 
> Is there any benefit to using the new syntax compared to the old one? It does seem similar verbose, so I don't see any benefit there.

I have to agree with Thomas here. Newer is not always better.

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From jwaters at openjdk.org  Mon Nov 14 12:00:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 12:00:28 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>
 <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com>
Message-ID: <aRZ0z2fQtE_oqBULtBDXoWOjZTczhBd77qXOuxkA1a0=.a485227d-efdf-42d6-9a79-a01959ddce42@github.com>

On Mon, 14 Nov 2022 08:08:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods
>
> Wow I'm really having eyesight problems today! Sorry about that.

Haha, no worries

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From jwaters at openjdk.org  Mon Nov 14 12:24:31 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 12:24:31 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
 <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
Message-ID: <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>

On Mon, 14 Nov 2022 08:01:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'm not sure I follow, I didn't remove anything here?
>
> Sorry my eyes must be playing tricks on me. ??
> 
> Why did you need to add this here?

It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11:

> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage.

While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead:

> ?11.3/4 [class.friend]
A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1).

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From kbarrett at openjdk.org  Mon Nov 14 13:42:02 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Nov 2022 13:42:02 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
Message-ID: <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>

On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ATTRIBUTE_SCANF

Changes requested by kbarrett (Reviewer).

make/hotspot/lib/CompileJvm.gmk line 67:

> 65:   # Hotspot cannot handle an empty build number
> 66:   VERSION_BUILD := 0
> 67: endif

I think the proposed "solution" is *much* worse than this.

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From kbarrett at openjdk.org  Mon Nov 14 13:42:04 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Nov 2022 13:42:04 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <cvaF0K8j70TF2vlmgBHzQYAOiYSeP7uZ_Y4yavC0J2w=.e69dd78a-7b52-4a00-969e-e4a195623c2b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <cvaF0K8j70TF2vlmgBHzQYAOiYSeP7uZ_Y4yavC0J2w=.e69dd78a-7b52-4a00-969e-e4a195623c2b@github.com>
Message-ID: <PqiJunKhY85BbqgIB5X96kg16Dm-mTszPAFzYOjsfWs=.ebb72cc2-e4e0-4e8f-823e-1f5f97881a6a@github.com>

On Mon, 14 Nov 2022 01:42:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 632:
>> 
>>> 630:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>>> 631:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
>>> 632:       -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'"
>> 
>> So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right?
>
> Yep, just something that C++ does a little neater, at least in my view

We (the HotSpot Group) have not discussed or approved the use of the new C++ attribute syntax, whether for standard attributes or compiler-specific ones.  That involves an update to the Style Guide.  I'm not convinced switching existing uses from compiler-specific `__attribute__` syntax to compiler-specific `[[attribute]]` syntax is worth the substantial code churn.

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From weijun at openjdk.org  Mon Nov 14 14:57:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 14:57:10 GMT
Subject: Integrated: 8296741: Illegal X400Address and EDIPartyName should not
 be created
In-Reply-To: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
References: <I7iw4bt5AAmWzl6Bei6fcqnC4Y-OzDdiPbyqXHbjWww=.85169e03-add7-4e3d-b8cf-61cb05ce5a69@github.com>
Message-ID: <R7M7uel2mkedvFV_Er4nUKvC7SKYOhzgwucYJsb9lPk=.83f4b669-3f16-429e-ae66-e7d0d35a989d@github.com>

On Wed, 9 Nov 2022 22:32:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `EDIPartyName` should not have a null `partyName`.
> 
> Inside `X400Name` it should be a `DerValue` instead of arbitrary byte array. Note: in `GeneralSubtrees.java`, an `X400Name` is created with a null content. This would lead to an NPE anyway. A future fix might be needed.

This pull request has now been integrated.

Changeset: e1d298c1
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1d298c12d8c8f22d36ba9592d188a3162b0c6e5
Stats:     66 lines in 4 files changed: 54 ins; 7 del; 5 mod

8296741: Illegal X400Address and EDIPartyName should not be created

Reviewed-by: xuelei, valeriep

-------------

PR: https://git.openjdk.org/jdk/pull/11071


From xuelei at openjdk.org  Mon Nov 14 15:17:15 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 14 Nov 2022 15:17:15 GMT
Subject: RFR: 8296818: Enhance JMH tests java/security/Signatures.java
Message-ID: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>

Hi,

May I get the micro benchmarking enhancement reviewed?

Benchmark cases for RSA(SSA-PSS)/DSA are added in the PR.  Here is the benchmarking number on a Linux X86_64 platform.

Benchmark                            (algorithm)  (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.DSA.sign                SHA256withDSA               64  thrpt   15  2076.114 ?  6.269  ops/s
Signatures.DSA.sign                SHA256withDSA              512  thrpt   15  2080.330 ?  4.204  ops/s
Signatures.DSA.sign                SHA256withDSA             2048  thrpt   15  2074.546 ? 11.596  ops/s
Signatures.DSA.sign                SHA256withDSA            16384  thrpt   15  2029.887 ?  6.255  ops/s
Signatures.DSA.sign                SHA384withDSA               64  thrpt   15   882.339 ?  3.343  ops/s
Signatures.DSA.sign                SHA384withDSA              512  thrpt   15   881.690 ?  2.792  ops/s
Signatures.DSA.sign                SHA384withDSA             2048  thrpt   15   876.370 ?  5.779  ops/s
Signatures.DSA.sign                SHA384withDSA            16384  thrpt   15   860.463 ?  3.286  ops/s
Signatures.EdDSA.sign                    Ed25519               64  thrpt   15  1198.668 ?  4.347  ops/s
Signatures.EdDSA.sign                    Ed25519              512  thrpt   15  1199.107 ?  2.645  ops/s
Signatures.EdDSA.sign                    Ed25519             2048  thrpt   15  1191.952 ?  7.202  ops/s
Signatures.EdDSA.sign                    Ed25519            16384  thrpt   15  1112.078 ?  5.449  ops/s
Signatures.EdDSA.sign                      Ed448               64  thrpt   15   329.802 ?  5.474  ops/s
Signatures.EdDSA.sign                      Ed448              512  thrpt   15   328.258 ?  1.725  ops/s
Signatures.EdDSA.sign                      Ed448             2048  thrpt   15   322.206 ?  5.911  ops/s
Signatures.EdDSA.sign                      Ed448            16384  thrpt   15   317.814 ?  2.339  ops/s
Signatures.RSA.sign                SHA256withRSA               64  thrpt   15   834.704 ?  6.869  ops/s
Signatures.RSA.sign                SHA256withRSA              512  thrpt   15   838.794 ?  2.995  ops/s
Signatures.RSA.sign                SHA256withRSA             2048  thrpt   15   832.343 ?  3.781  ops/s
Signatures.RSA.sign                SHA256withRSA            16384  thrpt   15   833.405 ?  3.750  ops/s
Signatures.RSA.sign                SHA384withRSA               64  thrpt   15   279.930 ?  1.384  ops/s
Signatures.RSA.sign                SHA384withRSA              512  thrpt   15   280.822 ?  1.189  ops/s
Signatures.RSA.sign                SHA384withRSA             2048  thrpt   15   278.644 ?  1.608  ops/s
Signatures.RSA.sign                SHA384withRSA            16384  thrpt   15   277.631 ?  1.266  ops/s
Signatures.RSA.sign                SHA512withRSA               64  thrpt   15   126.927 ?  0.790  ops/s
Signatures.RSA.sign                SHA512withRSA              512  thrpt   15   126.572 ?  0.506  ops/s
Signatures.RSA.sign                SHA512withRSA             2048  thrpt   15   127.159 ?  0.619  ops/s
Signatures.RSA.sign                SHA512withRSA            16384  thrpt   15   126.104 ?  0.262  ops/s
Signatures.RSASSAPSS.sign   SHA256withRSASSA-PSS               64  thrpt   15   832.804 ?  4.243  ops/s
Signatures.RSASSAPSS.sign   SHA256withRSASSA-PSS              512  thrpt   15   828.386 ? 10.118  ops/s
Signatures.RSASSAPSS.sign   SHA256withRSASSA-PSS             2048  thrpt   15   831.469 ?  4.792  ops/s
Signatures.RSASSAPSS.sign   SHA256withRSASSA-PSS            16384  thrpt   15   826.325 ?  2.698  ops/s
Signatures.RSASSAPSS.sign  SHA3846withRSASSA-PSS               64  thrpt   15   276.043 ?  1.594  ops/s
Signatures.RSASSAPSS.sign  SHA3846withRSASSA-PSS              512  thrpt   15   278.548 ?  2.011  ops/s
Signatures.RSASSAPSS.sign  SHA3846withRSASSA-PSS             2048  thrpt   15   276.393 ?  2.155  ops/s
Signatures.RSASSAPSS.sign  SHA3846withRSASSA-PSS            16384  thrpt   15   274.924 ?  1.520  ops/s
Signatures.RSASSAPSS.sign   SHA512withRSASSA-PSS               64  thrpt   15   126.004 ?  0.413  ops/s
Signatures.RSASSAPSS.sign   SHA512withRSASSA-PSS              512  thrpt   15   127.211 ?  0.312  ops/s
Signatures.RSASSAPSS.sign   SHA512withRSASSA-PSS             2048  thrpt   15   127.200 ?  0.338  ops/s
Signatures.RSASSAPSS.sign   SHA512withRSASSA-PSS            16384  thrpt   15   126.327 ?  0.520  ops/s
Signatures.sign                        secp256r1               64  thrpt   15  1523.564 ? 22.411  ops/s
Signatures.sign                        secp256r1              512  thrpt   15  1529.083 ?  5.903  ops/s
Signatures.sign                        secp256r1             2048  thrpt   15  1530.112 ?  7.832  ops/s
Signatures.sign                        secp256r1            16384  thrpt   15  1500.652 ?  1.936  ops/s
Signatures.sign                        secp384r1               64  thrpt   15   642.752 ? 11.175  ops/s
Signatures.sign                        secp384r1              512  thrpt   15   645.279 ?  3.632  ops/s
Signatures.sign                        secp384r1             2048  thrpt   15   632.866 ?  4.137  ops/s
Signatures.sign                        secp384r1            16384  thrpt   15   624.020 ?  6.282  ops/s
Signatures.sign                        secp521r1               64  thrpt   15   319.333 ?  1.587  ops/s
Signatures.sign                        secp521r1              512  thrpt   15   320.025 ?  0.890  ops/s
Signatures.sign                        secp521r1             2048  thrpt   15   309.922 ?  9.569  ops/s
Signatures.sign                        secp521r1            16384  thrpt   15   317.070 ?  0.930  ops/s

Thanks,
Xuelei

-------------

Commit messages:
 - add DSA signatures
 - 8296818: Enhance JMH tests java/security/Signatures.java

Changes: https://git.openjdk.org/jdk/pull/11131/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296818
  Stats: 146 lines in 1 file changed: 114 ins; 16 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11131/head:pull/11131

PR: https://git.openjdk.org/jdk/pull/11131


From jwaters at openjdk.org  Mon Nov 14 16:12:48 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 16:12:48 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert to using simpler solution similar to the original 8274980

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11081/files
  - new: https://git.openjdk.org/jdk/pull/11081/files/bb3ef0dd..fe5371c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=01-02

  Stats: 28 lines in 2 files changed: 4 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11081.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11081/head:pull/11081

PR: https://git.openjdk.org/jdk/pull/11081


From mpowers at openjdk.org  Mon Nov 14 16:20:27 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 14 Nov 2022 16:20:27 GMT
Subject: RFR: 8296900: CertificateValidity fields are not be optional
In-Reply-To: <GrpTWAat7jsVx8gZV15A3uAkA1Xlz9UhcYa7SVYR9yo=.5787ba48-7be6-4a5b-856c-9171b8a1e2a8@github.com>
References: <GrpTWAat7jsVx8gZV15A3uAkA1Xlz9UhcYa7SVYR9yo=.5787ba48-7be6-4a5b-856c-9171b8a1e2a8@github.com>
Message-ID: <K1vFncc_98byMgypwwqwdySFKVOQwEi4_6pqwAGDZkM=.8cf10ea8-110f-45cd-835e-675d76dddc9a@github.com>

On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Make two fields inside `CertificateValidity` final.

The changes look good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/11126


From duke at openjdk.org  Mon Nov 14 16:37:41 2022
From: duke at openjdk.org (Xubo Zhang)
Date: Mon, 14 Nov 2022 16:37:41 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
Message-ID: <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>

> NativePRNG SecureRandom doesn?t scale with number of threads. The performance starts dropping as we increase the number of threads. Even going from 1 thread to 2 threads shows significant drop. The bottleneck is the singleton RandomIO instance. Making the RandomIO ThreadLocal helps in removing this bottleneck.
> 
> Here are the jmh  thrpt ops/s data for SecureRandomBench.nextBytes, algorithm=NativePRNGNonBlocking, datasize=64, notshared:
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> #threads | singleton RandomIO | ThreadLocal RandomIO
> -- | -- | --
> 1 | 1269133 | 1279088
> 2 | 862923 | 1362066
> 3 | 819734 | 1630522
> 4 | 809128 | 1614500
> 5 | 821514 | 1594965
> 6 | 808795 | 1545045
> 7 | 783050 | 1499388
> 8 | 787236 | 1470004
> 
> 
> 
> </body>
> 
> </html>

Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/unix/classes/sun/security/provider/NativePRNG.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11069/files
  - new: https://git.openjdk.org/jdk/pull/11069/files/3fe520bf..9c93af32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11069&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11069&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11069.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11069/head:pull/11069

PR: https://git.openjdk.org/jdk/pull/11069


From weijun at openjdk.org  Mon Nov 14 16:53:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 16:53:10 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created
Message-ID: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>

Inside JDK we support a lot of X.509 certificate extensions. Almost every extension has a rule about what is legal or not. For example, the names in `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a rule is enforced in the `encode()` method, where the extension value is assigned null for illegal extension and the method throws an `IOException`. However, before the `encode()` method is called, the illegal extension can always be created successfully, whether from a constructor using extension components (For example, `new SubjectAlternativeNameExtension(names)`) or using the encoded value (for example, `new SubjectAlternativeNameExtension(derEncoding)`).

This code change tries to prevent illegal extensions from being created right from the beginning but the solution is not complete. Precisely, for constructors using extension components, new checks are added to ensure the correct components are provided and the extension can be encoded correctly. Fortunately, most of these conditions are already met inside JDK calls to them. The only exception is inside the `keytool -gencrl` command where the reason code of a revoked certificate could be zero. This has been fixed in this code change. There are some constructors having no arguments at all. These are useless and also removed.

On the other hand, constructors using the encoded value are complicated. Some of them check for legal values, some do not. However, since the encoding is read from the argument and already stored inside the object, there is no need to calculate the encoding in the `encode()` method and this method always succeed.

In short, while we cannot ensure the extensions created are perfectly legal, we ensure their `encode()` methods are always be able to find a non-null extension value to write out.

More fine comments in the code change.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11137/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11137&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296742
  Stats: 166 lines in 22 files changed: 98 ins; 39 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/11137.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11137/head:pull/11137

PR: https://git.openjdk.org/jdk/pull/11137


From weijun at openjdk.org  Mon Nov 14 16:53:13 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 16:53:13 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <cVrwVbeZAvlEVW6eniogFimnUFeLYMLAE6OzBbUztM4=.80fc22e2-aa58-4649-8922-2bd91b13ec6a@github.com>

On Mon, 14 Nov 2022 16:47:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Inside JDK we support a lot of X.509 certificate extensions. Almost every extension has a rule about what is legal or not. For example, the names in `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a rule is enforced in the `encode()` method, where the extension value is assigned null for illegal extension and the method throws an `IOException`. However, before the `encode()` method is called, the illegal extension can always be created successfully, whether from a constructor using extension components (For example, `new SubjectAlternativeNameExtension(names)`) or using the encoded value (for example, `new SubjectAlternativeNameExtension(derEncoding)`).
> 
> This code change tries to prevent illegal extensions from being created right from the beginning but the solution is not complete. Precisely, for constructors using extension components, new checks are added to ensure the correct components are provided and the extension can be encoded correctly. Fortunately, most of these conditions are already met inside JDK calls to them. The only exception is inside the `keytool -gencrl` command where the reason code of a revoked certificate could be zero. This has been fixed in this code change. There are some constructors having no arguments at all. These are useless and also removed.
> 
> On the other hand, constructors using the encoded value are complicated. Some of them check for legal values, some do not. However, since the encoding is read from the argument and already stored inside the object, there is no need to calculate the encoding in the `encode()` method and this method always succeed.
> 
> In short, while we cannot ensure the extensions created are perfectly legal, we ensure their `encode()` methods are always be able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1587:

> 1585:                 int code = Integer.parseInt(id.substring(d+1));
> 1586:                 if (code == 0) {
> 1587:                     throw new Exception("Reason code cannot be 0");

This is the only behavior change made. Please note that even if reason code 0 was accepted before this change, the extension could not be encoded and the CRL would not be created. After this change, the above exception will be thrown in an earlier stage.

-------------

PR: https://git.openjdk.org/jdk/pull/11137


From weijun at openjdk.org  Mon Nov 14 17:06:38 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 17:06:38 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <ArliRrtHldN02l3r-VGw-wik1auR252IVNyHYgoSoT0=.4866e960-ec47-48cf-bc52-abf8f14dd077@github.com>

On Mon, 14 Nov 2022 16:47:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Inside JDK we support a lot of X.509 certificate extensions. Almost every extension has a rule about what is legal or not. For example, the names in `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a rule is enforced in the `encode()` method, where the extension value is assigned null for illegal extension and the method throws an `IOException`. However, before the `encode()` method is called, the illegal extension can always be created successfully, whether from a constructor using extension components (For example, `new SubjectAlternativeNameExtension(names)`) or using the encoded value (for example, `new SubjectAlternativeNameExtension(derEncoding)`).
> 
> This code change tries to prevent illegal extensions from being created right from the beginning but the solution is not complete. Precisely, for constructors using extension components, new checks are added to ensure the correct components are provided and the extension can be encoded correctly. Fortunately, most of these conditions are already met inside JDK calls to them. The only exception is inside the `keytool -gencrl` command where the reason code of a revoked certificate could be zero. This has been fixed in this code change. There are some constructors having no arguments at all. These are useless and also removed.
> 
> On the other hand, constructors using the encoded value are complicated. Some of them check for legal values, some do not. However, since the encoding is read from the argument and already stored inside the object, there is no need to calculate the encoding in the `encode()` method and this method always succeed.
> 
> In short, while we cannot ensure the extensions created are perfectly legal, we ensure their `encode()` methods are always be able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4640:

> 4638:                 if (exttype != -1 && value != null && value.isEmpty()) {
> 4639:                     throw new Exception(rb.getString("Illegal.value.") + extstr);
> 4640:                 }

Due to a special rule. `"".split(",")` returns a single element `String[1] { "" }`, and this `""` will be rejected by keytool. The check above is added to be more clear.

-------------

PR: https://git.openjdk.org/jdk/pull/11137


From weijun at openjdk.org  Mon Nov 14 17:13:26 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 17:13:26 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <ZTDd34EbD5cTv-YX4pnb4bTEBVGqZ1vvC7sNRUp28No=.acddbf4e-ef9e-4eca-bff0-f973b9809eb0@github.com>

On Mon, 14 Nov 2022 16:47:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Inside JDK we support a lot of X.509 certificate extensions. Almost every extension has a rule about what is legal or not. For example, the names in `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a rule is enforced in the `encode()` method, where the extension value is assigned null for illegal extension and the method throws an `IOException`. However, before the `encode()` method is called, the illegal extension can always be created successfully, whether from a constructor using extension components (For example, `new SubjectAlternativeNameExtension(names)`) or using the encoded value (for example, `new SubjectAlternativeNameExtension(derEncoding)`).
> 
> This code change tries to prevent illegal extensions from being created right from the beginning but the solution is not complete. Precisely, for constructors using extension components, new checks are added to ensure the correct components are provided and the extension can be encoded correctly. Fortunately, most of these conditions are already met inside JDK calls to them. The only exception is inside the `keytool -gencrl` command where the reason code of a revoked certificate could be zero. This has been fixed in this code change. There are some constructors having no arguments at all. These are useless and also removed.
> 
> On the other hand, constructors using the encoded value are complicated. Some of them check for legal values, some do not. However, since the encoding is read from the argument and already stored inside the object, there is no need to calculate the encoding in the `encode()` method and this method always succeed.
> 
> In short, while we cannot ensure the extensions created are perfectly legal, we ensure their `encode()` methods are always able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

src/java.base/share/classes/sun/security/x509/NameConstraintsExtension.java line 351:

> 349:         if (updated) {
> 350:             encodeThis();
> 351:         }

This is the only extension where `encodeThis()` might be called (and thus set `extensionVaue` to null) even if the extension is created from an encoding. The `updated` flag is added to make sure the re-encoding is only done when there is a real modification. In this case, at least one of `permitted` and `excluded` is not null and a non-null encoding can be calculated.

In fact, because of this `merge` method, this is also the only extension that cannot be easily rewritten into an immutable class. This can be considered in a future enhancement.

-------------

PR: https://git.openjdk.org/jdk/pull/11137


From mullan at openjdk.org  Mon Nov 14 17:31:45 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 14 Nov 2022 17:31:45 GMT
Subject: RFR: 8296900: CertificateValidity fields are not be optional
In-Reply-To: <GrpTWAat7jsVx8gZV15A3uAkA1Xlz9UhcYa7SVYR9yo=.5787ba48-7be6-4a5b-856c-9171b8a1e2a8@github.com>
References: <GrpTWAat7jsVx8gZV15A3uAkA1Xlz9UhcYa7SVYR9yo=.5787ba48-7be6-4a5b-856c-9171b8a1e2a8@github.com>
Message-ID: <PTcS2swrcNVHf7paf-k8J0Ez5-ktR7KlW8QtnWnH0oU=.1a428a68-a37f-4e33-82ed-c04a349afa6a@github.com>

On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Make two fields inside `CertificateValidity` final.

Typo in bug summary, change to "CertificateValidity fields are not optional"

-------------

PR: https://git.openjdk.org/jdk/pull/11126


From mullan at openjdk.org  Mon Nov 14 17:35:55 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 14 Nov 2022 17:35:55 GMT
Subject: RFR: 8296900: CertificateValidity fields are not optional
In-Reply-To: <GrpTWAat7jsVx8gZV15A3uAkA1Xlz9UhcYa7SVYR9yo=.5787ba48-7be6-4a5b-856c-9171b8a1e2a8@github.com>
References: <GrpTWAat7jsVx8gZV15A3uAkA1Xlz9UhcYa7SVYR9yo=.5787ba48-7be6-4a5b-856c-9171b8a1e2a8@github.com>
Message-ID: <7GsYQAGnPHDOR-2iePsw4R91Qte7D8wyvwMeYSaC91I=.179db6cf-ac7d-45d6-b1c6-c454d8734dfe@github.com>

On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Make two fields inside `CertificateValidity` final.

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11126


From mpowers at openjdk.org  Mon Nov 14 17:40:47 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 14 Nov 2022 17:40:47 GMT
Subject: Integrated: 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: <nhzHszeKWDw-eMNhCnrjl3XCdpTtRsPRHN2s6L44vEs=.ea788902-4508-4190-8d0b-7cf08e66420f@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

This pull request has now been integrated.

Changeset: e269dc03
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e269dc03ad05e5734e08ca44d05e2eff4bdbc5fc
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8293681: ResponseAPDU getData() method javadoc

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.org/jdk/pull/10732


From duke at openjdk.org  Mon Nov 14 17:50:47 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 14 Nov 2022 17:50:47 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <hp3DuRUsHA39f-YoJ2AuxY-7ZcVPKDTFXFVB46xsDBo=.d077e145-3b07-43c5-93f4-6d00c29f101f@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <BTbk9ljmz_Cwa7x7buftpILEvm88PQNE8frL57YTQlw=.fe6189e1-fea7-401f-87e5-7ff7417cd9f0@github.com>
 <L4R9rjMDy1jtGusy2kAN13OrRK9P6UwQvr5jaGZNHUU=.61bf2e0d-7739-4e54-967e-870bff7e52f5@github.com>
 <IgOknAH9HUWa5VQropGAIp7I5QXLUGf6IspI_QVEe-Q=.85cfcc50-3c66-4fd3-b23a-65c40bb87423@github.com>
 <orY8dXwBoWdbN04iP_wTouuDWQl9aqjOFV9APiHY3Dc=.32ab3d07-8d44-4f04-85bd-cc51eb61f414@github.com>
 <ocwevLqOwgHaiJ46CLgPJFVvDcalz4PWPjREnWQ20A4=.187a1435-ee73-44a5-a15f-f4dc2e9e4a2e@github.com>
 <pYQs4FMpxhCrhceVFxyy7tvGrPG3t8RzbKfSOSPyzbs=.e3b7e01d-bbd7-4f73-bf57-245389bd5ec1@github.com>
 <hp3DuRUsHA39f-YoJ2AuxY-7ZcVPKDTFXFVB46xsDBo=.d077e145-3b07-43c5-93f4-6d00c29f101f@github.com>
Message-ID: <CShJXPrVP8_FNql7cOTu_GtUAkAQXi2OQBRwzksFULA=.1f2e9e51-226c-44da-a677-b437c3b2045c@github.com>

On Fri, 11 Nov 2022 20:46:57 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> It's not specific to `andq`: there's a huge `#ifdef` block around the definitions in `assembler_x86.hpp` (lines 12201 - 13773; and there's even a nested `#ifdef _LP64` (lines 13515-13585)!) , but declarations aren't guarded by `#ifdef _LP64`.
>
> Yeah, just got to about the same conclusion by looking at the preprocessor `-E` output.. its declared in the header, but not defined in the 'cpp' file.. One would think that that's a compile error, but its been more then a decade since I looked at the C++ spec; 'C++ compiler is always right'.

Don't know that there is anything else for me to do here? `assembler_x86.hpp` `#ifdef _LP64` macros were there before (and it not 'that wrong' or if a better/clean fix exists). `macroAssembler_x86.hpp` has to mirror that with `andq`.

(Just going through all the comments, making sure they have been addressed.) 

PS: In general I get worried about having macros changing object layout, but that's 'water under the bridge' and 64-bit seems big enough reason to have different layout. But its always 'entertaining debugging session' when offset of `a.f` is different in `a.o` and `b.o`, because somebody forgot to define same macros for `b.c` compile command as for `a.c`..

-------------

PR: https://git.openjdk.org/jdk/pull/10582


From duke at openjdk.org  Mon Nov 14 17:58:36 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 14 Nov 2022 17:58:36 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@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

Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - Vladimir's review
 - live review with Sandhya
 - jcheck
 - Sandhya's review
 - fix windows and 32b linux builds
 - add getLimbs to interface and reviews
 - fix 32-bit build
 - make UsePolyIntrinsics option diagnostic
 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - ... and 13 more: https://git.openjdk.org/jdk/compare/e269dc03...a26ac7db

-------------

Changes: https://git.openjdk.org/jdk/pull/10582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=15
  Stats: 1851 lines in 32 files changed: 1815 ins; 3 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  Mon Nov 14 17:58:37 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 14 Nov 2022 17:58:37 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v15]
In-Reply-To: <g9b4K88VLczZ7zoHN0oisP9Qju0EvlQWW5voCyJlGPQ=.6363291f-20aa-4fbc-9a81-96af9b54c76f@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <g9b4K88VLczZ7zoHN0oisP9Qju0EvlQWW5voCyJlGPQ=.6363291f-20aa-4fbc-9a81-96af9b54c76f@github.com>
Message-ID: <bleuvI4zHKuGW0CZdl_PJf0N5VUHoUzN7XtuPdOLfc8=.83be7f10-841e-40fe-b85b-ca8af13049f9@github.com>

On Fri, 11 Nov 2022 17:56:55 GMT, Volodymyr Paprotski <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