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

Try to get clean build, pull in https://github.com/openjdk/jdk/pull/11065

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

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

From vlivanov at openjdk.org  Mon Nov 14 18:39:29 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 14 Nov 2022 18:39:29 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v14]
In-Reply-To: <CShJXPrVP8_FNql7cOTu_GtUAkAQXi2OQBRwzksFULA=.1f2e9e51-226c-44da-a677-b437c3b2045c@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>
 <CShJXPrVP8_FNql7cOTu_GtUAkAQXi2OQBRwzksFULA=.1f2e9e51-226c-44da-a677-b437c3b2045c@github.com>
Message-ID: <yAcsnq-lwFhAyP7NWuFIDDmsEBcyvC7TDUk5ri8hu-4=.6d2bfb6d-23b7-4d88-b587-109a3e89550b@github.com>

On Mon, 14 Nov 2022 17:48:25 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

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

Leave it as is. It'll be addressed separately.

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

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

From mullan at openjdk.org  Mon Nov 14 18:45:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 14 Nov 2022 18:45:29 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <1SgjlQatBEnDkM7SKknVvONQZlTwxTM_1fQemk4-MbY=.14a019db-58c0-4dc8-af74-2b7d294c766c@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <ZIyMVSrvrcJL7cCkfeYGEo1Ti0uc8r--9seOCzpSTos=.12290c69-ddac-4f2a-a572-9f02d815d679@github.com>
 <1SgjlQatBEnDkM7SKknVvONQZlTwxTM_1fQemk4-MbY=.14a019db-58c0-4dc8-af74-2b7d294c766c@github.com>
Message-ID: <0JwKXTVP7rKAH_q7PdO4cBxfzqh516EOlvdropX57-M=.5247755b-5536-4695-b5f8-2d02639d9407@github.com>

On Fri, 11 Nov 2022 13:57:39 GMT, pandaapo <duke 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 also remove these methods from `JarFile`, `JavaUtilJarAccess` and its only implementation `JavaUtilJarAccessImpl`?

Yes. I believe the `setEagerValidation` method can also be removed and all code that calls it.

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

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

From weijun at openjdk.org  Mon Nov 14 19:51:13 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 19:51:13 GMT
Subject: Integrated: 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: <NmNbIcXMkmrqGNFo50XRGJ7aMVx7HI1QuJnbVeMyuek=.6195d689-c8a3-47a0-94f6-03182d58ff99@github.com>

On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Make two fields inside `CertificateValidity` final.

This pull request has now been integrated.

Changeset: a7c2338a
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7c2338a6d71bdbbceee9ad7481badc76456fadf
Stats:     112 lines in 2 files changed: 71 ins; 37 del; 4 mod

8296900: CertificateValidity fields are not optional

Reviewed-by: mullan

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

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

From mpowers at openjdk.org  Mon Nov 14 19:51:22 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 14 Nov 2022 19:51:22 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: <e6AZ0HbkwymsR3GHXV8k3QhZPkm4WtVv3sHB1bZDT8E=.78400fb0-7d10-4c29-a146-e0b67a103896@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/AuthorityKeyIdentifierExtension.java line 114:

> 112:                                            SerialNumber sn)
> 113:             throws IOException {
> 114:         if (kid == null && names == null && serialNum == null) {

Might want to mention in javadoc comment that at least one element must be non-null.

src/java.base/share/classes/sun/security/x509/NameConstraintsExtension.java line 142:

> 140:         if (permitted == null && excluded == null) {
> 141:             throw new IllegalArgumentException(
> 142:                     "permitted and exclude cannot be all null");

s/be all/both be/

src/java.base/share/classes/sun/security/x509/PolicyConstraintsExtension.java line 115:

> 113:         if (require == -1 && inhibit == -1) {
> 114:             throw new IllegalArgumentException(
> 115:                     "require and inhibit cannot be all -1");

s/be all/both be/

src/java.base/share/classes/sun/security/x509/PrivateKeyUsageExtension.java line 107:

> 105:         if (notBefore == null && notAfter == null) {
> 106:             throw new IllegalArgumentException(
> 107:                     "notBefore and notAfter cannot be all null");

s/be all/both be/

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

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

From valeriep at openjdk.org  Mon Nov 14 21:19:09 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 14 Nov 2022 21:19:09 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: <7vIKAl3__o1Kvr7omLmkY-TOxueXVfUSKaLL2C78K6Q=.5e7d0dc6-d72b-4886-aaeb-24dd10d40430@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

test/jdk/sun/security/pkcs/pkcs9/PKCS9AttrTypeTests.java line 176:

> 174:                 // Encoding is supported
> 175:                 DerOutputStream dos = new DerOutputStream();
> 176:                 p9Attr.encode(dos);

Should we check the encoding has the expected value? Otherwise, it looks like we only require that no exception is thrown?

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

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

From duke at openjdk.org  Mon Nov 14 21:29:08 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 14 Nov 2022 21:29:08 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
Message-ID: <O8EAjZwOmYlRKNZf5HTf5B4up562VoNdC6I4han2rzg=.a405f0e5-8264-49a2-a1ca-292e2b603f7d@github.com>

On Mon, 14 Nov 2022 17:58:36 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 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

(Build finally passing!)

Hi @TobiHartmann you had mentioned there were some more tests to run? Looking to see what else needs fixing. Thanks.

@iwanowww thanks for the reviews! As you have time, let me know what else you see or if its good for approval? Don't want to switch too much to another intrinsic yet, one crypto algorithm is about what I can fit into my brain at a time.

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

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

From valeriep at openjdk.org  Mon Nov 14 21:55:57 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 14 Nov 2022 21:55:57 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: <zoFd4Zu0gmjT2zRqTnmFeaTMfiGWFqsFRJdQ-uBiJJQ=.6e8e5541-ef04-4048-8f68-d1c1d5dde910@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

src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 381:

> 379:         index = indexOf(oid, PKCS9_OIDS, 1);
> 380:         Class<?> clazz = index == -1 ? BYTE_ARRAY_CLASS: VALUE_CLASSES[index];
> 381:         if (clazz == null || !clazz.isInstance(value)) {

If my reading of the current impl is correct, if clazz is null, the attribute is not supported. The error message seems a bit misleading as it's not really due to the value itself, but the attribute is not supported. Is it just for avoiding NPE and changing it into IAE?

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

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

From weijun at openjdk.org  Mon Nov 14 21:55:57 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 21:55:57 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v2]
In-Reply-To: <zoFd4Zu0gmjT2zRqTnmFeaTMfiGWFqsFRJdQ-uBiJJQ=.6e8e5541-ef04-4048-8f68-d1c1d5dde910@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>
 <zoFd4Zu0gmjT2zRqTnmFeaTMfiGWFqsFRJdQ-uBiJJQ=.6e8e5541-ef04-4048-8f68-d1c1d5dde910@github.com>
Message-ID: <d-MT6ntu6lRIgHwxrcsyv_oH6JbfXLwuUls40C42gmI=.71d307ff-c4db-4b51-8038-1e7c9d54e5d9@github.com>

On Mon, 14 Nov 2022 21:47:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make class package private
>
> src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 381:
> 
>> 379:         index = indexOf(oid, PKCS9_OIDS, 1);
>> 380:         Class<?> clazz = index == -1 ? BYTE_ARRAY_CLASS: VALUE_CLASSES[index];
>> 381:         if (clazz == null || !clazz.isInstance(value)) {
> 
> If my reading of the current impl is correct, if clazz is null, the attribute is not supported. The error message seems a bit misleading as it's not really due to the value itself, but the attribute is not supported. Is it just for avoiding NPE and changing it into IAE?

Yes, just to avoid NPE. I can see the message about type is null looks strange. I'll change it to something normal.

> test/jdk/sun/security/pkcs/pkcs9/PKCS9AttrTypeTests.java line 176:
> 
>> 174:                 // Encoding is supported
>> 175:                 DerOutputStream dos = new DerOutputStream();
>> 176:                 p9Attr.encode(dos);
> 
> Should we check the encoding has the expected value? Otherwise, it looks like we only require that no exception is thrown?

You mean comparing it with the original value? I tried that but not always the same. For example, a string might be an IA5String at the beginning but becomes a UTF8String after re-encoding.

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

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

From weijun at openjdk.org  Mon Nov 14 22:14:31 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 22:14:31 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v2]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <nE3zgii7k7hQcaapRIrM0yhW2X7PzdzFhhBQxshDxQ8=.bb03bf9c-a583-4faa-8389-fc31ddf78531@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  address Mark's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/73108231..b46cd8eb

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

  Stats: 29 lines in 17 files changed: 6 ins; 0 del; 23 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 22:19:32 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 14 Nov 2022 22:19:32 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v3]
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: <DY5ZEc8b3nJvIFOeUDvB-GWJ4IyaTP2Z2iZCi_X8bgM=.b4a3073e-309f-43a5-af05-e6952d0a9932@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:

  different message for null encoded

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11070/files
  - new: https://git.openjdk.org/jdk/pull/11070/files/8765c136..efc69f01

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

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 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 mpowers at openjdk.org  Mon Nov 14 23:01:13 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 14 Nov 2022 23:01:13 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
 [v2]
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <fsislld652ylInhcJO2HuPIgAovwBtxuLdST66SI_HE=.04a5e3a0-8f11-41fc-ab49-a0a53e9bdfd6@github.com>

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

Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - yes we need /dev/urandom
 - Merge
 - Merge
 - second iteration
 - Merge
 - first iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10716/files
  - new: https://git.openjdk.org/jdk/pull/10716/files/1375cc9b..2dc18e5c

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

  Stats: 58977 lines in 783 files changed: 18667 ins; 36419 del; 3891 mod
  Patch: https://git.openjdk.org/jdk/pull/10716.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10716/head:pull/10716

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

From sviswanathan at openjdk.org  Mon Nov 14 23:42:28 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 14 Nov 2022 23:42:28 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: <psMr8pmTuDtbyh_3LrTHo9v1ln_VKImuYz7UkX4MHeM=.368b4dc0-4f03-4cc4-8f27-1f8707cf4237@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

Marked as reviewed by sviswanathan (Reviewer).

The x86_64 code looks good to me.

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

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

From vlivanov at openjdk.org  Tue Nov 15 00:23:53 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Nov 2022 00:23:53 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
Message-ID: <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>

On Mon, 14 Nov 2022 17:58:36 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 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

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 103:

> 101: 
> 102: ATTRIBUTE_ALIGNED(64) uint64_t POLY1305_MASK44[] = {
> 103:   // OFFSET 64: mask_44

Redundant comment.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 384:

> 382: void StubGenerator::poly1305_limbs(const Register limbs, const Register a0, const Register a1, const Register a2, bool only128)
> 383: {
> 384:   const Register t1 = r13;

Please, make the temps explicit and lift them into arguments. Otherwise, it's hard to see what registers are clobbered when helper methods are called.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 387:

> 385:   const Register t2 = r14;
> 386: 
> 387:   __ movq(a0, Address(limbs, 0));

I don't understand how it works. `limbs` comes directly from `c_rarg2` and contains raw oop. So, `Address(limbs, 0)` reads object mark word rather than the first element from the array. 

(Same situation in `poly1305_limbs_out`. And now I'm curious why doesn't object header corruption trigger a crash.)

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 987:

> 985: 
> 986:   // Load R into r1:r0
> 987:   poly1305_limbs(R, r0, r1, r1, true);

What's the intention here when you pass `r1` twice? Just load `R[0]` and `R[2]`. You could use `noreg` to mark an optional operation and check for it in `poly1305_limbs` before loading the corresponding element.

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

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

From sviswanathan at openjdk.org  Tue Nov 15 00:28:06 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 15 Nov 2022 00:28:06 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
Message-ID: <-JVYIHKOY_LuVTqyH5xuubtPdk8pK_wi5z-8pestRis=.e63938ab-0ac2-4880-8238-e6e6d8debf03@github.com>

On Tue, 15 Nov 2022 00:10:35 GMT, Vladimir Ivanov <vlivanov 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 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
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 387:
> 
>> 385:   const Register t2 = r14;
>> 386: 
>> 387:   __ movq(a0, Address(limbs, 0));
> 
> I don't understand how it works. `limbs` comes directly from `c_rarg2` and contains raw oop. So, `Address(limbs, 0)` reads object mark word rather than the first element from the array. 
> 
> (Same situation in `poly1305_limbs_out`. And now I'm curious why doesn't object header corruption trigger a crash.)

library_call.cpp takes care of that, it passes the address of 0'th element to the stub.

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

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

From vlivanov at openjdk.org  Tue Nov 15 00:51:07 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Nov 2022 00:51:07 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <-JVYIHKOY_LuVTqyH5xuubtPdk8pK_wi5z-8pestRis=.e63938ab-0ac2-4880-8238-e6e6d8debf03@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
 <-JVYIHKOY_LuVTqyH5xuubtPdk8pK_wi5z-8pestRis=.e63938ab-0ac2-4880-8238-e6e6d8debf03@github.com>
Message-ID: <OfSiSh0ho8oFGm5lOgCGxw84XjHzQHdXvyDOcZBQBXo=.f243574a-c6aa-47b2-8bb1-7951232bf83d@github.com>

On Tue, 15 Nov 2022 00:25:46 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 387:
>> 
>>> 385:   const Register t2 = r14;
>>> 386: 
>>> 387:   __ movq(a0, Address(limbs, 0));
>> 
>> I don't understand how it works. `limbs` comes directly from `c_rarg2` and contains raw oop. So, `Address(limbs, 0)` reads object mark word rather than the first element from the array. 
>> 
>> (Same situation in `poly1305_limbs_out`. And now I'm curious why doesn't object header corruption trigger a crash.)
>
> library_call.cpp takes care of that, it passes the address of 0'th element to the stub.

Ah, got it. Worth elaborating that in the comments. Otherwise, they confuse rather than help:

  // void processBlocks(byte[] input, int len, int[5] a, int[5] r)
  const Register input        = rdi; //input+offset
  const Register length       = rbx;
  const Register accumulator  = rcx;
  const Register R            = r8;

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

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

From vlivanov at openjdk.org  Tue Nov 15 00:51:09 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Nov 2022 00:51:09 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
Message-ID: <XAAaQDoWmjbJ0coZZaBwpzxtDMbazRvX6yFPNexV3j4=.93142a64-e120-4f01-8801-d4a0f135c8f7@github.com>

On Mon, 14 Nov 2022 17:58:36 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 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

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

> 6974: 
> 6975:   if (!stubAddr) return false;
> 6976:   Node* input = argument(1);

Receiver null check is missing. Since the method being intrinsified is non-static, the intrinsic itself has to take care of receiver null check.

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

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

From jwaters at openjdk.org  Tue Nov 15 00:52:07 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 00:52:07 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
Message-ID: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>

On Mon, 14 Nov 2022 13:08:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

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

Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0)

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

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

From weijun at openjdk.org  Tue Nov 15 00:53:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 00:53:47 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL
Message-ID: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>

Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.

The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.

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

Commit messages:
 - remove trailing space
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11151/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296901
  Stats: 708 lines in 11 files changed: 294 ins; 313 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/11151.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11151/head:pull/11151

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

From weijun at openjdk.org  Tue Nov 15 00:53:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 00:53:49 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL
In-Reply-To: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
Message-ID: <9kZZAF2j4u5P62rSQ4ee5Xen9m8jO6KEvRcnTmHAOMc=.a5008ae7-8e57-4116-ad8a-4438a3dd74d6@github.com>

On Tue, 15 Nov 2022 00:35:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
> 
> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.

src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 365:

> 363:      */
> 364:     public X509CRLImpl(TBSCertList info, AlgorithmId sigAlgId, byte[] signature,
> 365:                        byte[] tbsCertList, byte[] signedCRL) {

In fact, all arguments must be non null. Only the last one is checked to emphasize that the encoding must be provided. This constructor is also used in tests to create fake CRLs where not all fields are available.

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

> 120:      */
> 121:     public X509CertImpl(X509CertInfo info, AlgorithmId algId, byte[] signature,
> 122:                         byte[] signedCert) {

In fact, all arguments must be non null. Only the last one is checked to emphasize that the encoding must be provided. This constructor is also used in tests to create fake certificates where not all fields are available.

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

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

From valeriep at openjdk.org  Tue Nov 15 00:56:04 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 15 Nov 2022 00:56:04 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v3]
In-Reply-To: <DY5ZEc8b3nJvIFOeUDvB-GWJ4IyaTP2Z2iZCi_X8bgM=.b4a3073e-309f-43a5-af05-e6952d0a9932@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <DY5ZEc8b3nJvIFOeUDvB-GWJ4IyaTP2Z2iZCi_X8bgM=.b4a3073e-309f-43a5-af05-e6952d0a9932@github.com>
Message-ID: <PXmFEpER4vmuIBN3-EbDQh3J-4GSwOWIv4iTIek48Es=.d9d1da7f-4522-4fda-985d-131054628e71@github.com>

On Mon, 14 Nov 2022 22:19:32 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:
> 
>   different message for null encoded

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.org  Tue Nov 15 00:56:04 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 15 Nov 2022 00:56:04 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v2]
In-Reply-To: <d-MT6ntu6lRIgHwxrcsyv_oH6JbfXLwuUls40C42gmI=.71d307ff-c4db-4b51-8038-1e7c9d54e5d9@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>
 <zoFd4Zu0gmjT2zRqTnmFeaTMfiGWFqsFRJdQ-uBiJJQ=.6e8e5541-ef04-4048-8f68-d1c1d5dde910@github.com>
 <d-MT6ntu6lRIgHwxrcsyv_oH6JbfXLwuUls40C42gmI=.71d307ff-c4db-4b51-8038-1e7c9d54e5d9@github.com>
Message-ID: <FOEXofUXW2nSy_RgjDQWJbYMSw6FZMaLUuNDO2JIVwo=.8c97cf22-d736-4edf-930f-c7d51c97591d@github.com>

On Mon, 14 Nov 2022 21:44:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs/pkcs9/PKCS9AttrTypeTests.java line 176:
>> 
>>> 174:                 // Encoding is supported
>>> 175:                 DerOutputStream dos = new DerOutputStream();
>>> 176:                 p9Attr.encode(dos);
>> 
>> Should we check the encoding has the expected value? Otherwise, it looks like we only require that no exception is thrown?
>
> You mean comparing it with the original value? I tried that but not always the same. For example, a string might be an IA5String at the beginning but becomes a UTF8String after re-encoding.

I see, not surprising, perhaps just checking that it's not empty? Or even that may not hold true?

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

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

From weijun at openjdk.org  Tue Nov 15 02:50:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 02:50:10 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v2]
In-Reply-To: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
Message-ID: <fIg-QICI6Po-fdH3b3o6KkZW_OgwvnFtx7IBb7E-rQw=.c3e79f1d-e6ff-4d1f-8914-15ba9fa8de36@github.com>

> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
> 
> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.

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

  a method called by test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11151/files
  - new: https://git.openjdk.org/jdk/pull/11151/files/b7134909..3d031083

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

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

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

From kbarrett at openjdk.org  Tue Nov 15 06:42:58 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Nov 2022 06:42:58 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
Message-ID: <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>

On Mon, 14 Nov 2022 16:12:48 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:
> 
>   Revert to using simpler solution similar to the original 8274980

A few more issues as I slog my way through this commingled PR.  Probably more to come.

src/hotspot/share/utilities/globalDefinitions.hpp line 50:

> 48: 
> 49: #ifndef ATTRIBUTE_ALIGNED
> 50: #define ATTRIBUTE_ALIGNED(x) alignas(x)

HotSpot Group has not discussed or approved use of `alignas` - see https://bugs.openjdk.org/browse/JDK-8250269.  This is another change that is independent of most of the rest of this PR, and should be dealt with separately.  The various MSVC-conditional direct uses of `_declspec(align(N))` should probably currently be using `ATTRIBUTE_ALIGNED`.

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

Changes requested by kbarrett (Reviewer).

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

From kbarrett at openjdk.org  Tue Nov 15 06:42:59 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Nov 2022 06:42:59 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
 <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>
Message-ID: <S1wp3kCTkaV5pa7NNeFP57Zrf2JFGs9BNzMC1dYkfXU=.262781f6-e561-42e2-893d-918cf6fc189b@github.com>

On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 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.
>
> Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0)

Sorry, but I don't think that's much better than the prior version, and still doesn't seem better than the current code.  What problem is this change supposed to be solving?  I didn't find any open bugs that seemed relevant (could be I just didn't recognize such).  Whatever it is seems likely to be unrelated to any of the other changes in this PR; it would have been / would be better to deal with it separately.

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

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

From kbarrett at openjdk.org  Tue Nov 15 06:42:59 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Nov 2022 06:42:59 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
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: <V_tHKXIx0k0HzvHk3hnP9vVP4F0Vx4uD9a1oz5DTi54=.d8437f88-81fc-4412-a2ee-074fd4c6e9c1@github.com>

On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

I also think the macro name should be left alone.  It's the file suffix that is "bad", though I'm not convinced it's so bad as to be worth changing.  (There's also `TARGET_COMPILER_visCPP`.)

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

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

From thartmann at openjdk.org  Tue Nov 15 06:55:53 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 15 Nov 2022 06:55:53 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v3]
In-Reply-To: <9XWZNcNcmELCLXDwpuNgpztPrw8xXajJQcj_daf4jhU=.4af44336-021f-4688-9a56-6a90c8e12f53@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <W_qQO4k5o0HZkFFjKpRIQpNRBG5ggCHata3b2f3ggR8=.9b4e4686-96a1-4c7c-a3da-449092a25d18@github.com>
 <9XWZNcNcmELCLXDwpuNgpztPrw8xXajJQcj_daf4jhU=.4af44336-021f-4688-9a56-6a90c8e12f53@github.com>
Message-ID: <l0lf2AhMm1HQObe9BcdfgnWHENQGEVuwWBmh9Fa8Jmg=.55171123-f70a-423c-b702-cb537e011bbd@github.com>

On Mon, 24 Oct 2022 09:02:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volodymyr Paprotski has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   further restrict UsePolyIntrinsics with supports_avx512vlbw
>
> Thanks, I'll re-run testing.

> Hi @TobiHartmann you had mentioned there were some more tests to run? Looking to see what else needs fixing. Thanks.

Sure, I re-submitted testing.

EDIT: I see that Vladimir already did that.

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

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

From djelinski at openjdk.org  Tue Nov 15 11:32:30 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 15 Nov 2022 11:32:30 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
 [v2]
In-Reply-To: <fsislld652ylInhcJO2HuPIgAovwBtxuLdST66SI_HE=.04a5e3a0-8f11-41fc-ab49-a0a53e9bdfd6@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
 <fsislld652ylInhcJO2HuPIgAovwBtxuLdST66SI_HE=.04a5e3a0-8f11-41fc-ab49-a0a53e9bdfd6@github.com>
Message-ID: <4TGnHyVBpRB0kF3PDNGQibnKP9GUZmX1e2xmogm80vM=.0a36ff96-6cd1-41f2-867c-6512edd1af3a@github.com>

On Mon, 14 Nov 2022 23:01:13 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293412
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - yes we need /dev/urandom
>  - Merge
>  - Merge
>  - second iteration
>  - Merge
>  - first iteration

Thanks! LGTM.

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

Marked as reviewed by djelinski (Committer).

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

From hannesw at openjdk.org  Tue Nov 15 12:23:15 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 15 Nov 2022 12:23:15 GMT
Subject: RFR: JDK-8277074: Qualified exported types show up in JavaDoc
Message-ID: <xR3kgCjjyFNOCQ2zSYEkv5HjktzCsFsahCsbNGs5Tw4=.ec8b3808-fe12-41b1-986a-64dd67073c3c@github.com>

Please review a simple change to hide internal classes in generated documentation by adding doc comments containing a `@hidden` tag. I verified the fix by making sure `grep -r jdk.internal` returns no matches in the generated documentation tree.

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

Commit messages:
 - JDK-8277074: Qualified exported types show up in JavaDoc

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

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

From jwaters at openjdk.org  Tue Nov 15 12:25:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 12:25:06 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <S1wp3kCTkaV5pa7NNeFP57Zrf2JFGs9BNzMC1dYkfXU=.262781f6-e561-42e2-893d-918cf6fc189b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
 <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>
 <S1wp3kCTkaV5pa7NNeFP57Zrf2JFGs9BNzMC1dYkfXU=.262781f6-e561-42e2-893d-918cf6fc189b@github.com>
Message-ID: <iSTDY2tJsH0cZdGm-b43DfFGTQN8vKa_hBBHMgjKu_k=.3c3d967c-1bd7-43f1-85a5-aa5a3ece6171@github.com>

On Tue, 15 Nov 2022 06:12:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0)
>
> Sorry, but I don't think that's much better than the prior version, and still doesn't seem better than the current code.  What problem is this change supposed to be solving?  I didn't find any open bugs that seemed relevant (could be I just didn't recognize such).  Whatever it is seems likely to be unrelated to any of the other changes in this PR; it would have been / would be better to deal with it separately.

It's related to the JEP-223 version build numbers, which the original commit couldn't get to work due to a preprocessor trick not working with the now unsupported 2017. I just felt it could be included here out of convenience, but I guess I can split it off into another change if required

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

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

From jwaters at openjdk.org  Tue Nov 15 12:34:04 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 12:34:04 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <PqiJunKhY85BbqgIB5X96kg16Dm-mTszPAFzYOjsfWs=.ebb72cc2-e4e0-4e8f-823e-1f5f97881a6a@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>
 <PqiJunKhY85BbqgIB5X96kg16Dm-mTszPAFzYOjsfWs=.ebb72cc2-e4e0-4e8f-823e-1f5f97881a6a@github.com>
Message-ID: <cRXeR6mdu1s4Vy4P-1TDPTCdnso0soubbR2tSeVvYiY=.3d543774-2096-4b96-89e7-50aec40fa96b@github.com>

On Mon, 14 Nov 2022 13:06:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

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

I was under the assumption that anything not listed under "Not discussed" or "Forbidden" was free game in HotSpot, I apologise for my goof since that isn't the case. That said, I am curious if there are any isolated conversations about the attribute syntax anywhere

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

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

From duke at openjdk.org  Tue Nov 15 13:32:59 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 15 Nov 2022 13:32:59 GMT
Subject: RFR: 8294731: Improve multiplicative inverse for secp256r1
 implementation [v6]
In-Reply-To: <bJZOGjoJ-Kk-F9Dx-BqdGvgmQWiXZ2akSKt4eV5I1bg=.cb342702-8c72-4bc3-a890-41e0aff4ba20@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
 <bJZOGjoJ-Kk-F9Dx-BqdGvgmQWiXZ2akSKt4eV5I1bg=.cb342702-8c72-4bc3-a890-41e0aff4ba20@github.com>
Message-ID: <GzxOXf7GEb5KfS0O_BZHIlP6LnQ4Q-F6_P6i0G7jlbE=.e9ff75eb-e632-4049-bbc5-a523f5cda6d7@github.com>

On Sat, 12 Nov 2022 18:52:59 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 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

It looks good to me.

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

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

From coleenp at openjdk.org  Tue Nov 15 14:15:02 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Nov 2022 14:15:02 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
Message-ID: <iF4tdByM8y7NzhFfm2dbJ38l39Ld8CZIPdt3zC7w_d4=.eda73685-fe4a-41cf-b39f-d8134c6c1f9c@github.com>

On Mon, 14 Nov 2022 16:12:48 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:
> 
>   Revert to using simpler solution similar to the original 8274980

Can you have separate PRs for each type of thing you're changing?

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

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

From aph at openjdk.org  Tue Nov 15 14:20:43 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:43 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator)
Message-ID: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>

JEP 429 implementation.

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

Commit messages:
 - Update StressStackOverflow
 - Release _scopedValueCache after use
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - Update src/java.base/share/classes/jdk/internal/vm/ScopedValueContainer.java
 - Rename test
 - Update
 - Whitespace
 - Rewrite ScopedValue stress test
 - Reviewer feedback
 - Reviewer feedback
 - ... and 10 more: https://git.openjdk.org/jdk/compare/d4d183ed...0d72ca2f

Changes: https://git.openjdk.org/jdk/pull/10952/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286666
  Stats: 3272 lines in 52 files changed: 2868 ins; 246 del; 158 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

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

From dlong at openjdk.org  Tue Nov 15 14:20:47 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 15 Nov 2022 14:20:47 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/hotspot/share/prims/jvm.cpp line 1410:

> 1408:       loc = 3;
> 1409:     } else if (method == resolver.thread_run_method) {
> 1410:       loc = 2;

This depends on how javac numbers locals, right?  It seems a bit fragile.  This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets.

src/java.base/share/classes/jdk/internal/vm/ScopedValueContainer.java line 53:

> 51:     /**
> 52:      * Returns the "latest" ScopedValueContainer for the current Thread. This may be on
> 53:      * the current thread's scope task or ma require walking up the tree to find it.

Suggestion:

     * the current thread's scope task or may require walking up the tree to find it.

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

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

From aph at openjdk.org  Tue Nov 15 14:20:48 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:48 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>
Message-ID: <dkd9EyTzZJXTs_6-x0NF6VpAhP9CXyi2o9fla7WcOJM=.3cc41e07-6f17-4d9d-ad98-e372a0c421bb@github.com>

On Fri, 4 Nov 2022 23:17:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> JEP 429 implementation.
>
> src/hotspot/share/prims/jvm.cpp line 1410:
> 
>> 1408:       loc = 3;
>> 1409:     } else if (method == resolver.thread_run_method) {
>> 1410:       loc = 2;
> 
> This depends on how javac numbers locals, right?  It seems a bit fragile.  This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets.

Ah, good point. I'll have a look at doing that.

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

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

From aph at openjdk.org  Tue Nov 15 14:20:48 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:48 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <dkd9EyTzZJXTs_6-x0NF6VpAhP9CXyi2o9fla7WcOJM=.3cc41e07-6f17-4d9d-ad98-e372a0c421bb@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>
 <dkd9EyTzZJXTs_6-x0NF6VpAhP9CXyi2o9fla7WcOJM=.3cc41e07-6f17-4d9d-ad98-e372a0c421bb@github.com>
Message-ID: <buDIXmfTPJUOV6ITOJzStRgl2rTMugKZov6HCrNSHgY=.e8cdf866-d68e-4edd-922e-a7c776019ff0@github.com>

On Thu, 10 Nov 2022 17:42:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1410:
>> 
>>> 1408:       loc = 3;
>>> 1409:     } else if (method == resolver.thread_run_method) {
>>> 1410:       loc = 2;
>> 
>> This depends on how javac numbers locals, right?  It seems a bit fragile.  This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets.
>
> Ah, good point. I'll have a look at doing that.

Done.

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

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

From alanb at openjdk.org  Tue Nov 15 14:20:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 14:20:50 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/hotspot/share/prims/jvm.cpp line 4072:

> 4070:  */
> 4071: JVM_ENTRY(void, JVM_EnsureMaterializedForStackWalk_func(JNIEnv* env, jobject vthread, jobject value))
> 4072:   //asm("nop");

The asm("nop") was commented out to get the build working. Its inserted by the compiler now so I assume the commented now asm can be removed.

src/java.base/share/classes/java/lang/VirtualThread.java line 318:

> 316:         }
> 317:     }
> 318:     @Hidden

Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can?

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

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

From aph at openjdk.org  Tue Nov 15 14:20:53 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:53 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>
Message-ID: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>

On Thu, 3 Nov 2022 11:50:17 GMT, ExE Boss <duke at openjdk.org> wrote:

>> JEP 429 implementation.
>
> src/java.base/share/classes/java/lang/Thread.java line 1610:
> 
>> 1608:             ensureMaterializedForStackWalk(bindings);
>> 1609:             task.run();
>> 1610:             Reference.reachabilityFence(bindings);
> 
> This?should probably?be?in a?`try`?`finally`?block:
> Suggestion:
> 
>             try {
>                 task.run();
>             } finally {
>                 Reference.reachabilityFence(bindings);
>             }

I wonder. The pattern I'm using here is based on `AccessController.executePrivileged`, which doesn't have the `finally` clause. Perhaps I should add one here anyway.

> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481:
> 
>> 479:         }
>> 480:  */
>> 481:         return findBinding() != Snapshot.NIL;
> 
> This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of:
> 
> if (SCOPED_VALUE.isBound()) {
> 	final var value = SCOPED_VALUE.get();
> 	// do something with `value`
> }
> 
> 
> --------------------------------------------------------------------------------
> 
> Suggestion:
> 
>         var value = findBinding();
>         if (value == Snapshot.NIL) {
>             return false;
>         }
>         Cache.put(this, value);
>         return true;

Probably so, yes. I'll have a look at that along with caching failure.

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

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

From duke at openjdk.org  Tue Nov 15 14:20:53 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 15 Nov 2022 14:20:53 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/java.base/share/classes/java/lang/Thread.java line 1610:

> 1608:             ensureMaterializedForStackWalk(bindings);
> 1609:             task.run();
> 1610:             Reference.reachabilityFence(bindings);

This?should probably?be?in a?`try`?`finally`?block:
Suggestion:

            try {
                task.run();
            } finally {
                Reference.reachabilityFence(bindings);
            }

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481:

> 479:         }
> 480:  */
> 481:         return findBinding() != Snapshot.NIL;

This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of:

if (SCOPED_VALUE.isBound()) {
	final var value = SCOPED_VALUE.get();
	// do something with `value`
}


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

Suggestion:

        var value = findBinding();
        if (value == Snapshot.NIL) {
            return false;
        }
        Cache.put(this, value);
        return true;

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

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

From dlong at openjdk.org  Tue Nov 15 14:20:54 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 15 Nov 2022 14:20:54 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>
 <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>
Message-ID: <kXgHNrHUMWBv50mRCkzuOOT9wNCoNzpSHGmaCmP5gGE=.27f2e129-b410-4a74-a14b-c41ea260f72e@github.com>

On Fri, 4 Nov 2022 09:53:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1610:
>> 
>>> 1608:             ensureMaterializedForStackWalk(bindings);
>>> 1609:             task.run();
>>> 1610:             Reference.reachabilityFence(bindings);
>> 
>> This?should probably?be?in a?`try`?`finally`?block:
>> Suggestion:
>> 
>>             try {
>>                 task.run();
>>             } finally {
>>                 Reference.reachabilityFence(bindings);
>>             }
>
> I wonder. The pattern I'm using here is based on `AccessController.executePrivileged`, which doesn't have the `finally` clause. Perhaps I should add one here anyway.

I hope it doesn't matter.  There is an example in the reachabilityFence javadocs where it does not use finally.  For it to matter, I think the compiler would need to inline through run() and prove that it can throw an exception, but I don't think that's how the JIT compilers currently implement reachabilityFence.  I suppose a finally shouldn't hurt, however.

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

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

From aph at openjdk.org  Tue Nov 15 14:20:55 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:55 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>
Message-ID: <Yj81L0TMKWcS5VBcJfGyzQQVfAr0mtM10YMyfQJp2WY=.a37e4cff-c9cc-47f2-ad49-661151cc27e0@github.com>

On Mon, 14 Nov 2022 17:34:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 429 implementation.
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 318:
> 
>> 316:         }
>> 317:     }
>> 318:     @Hidden
> 
> Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can?

OK. I do want to keep the name of this method consistent throughout. There are version for `Runnable` and `Callable` and it makes the runtime code cleaner if they have the same name.

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

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

From aph at openjdk.org  Tue Nov 15 14:20:56 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:56 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <3lVtaG-K0g_3M_-8_lszieivuJ4a88CKmyWj0MH8cgU=.fc28bd92-72ec-4eff-962f-06c7404954fd@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 475:

> 473:         // ??? Do we want to search cache for this? In most cases we don't expect
> 474:         // this {@link ScopedValue} to be bound, so it's not worth it. But I may
> 475:         // be wrong about that.

We should make it switchable by a runtime parameter. We should optionally cache failures.
Add a microbenchmark for that.

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

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

From sean.mullan at oracle.com  Tue Nov 15 14:34:36 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 15 Nov 2022 09:34:36 -0500
Subject: Undo deprecation of brainpool EC
In-Reply-To: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>
References: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>
Message-ID: <27e37532-be19-3ccd-8d8c-6a19c2b3dda2@oracle.com>

Hi,

Thanks for your questions about brainpool. See below for more details.

On 11/14/22 3:36 AM, benjamin.marwell at f-i.de wrote:
> 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.

The word "deprecated" may have been the wrong word to use when referring
to the brainpool curves, although I will note that the IANA registry
still lists them as not recommended for TLS [1].

We don't have any issues with the brainpool curves as we do for
some of the other legacy curves. But, these curves were implemented in
native C code and we changed the structure of the JDK EC implementation
such that all curves that were implemented in C were removed. The
remaining curves that we do support are implemented in Java and use
modern techniques and complete formulas.

It has not been a priority for us to re-implement brainpool. And with
recently added support for EdDSA and the future with PQC, it's not
likely we will circle back to them.

We are ok with a contribution, but they would need to be done using
the current design structure and using complete formulas.

--Sean

[1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

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

From aph at openjdk.org  Tue Nov 15 14:57:35 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:57:35 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v2]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <8Yik6EmjgjWQSz-lAL99OFhis_ZpNTP3IGYyebnggyM=.67de9502-136c-4a17-b6fe-9cb89b72c37a@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Update test
 - Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/0d72ca2f..4bd44d66

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

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

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

From jnimeh at openjdk.org  Tue Nov 15 14:57:30 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 15 Nov 2022 14:57:30 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v3]
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: <oETF54Wm1GiGgxVPDTzdA9cPIXez9Lgu7pq7rif8aHw=.82267473-4f18-433c-942e-dab9dc77dab6@github.com>

On Tue, 1 Nov 2022 18:38:21 GMT, Vladimir Ivanov <vlivanov 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
>
> 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.

I think I'd like to handle this as a follow-on enhancement.

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

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

From alanb at openjdk.org  Tue Nov 15 15:06:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 15:06:05 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v2]
In-Reply-To: <Yj81L0TMKWcS5VBcJfGyzQQVfAr0mtM10YMyfQJp2WY=.a37e4cff-c9cc-47f2-ad49-661151cc27e0@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>
 <Yj81L0TMKWcS5VBcJfGyzQQVfAr0mtM10YMyfQJp2WY=.a37e4cff-c9cc-47f2-ad49-661151cc27e0@github.com>
Message-ID: <p0meBnMWhQHcgk4Zxz9jbZThPkQNBFNC9mBA54mEqCc=.9f60a7d8-149d-4372-83a7-8166c4b2e3f1@github.com>

On Tue, 15 Nov 2022 14:15:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 318:
>> 
>>> 316:         }
>>> 317:     }
>>> 318:     @Hidden
>> 
>> Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can?
>
> OK. I do want to keep the name of this method consistent throughout. There are version for `Runnable` and `Callable` and it makes the runtime code cleaner if they have the same name.

The other thing here is that there two calls to reachabilityFence, it shouldn't need both.

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

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

From weijun at openjdk.org  Tue Nov 15 15:32:50 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 15:32:50 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v4]
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: <VOpwxbcoGcket-HZ901kdMLNGkVFv0oYQCF-6AEHaG0=.8ea87973-c83e-41bd-baab-7c3c0e458427@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:

  enhance test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11070/files
  - new: https://git.openjdk.org/jdk/pull/11070/files/efc69f01..e8af4309

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

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 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  Tue Nov 15 15:32:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 15:32:51 GMT
Subject: RFR: 8296736: Some PKCS9Attribute can be created but cannot be
 encoded [v2]
In-Reply-To: <FOEXofUXW2nSy_RgjDQWJbYMSw6FZMaLUuNDO2JIVwo=.8c97cf22-d736-4edf-930f-c7d51c97591d@github.com>
References: <sEiOfL_NRS-Mbh7rCtd1QMXx1pXiA3uo7kRlFJ4kjVs=.e6a72702-8b7e-4911-8c0c-add943d70b70@github.com>
 <BykTcdwrUJBaP0oZ-oFSP6mlXAMWpg1o1Z-MzpfV1_A=.77ab5fca-40a7-4d35-89ba-cb6fc551e81f@github.com>
 <zoFd4Zu0gmjT2zRqTnmFeaTMfiGWFqsFRJdQ-uBiJJQ=.6e8e5541-ef04-4048-8f68-d1c1d5dde910@github.com>
 <d-MT6ntu6lRIgHwxrcsyv_oH6JbfXLwuUls40C42gmI=.71d307ff-c4db-4b51-8038-1e7c9d54e5d9@github.com>
 <FOEXofUXW2nSy_RgjDQWJbYMSw6FZMaLUuNDO2JIVwo=.8c97cf22-d736-4edf-930f-c7d51c97591d@github.com>
Message-ID: <uxy9LmhyWRqIMpGNVOTC8EjcQJporMkEgeq88qPoiCo=.03aa4f4b-7ca3-4a0c-8a99-0f540db8c851@github.com>

On Tue, 15 Nov 2022 00:49:23 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> You mean comparing it with the original value? I tried that but not always the same. For example, a string might be an IA5String at the beginning but becomes a UTF8String after re-encoding.
>
> I see, not surprising, perhaps just checking that it's not empty? Or even that may not hold true?

That should be true. The constructor on bytes ensures either a value is assigned or an exception is thrown. I'll add a check.

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

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

From weijun at openjdk.org  Tue Nov 15 15:36:21 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 15:36:21 GMT
Subject: Integrated: 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: <38PiOd_aNF0OIVwrCJC3gRjaCm_Y1u4yjrxOYbXLBnU=.96dff139-8147-4028-8775-1baa607c1529@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.

This pull request has now been integrated.

Changeset: d3051a75
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3051a75a37db5c8582c3040a220d15f4c29a851
Stats:     82 lines in 3 files changed: 35 ins; 4 del; 43 mod

8296736: Some PKCS9Attribute can be created but cannot be encoded

Reviewed-by: xuelei, valeriep

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

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

From aph at openjdk.org  Tue Nov 15 15:52:22 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 15:52:22 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v3]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <upL_LOJRbB9XCJtuvA7rHX3CzZe34ZgbK50GeS_dFhs=.d5490421-c718-4e53-9b7d-cbb24f3a7b0f@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/4bd44d66..442a04ef

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

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

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

From xuelei at openjdk.org  Tue Nov 15 15:58:39 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 15:58:39 GMT
Subject: Integrated: 8294731: Improve multiplicative inverse for secp256r1
 implementation
In-Reply-To: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
References: <yGkpZMlXn8rV9WjxLo2oKF6QQCQ4SPyZLlvyxjxaCBI=.6768a1ac-d10f-48bc-901e-4cb0810219ba@github.com>
Message-ID: <3eCaZc-nQLtpeAVZamKbOG6zSjjNnoWJq_66JmjAIFs=.559e4292-476d-4db0-9681-7a963a645f43@github.com>

On Mon, 3 Oct 2022 19:00:44 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

This pull request has now been integrated.

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

8294731: Improve multiplicative inverse for secp256r1 implementation

Reviewed-by: djelinski, jjiang

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

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

From xuelei.f at gmail.com  Tue Nov 15 16:02:30 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Tue, 15 Nov 2022 08:02:30 -0800
Subject: Undo deprecation of brainpool EC
In-Reply-To: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>
References: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>
Message-ID: <0580EF25-FCF0-4867-B5DB-B61C6D0BE7B4@gmail.com>

Hi Benjamin,

May I ask what are the sizes of brainpool curves used in practice?

Thank,
Xuelei

> On Nov 14, 2022, at 12:36 AM, benjamin.marwell at f-i.de wrote:
> 
> 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 
> 


From weijun at openjdk.org  Tue Nov 15 16:03:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 16:03:04 GMT
Subject: RFR: 8296818: Enhance JMH tests java/security/Signatures.java
In-Reply-To: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
References: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
Message-ID: <41wzBc5-WCin3vaRuj7wxi9aZ5ccJ5gGlIOpoYL_Q4w=.61e741e1-23ca-496d-a118-93a4f3d97b2e@github.com>

On Mon, 14 Nov 2022 05:11:33 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> 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

test/micro/org/openjdk/bench/java/security/Signatures.java line 39:

> 37: @Fork(jvmArgsAppend = {"-Xms1024m", "-Xmx1024m", "-Xmn768m", "-XX:+UseParallelGC"}, value = 3)
> 38: public class Signatures {
> 39:     private static Signature signer;

Not a JMH expert. Is it possible to make `Signatures` abstract and move the ECDSA codes into a subclass just like for other algorithms?

test/micro/org/openjdk/bench/java/security/Signatures.java line 152:

> 150: 
> 151:     public static class RSASSAPSS extends Signatures {
> 152:         @Param({"SHA256withRSASSA-PSS", "SHA3846withRSASSA-PSS", "SHA512withRSASSA-PSS"})

Since this test is only about RSASSA-PSS, you can probably only use "SHA256" etc above. Otherwise I keep thinking about whether these are real signature algorithm names. :-)

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

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

From xuelei at openjdk.org  Tue Nov 15 17:32:14 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 17:32:14 GMT
Subject: RFR: 8296818: Enhance JMH tests java/security/Signatures.java [v2]
In-Reply-To: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
References: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
Message-ID: <OP71SkHJ4YShGoKi9GP539fpRR-4AWTVrubsmQc-kFY=.310ef32f-49ea-4170-855a-2d5a6d42f829@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

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

  use hash algorithm for RSASSA-PSS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11131/files
  - new: https://git.openjdk.org/jdk/pull/11131/files/67be4fe7..1506eda6

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

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 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 xuelei at openjdk.org  Tue Nov 15 17:32:14 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 17:32:14 GMT
Subject: RFR: 8296818: Enhance JMH tests java/security/Signatures.java [v2]
In-Reply-To: <41wzBc5-WCin3vaRuj7wxi9aZ5ccJ5gGlIOpoYL_Q4w=.61e741e1-23ca-496d-a118-93a4f3d97b2e@github.com>
References: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
 <41wzBc5-WCin3vaRuj7wxi9aZ5ccJ5gGlIOpoYL_Q4w=.61e741e1-23ca-496d-a118-93a4f3d97b2e@github.com>
Message-ID: <etnPt8xhjnfIbaJt-pu-mX0ty8-9ACBpShDDH6i8l2k=.27d00fc0-08f1-4bed-94e0-c97cd99bfcd3@github.com>

On Tue, 15 Nov 2022 16:00:36 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 hash algorithm for RSASSA-PSS
>
> test/micro/org/openjdk/bench/java/security/Signatures.java line 39:
> 
>> 37: @Fork(jvmArgsAppend = {"-Xms1024m", "-Xmx1024m", "-Xmn768m", "-XX:+UseParallelGC"}, value = 3)
>> 38: public class Signatures {
>> 39:     private static Signature signer;
> 
> Not a JMH expert. Is it possible to make `Signatures` abstract and move the ECDSA codes into a subclass just like for other algorithms?

I had the same concerns about the style.  But I did not find a way to make it.

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

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

From xuelei at openjdk.org  Tue Nov 15 17:35:02 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 17:35:02 GMT
Subject: RFR: 8296818: Enhance JMH tests java/security/Signatures.java [v3]
In-Reply-To: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
References: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
Message-ID: <4TA3Dq1qVOplHBHnGVagOimibhJBNod997LpsVuKT3U=.5a1222d5-cf12-403d-94f6-af0a917c04c5@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

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

  typo and missing correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11131/files
  - new: https://git.openjdk.org/jdk/pull/11131/files/1506eda6..df9ad369

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

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 duke at openjdk.org  Tue Nov 15 17:44:12 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 17:44:12 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
Message-ID: <i2KXAYD9RaayPF684xwQgBredelBO5O6oyO28aETB0E=.329c21c6-84cb-4354-849d-0fdf8ca19e59@github.com>

On Tue, 15 Nov 2022 00:06:40 GMT, Vladimir Ivanov <vlivanov 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 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
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 384:
> 
>> 382: void StubGenerator::poly1305_limbs(const Register limbs, const Register a0, const Register a1, const Register a2, bool only128)
>> 383: {
>> 384:   const Register t1 = r13;
> 
> Please, make the temps explicit and lift them into arguments. Otherwise, it's hard to see what registers are clobbered when helper methods are called.

Thanks for pointing this out.. I spent quite a bit of time and went back and forth on 'register allocation'... it does make sense to pass all the temps needed, when the number of temps is small. This is the case for the three `*_limbs_*` functions. Maybe I should indeed do that...

On other hand, there are functions like `poly1305_multiply8_avx512` and `poly1305_process_blocks_avx512` that use a _lot_ of temp registers. I think it makes sense to keep those as 'function-header declarations'. 

Then there are functions like `poly1305_multiply_scalar` that could go either way, has some temps and 'implicitly clobbered' registers, but probably should stay 'as is'..

I ended up being 'pedantic' and making _all_ temps into 'header variables'. I also tried to comment, but those probably mean more to me then anyone else in hindsight?


// Register Map:
// GPRs:
//   input        = rdi
//   length       = rbx
//   accumulator  = rcx
//   R   = r8
//   a0  = rsi
//   a1  = r9
//   a2  = r10
//   r0  = r11
//   r1  = r12
//   c1  = r8;
//   t1  = r13
//   t2  = r14
//   t3  = r15
//   t0  = r14
//   rscratch = r13
//   stack(rsp, rbp)
//   imul(rax, rdx)
// ZMMs:
//   T: xmm0-6
//   C: xmm7-9
//   A: xmm13-18
//   B: xmm19-24
//   R: xmm25-29
...
  // Register Map:
  // reserved: rsp, rbp, rcx
  // PARAMs: rdi, rbx, rsi, r8-r12
  // poly1305_multiply_scalar clobbers: r13-r15, rax, rdx
  const Register t0 = r14;
  const Register t1 = r13;
  const Register rscratch = r13;

  // poly1305_limbs_avx512 clobbers: xmm0, xmm1
  // poly1305_multiply8_avx512 clobbers: xmm0-xmm6
  const XMMRegister T0 = xmm2;
...


I think I am ok changing the `*limbs*` functions (even started, before I remembered my train of thought from months back..) but let me know if you agree with the rest of the reasoning?

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

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

From darcy at openjdk.org  Tue Nov 15 17:53:36 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Nov 2022 17:53:36 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <QL270-p64Gwgmm_nGnQMmmFN3Wxkp4ymQnZaFF6OeAo=.728937f2-c68f-4b5e-a271-b8e15abed62c@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

Marked as reviewed by darcy (Reviewer).

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

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

From mullan at openjdk.org  Tue Nov 15 17:53:35 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 17:53:35 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance noting
 subsequent behavior if protocol is disabled
Message-ID: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>

Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

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

Commit messages:
 - Update wording for SunJSSE provider.
 - Initial revision.

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

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

From xuelei at openjdk.org  Tue Nov 15 18:30:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 18:30:16 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking.  Here are some cases I'm aware of:
1. the protocol is disabled with Security property
2. the protocol is not set while setting the SSLParameters
3. the protocol is not set while set the enabled protocol
4. the protocol is not supported by the peer
5. the protocol is not supported by any cipher suites enabled.

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

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

From mullan at openjdk.org  Tue Nov 15 18:40:04 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 18:40:04 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
Message-ID: <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>

On Tue, 15 Nov 2022 18:27:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking. Here are some cases I'm aware of:
> 
> 1. the protocol is disabled with Security property
> 2. the protocol is not set while setting the SSLParameters
> 3. the protocol is not set while set the enabled protocol
> 4. the protocol is not supported by the peer
> 5. the protocol is not supported by any cipher suites enabled.

Good point, but I feel that should be handled in a separate issue, if necessary. Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. The JCK team requested this clarification.

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

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

From xuelei at openjdk.org  Tue Nov 15 19:10:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 19:10:58 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
Message-ID: <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>

On Tue, 15 Nov 2022 18:37:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking. Here are some cases I'm aware of:
> > 
> > 1. the protocol is disabled with Security property
> > 2. the protocol is not set while setting the SSLParameters
> > 3. the protocol is not set while set the enabled protocol
> > 4. the protocol is not supported by the peer
> > 5. the protocol is not supported by any cipher suites enabled.
> 
> Good point, but I feel that should be handled in a separate issue, if necessary.

If it will be addressed in the future issue, the current specification may need to weight the impact in.  Otherwise, the specification added here might need to re-work to cover more cases.

> Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. The JCK team requested this clarification.

I understand the concerns.  There are many cases in security components that an instance could return, but will not work in the following process if not set or configured properly.   The impact of disabled properties is just one case of many.  Maybe, a simple description is sufficient, "the instance may not work if not configured or set properly, for example ... ".

It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as  an application still can have the protocol back by overriding the default security properties.

BTW, the protocol for SSLContext.getInstance() method is not a TLS protocol.  It is more of a context-algorithm.  For example, SSLContext.getInstance("TLSv1.3") could support TLS 1.0/1.1/1.2/1.3.  It may be not usual, but if TLS 1.3 is disabled, and TLS 1.2 not, the connection should be able to established with TLS 1.2.  In the description, it would be nice to make it clean what the 'protocol" means in different circumstances.

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

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

From xuelei at openjdk.org  Tue Nov 15 19:16:07 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 19:16:07 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
Message-ID: <uwtKczbW2Hf3qN9uaMpE58reGbYfK5xuw9SWXpAJNUM=.7ad26adb-3a34-4eb5-9358-bbe58ec2c625@github.com>

On Tue, 15 Nov 2022 19:07:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as an application still can have the protocol back by overriding the default security properties.

I may be wrong.  The security property may be just loaded one time, and the follow-on update will not take effect.  If it is the case, is it an option to stop at  SSLContext.getInstance()?

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

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

From duke at openjdk.org  Tue Nov 15 19:43:11 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 19:43:11 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v17]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <7hXP-vwxc6J7fklu8QuJqiIcSQRff-QyR1SZ0Fzfqmc=.33a38a51-38c3-451a-a756-ed538507f04e@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 25 commits:

 - Vladimir's review comments
 - Merge remote-tracking branch 'origin/master' into avx512-poly
 - 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
 - ... and 15 more: https://git.openjdk.org/jdk/compare/7357a1a3...8f5942d9

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

Changes: https://git.openjdk.org/jdk/pull/10582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=16
  Stats: 1859 lines in 32 files changed: 1823 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  Tue Nov 15 19:43:18 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 19:43:18 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <i2KXAYD9RaayPF684xwQgBredelBO5O6oyO28aETB0E=.329c21c6-84cb-4354-849d-0fdf8ca19e59@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
 <i2KXAYD9RaayPF684xwQgBredelBO5O6oyO28aETB0E=.329c21c6-84cb-4354-849d-0fdf8ca19e59@github.com>
Message-ID: <r_1O7IZ10L42qLo58Al4P7vopxNimqQf_JGXTozhSrQ=.02f7ac95-6ee2-409c-8730-649eae6835fe@github.com>

On Tue, 15 Nov 2022 17:42:08 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 384:
>> 
>>> 382: void StubGenerator::poly1305_limbs(const Register limbs, const Register a0, const Register a1, const Register a2, bool only128)
>>> 383: {
>>> 384:   const Register t1 = r13;
>> 
>> Please, make the temps explicit and lift them into arguments. Otherwise, it's hard to see what registers are clobbered when helper methods are called.
>
> Thanks for pointing this out.. I spent quite a bit of time and went back and forth on 'register allocation'... it does make sense to pass all the temps needed, when the number of temps is small. This is the case for the three `*_limbs_*` functions. Maybe I should indeed do that...
> 
> On other hand, there are functions like `poly1305_multiply8_avx512` and `poly1305_process_blocks_avx512` that use a _lot_ of temp registers. I think it makes sense to keep those as 'function-header declarations'. 
> 
> Then there are functions like `poly1305_multiply_scalar` that could go either way, has some temps and 'implicitly clobbered' registers, but probably should stay 'as is'..
> 
> I ended up being 'pedantic' and making _all_ temps into 'header variables'. I also tried to comment, but those probably mean more to me then anyone else in hindsight?
> 
> 
> // Register Map:
> // GPRs:
> //   input        = rdi
> //   length       = rbx
> //   accumulator  = rcx
> //   R   = r8
> //   a0  = rsi
> //   a1  = r9
> //   a2  = r10
> //   r0  = r11
> //   r1  = r12
> //   c1  = r8;
> //   t1  = r13
> //   t2  = r14
> //   t3  = r15
> //   t0  = r14
> //   rscratch = r13
> //   stack(rsp, rbp)
> //   imul(rax, rdx)
> // ZMMs:
> //   T: xmm0-6
> //   C: xmm7-9
> //   A: xmm13-18
> //   B: xmm19-24
> //   R: xmm25-29
> ...
>   // Register Map:
>   // reserved: rsp, rbp, rcx
>   // PARAMs: rdi, rbx, rsi, r8-r12
>   // poly1305_multiply_scalar clobbers: r13-r15, rax, rdx
>   const Register t0 = r14;
>   const Register t1 = r13;
>   const Register rscratch = r13;
> 
>   // poly1305_limbs_avx512 clobbers: xmm0, xmm1
>   // poly1305_multiply8_avx512 clobbers: xmm0-xmm6
>   const XMMRegister T0 = xmm2;
> ...
> 
> 
> I think I am ok changing the `*limbs*` functions (even started, before I remembered my train of thought from months back..) but let me know if you agree with the rest of the reasoning?

Changed just the three `*limbs*` functions.

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

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

From duke at openjdk.org  Tue Nov 15 19:43:18 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 19:43:18 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <OfSiSh0ho8oFGm5lOgCGxw84XjHzQHdXvyDOcZBQBXo=.f243574a-c6aa-47b2-8bb1-7951232bf83d@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
 <-JVYIHKOY_LuVTqyH5xuubtPdk8pK_wi5z-8pestRis=.e63938ab-0ac2-4880-8238-e6e6d8debf03@github.com>
 <OfSiSh0ho8oFGm5lOgCGxw84XjHzQHdXvyDOcZBQBXo=.f243574a-c6aa-47b2-8bb1-7951232bf83d@github.com>
Message-ID: <9p2RTAI9FPWstQu0OtpSmSB7dqhFwmxbw86zZQg4GtU=.1be10660-ee5d-4654-9d4e-4fe3e449fd9b@github.com>

On Tue, 15 Nov 2022 00:45:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> library_call.cpp takes care of that, it passes the address of 0'th element to the stub.
>
> Ah, got it. Worth elaborating that in the comments. Otherwise, they confuse rather than help:
> 
>   // void processBlocks(byte[] input, int len, int[5] a, int[5] r)
>   const Register input        = rdi; //input+offset
>   const Register length       = rbx;
>   const Register accumulator  = rcx;
>   const Register R            = r8;

Added a comment, hopefully less confusing.

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

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

From duke at openjdk.org  Tue Nov 15 19:43:17 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 19:43:17 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
Message-ID: <5Jz1ZjH_bvH1Imw-Dptwrg9vZFA9lP8PNxnUWjnCru8=.18040fe2-6520-425a-8836-fe382a1e2f34@github.com>

On Tue, 15 Nov 2022 00:16:19 GMT, Vladimir Ivanov <vlivanov 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 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
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 103:
> 
>> 101: 
>> 102: ATTRIBUTE_ALIGNED(64) uint64_t POLY1305_MASK44[] = {
>> 103:   // OFFSET 64: mask_44
> 
> Redundant comment.

done

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 987:
> 
>> 985: 
>> 986:   // Load R into r1:r0
>> 987:   poly1305_limbs(R, r0, r1, r1, true);
> 
> What's the intention here when you pass `r1` twice? Just load `R[0]` and `R[2]`. You could use `noreg` to mark an optional operation and check for it in `poly1305_limbs` before loading the corresponding element.

ah, I was wondering how to make an 'optional reg' when parameter is not a pointer. `noreg` is exactly what I needed, thanks.

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

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

From duke at openjdk.org  Tue Nov 15 19:46:52 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 19:46:52 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <XAAaQDoWmjbJ0coZZaBwpzxtDMbazRvX6yFPNexV3j4=.93142a64-e120-4f01-8801-d4a0f135c8f7@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <XAAaQDoWmjbJ0coZZaBwpzxtDMbazRvX6yFPNexV3j4=.93142a64-e120-4f01-8801-d4a0f135c8f7@github.com>
Message-ID: <XZfwH5OtUeO0O3EKFTF3dKxMftTrL29UNpVHIDgLkio=.c0551eb8-c53f-4fa5-b6de-e457ffc96455@github.com>

On Tue, 15 Nov 2022 00:43:16 GMT, Vladimir Ivanov <vlivanov 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 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
>
> src/hotspot/share/opto/library_call.cpp line 6976:
> 
>> 6974: 
>> 6975:   if (!stubAddr) return false;
>> 6976:   Node* input = argument(1);
> 
> Receiver null check is missing. Since the method being intrinsified is non-static, the intrinsic itself has to take care of receiver null check.

I think I found the right code to copy-paste, if you could check again pls.

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

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

From duke at openjdk.org  Tue Nov 15 19:46:48 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 19:46:48 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v18]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <cFcXfBYId3XkRceQX9YEy9sO_uiloIorhRVmCq0448I=.2ae3dc2a-e8d7-4808-abdf-a786369e1dae@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:

  extra whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/8f5942d9..58488f42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=16-17

  Stats: 2 lines in 1 file changed: 0 ins; 0 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  Tue Nov 15 20:09:41 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Nov 2022 20:09:41 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v19]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <n0xQtihBTiXQpZr-I8R9T6yWou774yVTsOaJFxBp9ak=.531509bc-0c30-47f0-8bec-a412d4052664@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:

  use noreg properly in poly1305_limbs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/58488f42..cbf49380

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=17-18

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

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

From weijun at openjdk.org  Tue Nov 15 20:48:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 20:48:11 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v3]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <dMH_c1PSUDriZoAE0vO4jxtzlfh_kIx8X3lISCoB3i8=.f676112b-3572-4ff4-ace6-152a7197c147@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  one more extension
  
  only in patch2:
  unchanged:

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/b46cd8eb..fc315aeb

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Tue Nov 15 20:49:03 2022
From: duke at openjdk.org (Xubo Zhang)
Date: Tue, 15 Nov 2022 20:49:03 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
Message-ID: <vv42s4M3H1A85iwTTMsaCMSDmthxab_SMngxQYQMVYA=.d7955142-c48a-48d2-bd95-94aac8044e89@github.com>

On Mon, 14 Nov 2022 16:37:41 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>
>
> 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>

Hi [XueleiFan](https://github.com/XueleiFan)
This shouldn't be the case unless there is a kernel bug. Multiple threads using ThreadLocal to access /dev/random is just like multiple applications accessing it.

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

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

From weijun at openjdk.org  Tue Nov 15 20:55:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 20:55:51 GMT
Subject: RFR: 8297074: Use enhanced-for cycle instead of Enumeration in
 javax.crypto
In-Reply-To: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
References: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
Message-ID: <Du3BLHDRCwgOi5jfZ_b6lGvsSUR4r_6rKEfwz3qBckY=.26e87bfa-835f-48c1-8df8-f1c08a8a77f1@github.com>

On Mon, 7 Nov 2022 16:54:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> java.util.Enumeration is a legacy interface from java 1.0.
> There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 232:

> 230:         // find out if there is anything we should add into
> 231:         // ret.
> 232:         for (var entry : perms.entrySet()) {

Can we keep the old style? i.e. iterate over `for (var alg : this.perms.keySet())`?

Same with the change on line 270 below.

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

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

From aturbanov at openjdk.org  Tue Nov 15 20:55:51 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Nov 2022 20:55:51 GMT
Subject: RFR: 8297074: Use enhanced-for cycle instead of Enumeration in
 javax.crypto
Message-ID: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>

java.util.Enumeration is a legacy interface from java 1.0.
There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

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

Commit messages:
 - 8297074: Use enhanced-for cycle instead of Enumeration in javax.crypto
 - [PATCH] Use enhanced-for cycle instead of Enumeration in javax.crypto
 - [PATCH] Use enhanced-for cycle instead of Enumeration in javax.crypto

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

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

From aturbanov at openjdk.org  Tue Nov 15 20:55:52 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Nov 2022 20:55:52 GMT
Subject: RFR: 8297074: Use enhanced-for cycle instead of Enumeration in
 javax.crypto
In-Reply-To: <Du3BLHDRCwgOi5jfZ_b6lGvsSUR4r_6rKEfwz3qBckY=.26e87bfa-835f-48c1-8df8-f1c08a8a77f1@github.com>
References: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
 <Du3BLHDRCwgOi5jfZ_b6lGvsSUR4r_6rKEfwz3qBckY=.26e87bfa-835f-48c1-8df8-f1c08a8a77f1@github.com>
Message-ID: <xMwwSTfAWn857I0_noPeFQEwknNz6BxUIoCrEWhqgT4=.ddf1af77-c4e5-4636-ae7e-9f546c8e2e01@github.com>

On Tue, 15 Nov 2022 16:07:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> java.util.Enumeration is a legacy interface from java 1.0.
>> There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.
>
> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 232:
> 
>> 230:         // find out if there is anything we should add into
>> 231:         // ret.
>> 232:         for (var entry : perms.entrySet()) {
> 
> Can we keep the old style? i.e. iterate over `for (var alg : this.perms.keySet())`?
> 
> Same with the change on line 270 below.

Ok. reverted this part.

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

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

From mullan at openjdk.org  Tue Nov 15 21:17:34 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 21:17: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: <SeBzowNcYZ-i_HbmWoUnOZ0c1T_4BX647lbOrBXs4ds=.a053231a-9a56-45ea-9b31-16a39f3e9494@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

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 62:

> 60:     // The "encryptionAlgorithm" field. If this object is created by
> 61:     // {@link #EncryptedPrivateKeyInfo(AlgorithmParameters, byte[])}
> 62:     // with an uninitialized params, it's stored here and algid is null.

A bit confused by the words "it's stored here" if it is always null for the case where the params are uninitialized. How about: "... with an uninitialized params, algid is null."

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

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

From weijun at openjdk.org  Tue Nov 15 21:42:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 21:42:37 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <SeBzowNcYZ-i_HbmWoUnOZ0c1T_4BX647lbOrBXs4ds=.a053231a-9a56-45ea-9b31-16a39f3e9494@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
 <SeBzowNcYZ-i_HbmWoUnOZ0c1T_4BX647lbOrBXs4ds=.a053231a-9a56-45ea-9b31-16a39f3e9494@github.com>
Message-ID: <6IuH59LuaDkRFhSuo131Zd4cF3PaDKgsg4D1s-x2MYU=.5802cfb0-fee8-41d1-b31e-220f75d4ffb8@github.com>

On Tue, 15 Nov 2022 21:13:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   expected
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 62:
> 
>> 60:     // The "encryptionAlgorithm" field. If this object is created by
>> 61:     // {@link #EncryptedPrivateKeyInfo(AlgorithmParameters, byte[])}
>> 62:     // with an uninitialized params, it's stored here and algid is null.
> 
> A bit confused by the words "it's stored here" if it is always null for the case where the params are uninitialized. How about: "... with an uninitialized params, algid is null."

How about "...with an uninitialized AlgorithmParameters, the AlgorithmParameters object is store in the params field and algid is null". This should be clear.

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

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

From mullan at openjdk.org  Tue Nov 15 21:56:32 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 21:56:32 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: <mLZz482KWRRnNLRz2vE_T4FrRfamg0nYjPLy74GWa0Y=.26516b97-bd98-403f-b028-67294725db11@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

Still reviewing, but here are a few comments.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 63:

> 61:     // {@link #EncryptedPrivateKeyInfo(AlgorithmParameters, byte[])}
> 62:     // with an uninitialized params, it's stored here and algid is null.
> 63:     // In all other case, algid is non null and params is null.

s/case/cases/.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 65:

> 63:     // In all other case, algid is non null and params is null.
> 64:     private final AlgorithmId algid;
> 65:     private final AlgorithmParameters params;

Perhaps add a comment for this field since the others have comments.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 119:

> 117:     }
> 118: 
> 119:     MacData(AlgorithmParameters algParams, byte[] digest,

Is this related to this issue in some way or just a ctor that is not used?

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

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

From mullan at openjdk.org  Tue Nov 15 21:56:35 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 21:56:35 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <6IuH59LuaDkRFhSuo131Zd4cF3PaDKgsg4D1s-x2MYU=.5802cfb0-fee8-41d1-b31e-220f75d4ffb8@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
 <SeBzowNcYZ-i_HbmWoUnOZ0c1T_4BX647lbOrBXs4ds=.a053231a-9a56-45ea-9b31-16a39f3e9494@github.com>
 <6IuH59LuaDkRFhSuo131Zd4cF3PaDKgsg4D1s-x2MYU=.5802cfb0-fee8-41d1-b31e-220f75d4ffb8@github.com>
Message-ID: <KR3Dlbt853SRfWt6Q2vnD_gmt312TsBjg4Ue03DWz74=.af8bd26c-0a53-4f42-afb9-8d1024e6a1cc@github.com>

On Tue, 15 Nov 2022 21:39:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 62:
>> 
>>> 60:     // The "encryptionAlgorithm" field. If this object is created by
>>> 61:     // {@link #EncryptedPrivateKeyInfo(AlgorithmParameters, byte[])}
>>> 62:     // with an uninitialized params, it's stored here and algid is null.
>> 
>> A bit confused by the words "it's stored here" if it is always null for the case where the params are uninitialized. How about: "... with an uninitialized params, algid is null."
>
> How about "...with an uninitialized AlgorithmParameters, the AlgorithmParameters object is store in the params field and algid is null". This should be clear.

ok but change "store" to "stored" and "algid" to "algid is set to null".

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

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

From weijun at openjdk.org  Tue Nov 15 21:56:36 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 21:56:36 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <mLZz482KWRRnNLRz2vE_T4FrRfamg0nYjPLy74GWa0Y=.26516b97-bd98-403f-b028-67294725db11@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
 <mLZz482KWRRnNLRz2vE_T4FrRfamg0nYjPLy74GWa0Y=.26516b97-bd98-403f-b028-67294725db11@github.com>
Message-ID: <YX1nqE3C7ZPVyDAdjp4-xmDLmTcGxmVQdth9gcK1m_Q=.0e3b6fd9-5db7-4c63-bd68-6abf95191122@github.com>

On Tue, 15 Nov 2022 21:44:52 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   expected
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 119:
> 
>> 117:     }
>> 118: 
>> 119:     MacData(AlgorithmParameters algParams, byte[] digest,
> 
> Is this related to this issue in some way or just a ctor that is not used?

The constructor is not used anywhere, and it has an `AlgorithmParameters ` argument that could also be uninitialized.

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

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

From mullan at openjdk.org  Tue Nov 15 21:56:38 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 21:56:38 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <rhrLPtqZOaCLSOWjbRGiv98a0tKlzffr1tuLRDS-2Hc=.29658a4a-aeb0-4481-99ad-3009c0d1bc9c@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
 <rhrLPtqZOaCLSOWjbRGiv98a0tKlzffr1tuLRDS-2Hc=.29658a4a-aeb0-4481-99ad-3009c0d1bc9c@github.com>
Message-ID: <6dpngy50nkDivqKTWAoXVEV0IbdZHmOPjJDiMKPMaQg=.7ce0a0fc-eb03-47f1-890e-f05f3dc72be4@github.com>

On Thu, 10 Nov 2022 15:03:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

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

Would it be more correct to change the message to "AlgorithmParameters are not initialized or cannot be decoded"?

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

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

From weijun at openjdk.org  Tue Nov 15 21:56:39 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 21:56:39 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <6dpngy50nkDivqKTWAoXVEV0IbdZHmOPjJDiMKPMaQg=.7ce0a0fc-eb03-47f1-890e-f05f3dc72be4@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
 <rhrLPtqZOaCLSOWjbRGiv98a0tKlzffr1tuLRDS-2Hc=.29658a4a-aeb0-4481-99ad-3009c0d1bc9c@github.com>
 <6dpngy50nkDivqKTWAoXVEV0IbdZHmOPjJDiMKPMaQg=.7ce0a0fc-eb03-47f1-890e-f05f3dc72be4@github.com>
Message-ID: <7EHgfntPuBlDdB9_N9u9RQfUfOCkXIBRtYXgH2VSXOk=.4098363c-e283-4e94-88bd-2900698ce95a@github.com>

On Tue, 15 Nov 2022 21:48:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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).
>
> Would it be more correct to change the message to "AlgorithmParameters are not initialized or cannot be decoded"?

Yes, that's more precise.

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

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

From mullan at openjdk.org  Tue Nov 15 22:14:06 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 22:14:06 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <uwtKczbW2Hf3qN9uaMpE58reGbYfK5xuw9SWXpAJNUM=.7ad26adb-3a34-4eb5-9358-bbe58ec2c625@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
 <uwtKczbW2Hf3qN9uaMpE58reGbYfK5xuw9SWXpAJNUM=.7ad26adb-3a34-4eb5-9358-bbe58ec2c625@github.com>
Message-ID: <ie3peEkx2TL9hjiU8rSK-E39PdhjZwyjJDxk6z-bAN8=.b756abe4-f842-4d04-92f3-6e09a5b2a2c6@github.com>

On Tue, 15 Nov 2022 19:12:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as an application still can have the protocol back by overriding the default security properties.
> 
> I may be wrong. The security property may be just loaded one time, and the follow-on update will not take effect. If it is the case, is it an option to stop at SSLContext.getInstance()?

It is not specified if the property is read only once or multiple times. However, the JDK implementation reads it once and also when it creates an SSLContext, so there is no chance to modify it later.

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

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

From weijun at openjdk.org  Tue Nov 15 22:23:01 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 22:23:01 GMT
Subject: RFR: 8297074: Use enhanced-for cycle instead of Enumeration in
 javax.crypto
In-Reply-To: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
References: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
Message-ID: <OdwG3Cl91gTzBZK-hv-idoEH_iscMCwCAZ20sb8yRxU=.31a01493-3011-41c2-980c-36514ac869eb@github.com>

On Mon, 7 Nov 2022 16:54:32 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.

Look good. Thanks for the fix!

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

Marked as reviewed by weijun (Reviewer).

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

From weijun at openjdk.org  Tue Nov 15 22:24:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 15 Nov 2022 22:24:07 GMT
Subject: RFR: 8296818: Enhance JMH tests java/security/Signatures.java [v3]
In-Reply-To: <4TA3Dq1qVOplHBHnGVagOimibhJBNod997LpsVuKT3U=.5a1222d5-cf12-403d-94f6-af0a917c04c5@github.com>
References: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
 <4TA3Dq1qVOplHBHnGVagOimibhJBNod997LpsVuKT3U=.5a1222d5-cf12-403d-94f6-af0a917c04c5@github.com>
Message-ID: <Is4R3_wPjjTERbiHC_Mw2i8nIf5glCztPSgkpbRjBsE=.b35834a9-b76d-4200-85ef-7f0e7a706b1b@github.com>

On Tue, 15 Nov 2022 17:35:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> 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
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo and missing correction

Marked as reviewed by weijun (Reviewer).

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

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

From ascarpino at openjdk.org  Tue Nov 15 22:48:45 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 15 Nov 2022 22:48:45 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
Message-ID: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>

I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.

The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.


    JDK 17:   122913.554 ops/sec
    JDK 19:    94885.008 ops/sec
    Post fix: 122735.804 ops/sec 

There is no regression test because this is a memory change and test coverage already existing.

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

Commit messages:
 - comment cleanup & finesse ByteBuffer implGCMCrypt better
 - comment cleanup
 - include byte[] methods as part of the heapBB change
 - split len is not trigger
 - initial

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

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

From mullan at openjdk.org  Tue Nov 15 22:56:09 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 22:56:09 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
Message-ID: <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>

On Tue, 15 Nov 2022 19:07:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> If it will be addressed in the future issue, the current specification may need to weight the impact in. Otherwise, the specification added here might need to re-work to cover more cases.

Which is fine. But we can still cover the behavior of `jdk.tls.disabledAlgorithms` in this one.

> > Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. The JCK team requested this clarification.
> 
> I understand the concerns. There are many cases in security components that an instance could return, but will not work in the following process if not set or configured properly. The impact of disabled properties is just one case of many. Maybe, a simple description is sufficient, "the instance may not work if not configured or set properly, for example ... ".

But I don't think there is general confusion over those other scenarios, so I am wary about going down that path where we feel obligated to document all possible scenarios. People using TLS should already know that a connection may not succeed for various reasons and the SSLException should provide a good reason for that. However, this one is not very visible and could be somewhat surprising.  An application may want to query the `jdk.tls.disabledAlgorithms` property and make sure the protocol is not disabled before creating the `SSLContext`. Although, in practice, we recommend calling `SSLContext.getDefault`.

> It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as an application still can have the protocol back by overriding the default security properties.

It won't work - see my other reply.

> 
> BTW, the protocol for SSLContext.getInstance() method is not a TLS protocol. It is more of a context-algorithm. For example, SSLContext.getInstance("TLSv1.3") could support TLS 1.0/1.1/1.2/1.3. It may be not usual, but if TLS 1.3 is disabled, and TLS 1.2 not, the connection should be able to established with TLS 1.2. In the description, it would be nice to make it clean what the 'protocol" means in different circumstances.

Yes, it might be useful to add something like "The returned SSLContext implements the specified protocol version, and may also implement other protocol versions." But I think it could be covered in a separate issue.

The wording in this PR specifically refers to the protocol version that was specified. It isn't covering other optional protocols that may be supported.

I would like to hear from others if they feel this note is useful, or if it is opening up more questions that not.

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

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

From vlivanov at openjdk.org  Tue Nov 15 23:56:57 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Nov 2022 23:56:57 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
Message-ID: <QaZ2HofRpsSEDgL-WPjiOtuuk-WMZ7Hvfm7dgNb6OSo=.cd60e9e2-9470-488e-8889-6860b0d33d73@github.com>

On Mon, 14 Nov 2022 17:58:36 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 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

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 370:

> 368:   // Middle 44-bit limbs of new blocks
> 369:   __ vpsrlq(L1, L0, 44, Assembler::AVX_512bit);
> 370:   __ vpsllq(TMP2, TMP1, 20, Assembler::AVX_512bit);

Any particular reason to use `TMP2` here? Can you just update `TMP1` instead (w/ `vpsllq(TMP1, TMP1, 20, Assembler::AVX_512bit);`)?

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

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

From vlivanov at openjdk.org  Tue Nov 15 23:56:59 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Nov 2022 23:56:59 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <i2KXAYD9RaayPF684xwQgBredelBO5O6oyO28aETB0E=.329c21c6-84cb-4354-849d-0fdf8ca19e59@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
 <i2KXAYD9RaayPF684xwQgBredelBO5O6oyO28aETB0E=.329c21c6-84cb-4354-849d-0fdf8ca19e59@github.com>
Message-ID: <6ks_fjBAWGK7eqIki9sA9oWjTOheJR-JAakGUx5t6Ro=.df7278d3-5d28-4219-819f-74c73dfb0677@github.com>

On Tue, 15 Nov 2022 17:42:08 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 384:
>> 
>>> 382: void StubGenerator::poly1305_limbs(const Register limbs, const Register a0, const Register a1, const Register a2, bool only128)
>>> 383: {
>>> 384:   const Register t1 = r13;
>> 
>> Please, make the temps explicit and lift them into arguments. Otherwise, it's hard to see what registers are clobbered when helper methods are called.
>
> Thanks for pointing this out.. I spent quite a bit of time and went back and forth on 'register allocation'... it does make sense to pass all the temps needed, when the number of temps is small. This is the case for the three `*_limbs_*` functions. Maybe I should indeed do that...
> 
> On other hand, there are functions like `poly1305_multiply8_avx512` and `poly1305_process_blocks_avx512` that use a _lot_ of temp registers. I think it makes sense to keep those as 'function-header declarations'. 
> 
> Then there are functions like `poly1305_multiply_scalar` that could go either way, has some temps and 'implicitly clobbered' registers, but probably should stay 'as is'..
> 
> I ended up being 'pedantic' and making _all_ temps into 'header variables'. I also tried to comment, but those probably mean more to me then anyone else in hindsight?
> 
> 
> // Register Map:
> // GPRs:
> //   input        = rdi
> //   length       = rbx
> //   accumulator  = rcx
> //   R   = r8
> //   a0  = rsi
> //   a1  = r9
> //   a2  = r10
> //   r0  = r11
> //   r1  = r12
> //   c1  = r8;
> //   t1  = r13
> //   t2  = r14
> //   t3  = r15
> //   t0  = r14
> //   rscratch = r13
> //   stack(rsp, rbp)
> //   imul(rax, rdx)
> // ZMMs:
> //   T: xmm0-6
> //   C: xmm7-9
> //   A: xmm13-18
> //   B: xmm19-24
> //   R: xmm25-29
> ...
>   // Register Map:
>   // reserved: rsp, rbp, rcx
>   // PARAMs: rdi, rbx, rsi, r8-r12
>   // poly1305_multiply_scalar clobbers: r13-r15, rax, rdx
>   const Register t0 = r14;
>   const Register t1 = r13;
>   const Register rscratch = r13;
> 
>   // poly1305_limbs_avx512 clobbers: xmm0, xmm1
>   // poly1305_multiply8_avx512 clobbers: xmm0-xmm6
>   const XMMRegister T0 = xmm2;
> ...
> 
> 
> I think I am ok changing the `*limbs*` functions (even started, before I remembered my train of thought from months back..) but let me know if you agree with the rest of the reasoning?

> On other hand, there are functions like poly1305_multiply8_avx512 and poly1305_process_blocks_avx512 that use a lot of temp registers. I think it makes sense to keep those as 'function-header declarations'.

I agree with you on `poly1305_process_blocks_avx512`, but `poly1305_multiply8_avx512` already takes 8 arguments. Putting 8 more arguments for temps doesn't look prohibitive. 

> I think it makes sense to keep those as 'function-header declarations'.

IMO it's not enough. Ideally, if there are any implicit usages, those should be clearly spelled out at every call site.

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

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

From vlivanov at openjdk.org  Tue Nov 15 23:57:00 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Nov 2022 23:57:00 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <9p2RTAI9FPWstQu0OtpSmSB7dqhFwmxbw86zZQg4GtU=.1be10660-ee5d-4654-9d4e-4fe3e449fd9b@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
 <-JVYIHKOY_LuVTqyH5xuubtPdk8pK_wi5z-8pestRis=.e63938ab-0ac2-4880-8238-e6e6d8debf03@github.com>
 <OfSiSh0ho8oFGm5lOgCGxw84XjHzQHdXvyDOcZBQBXo=.f243574a-c6aa-47b2-8bb1-7951232bf83d@github.com>
 <9p2RTAI9FPWstQu0OtpSmSB7dqhFwmxbw86zZQg4GtU=.1be10660-ee5d-4654-9d4e-4fe3e449fd9b@github.com>
Message-ID: <jOU2YrKbL5IN9drxis9yPT_AlliER47yfWT82oCm8_g=.92f9a11a-4f49-4897-974d-f77c5d4b6a21@github.com>

On Tue, 15 Nov 2022 19:38:26 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Ah, got it. Worth elaborating that in the comments. Otherwise, they confuse rather than help:
>> 
>>   // void processBlocks(byte[] input, int len, int[5] a, int[5] r)
>>   const Register input        = rdi; //input+offset
>>   const Register length       = rbx;
>>   const Register accumulator  = rcx;
>>   const Register R            = r8;
>
> Added a comment, hopefully less confusing.

On a second thought, passing derived pointers as arguments doesn't mix well with safepoint awareness.
(And this stub eventually has to become safepoint aware.)
Deriving a pointer inside the stub from a base oop and offset is trivial, recovering base oop from derived pointer is hard. 

It doesn't mean we have to address it right now.

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

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

From vlivanov at openjdk.org  Tue Nov 15 23:57:04 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Nov 2022 23:57:04 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v17]
In-Reply-To: <7hXP-vwxc6J7fklu8QuJqiIcSQRff-QyR1SZ0Fzfqmc=.33a38a51-38c3-451a-a756-ed538507f04e@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <7hXP-vwxc6J7fklu8QuJqiIcSQRff-QyR1SZ0Fzfqmc=.33a38a51-38c3-451a-a756-ed538507f04e@github.com>
Message-ID: <fw96wWvrsbFqCZc16QUimZ6Cg0OhKARsTY-oeRbfT-I=.5bc6a1e2-d99d-4784-9b41-d4722793c613@github.com>

On Tue, 15 Nov 2022 19:43: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 25 commits:
> 
>  - Vladimir's review comments
>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>  - 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
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/7357a1a3...8f5942d9

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 896:

> 894: 
> 895:   // Cleanup
> 896:   __ vpxorq(xmm0, xmm0, xmm0, Assembler::AVX_512bit);

What's the purpose of the cleanup?

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1004:

> 1002:   __ jcc(Assembler::less, L_process16Loop);
> 1003: 
> 1004:   poly1305_process_blocks_avx512(input, length,

I'd like to see a comment here explaining what register effects are implicit.

`poly1305_process_blocks_avx512` has the following comment, but it doesn't mention xmm registers:

  // Register Map:
  // reserved: rsp, rbp, rcx
  // PARAMs: rdi, rbx, rsi, r8-r12
  // poly1305_multiply_scalar clobbers: r13-r15, rax, rdx

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

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

From duke at openjdk.org  Wed Nov 16 00:08:07 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 00:08:07 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v17]
In-Reply-To: <fw96wWvrsbFqCZc16QUimZ6Cg0OhKARsTY-oeRbfT-I=.5bc6a1e2-d99d-4784-9b41-d4722793c613@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <7hXP-vwxc6J7fklu8QuJqiIcSQRff-QyR1SZ0Fzfqmc=.33a38a51-38c3-451a-a756-ed538507f04e@github.com>
 <fw96wWvrsbFqCZc16QUimZ6Cg0OhKARsTY-oeRbfT-I=.5bc6a1e2-d99d-4784-9b41-d4722793c613@github.com>
Message-ID: <R5Z9dm4TLlM2Pgxg5_UDBgYL3IG83Ec6KGCQ3ei_qdw=.2ee65e24-aaec-4266-8378-5a109de4dbbc@github.com>

On Tue, 15 Nov 2022 19:41:25 GMT, Vladimir Ivanov <vlivanov 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 25 commits:
>> 
>>  - Vladimir's review comments
>>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>>  - 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
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/7357a1a3...8f5942d9
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 896:
> 
>> 894: 
>> 895:   // Cleanup
>> 896:   __ vpxorq(xmm0, xmm0, xmm0, Assembler::AVX_512bit);
> 
> What's the purpose of the cleanup?

The internal security review asked me to blank out all the key material after I am done. i.e. R (and its powers on the stack)

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

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

From xuelei.f at gmail.com  Wed Nov 16 01:20:43 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Tue, 15 Nov 2022 17:20:43 -0800
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
 <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
Message-ID: <CAPJ=zzjJ4R-awP7RFJhXEJnY0NHM1sjk6bSr_gEW-Tgzyz6o2Q@mail.gmail.com>

> The wording in this PR specifically refers to the protocol version that
was specified. It isn't covering other optional protocols that may be
supported.

Sorry, I may not make it clear.  The protocol specified in
SSLContext.getInstance is not TLS protocol version.  I think the protocol
disabled in security properties refers to protocol version.  The new added
specification in this PR would better avoid the confusing.  If you want the
specified protocol referring to TLS version, the handshake may still
success even the TLS version is disabled. If you means the specified
protocol as SSLContext algorithm, I am not sure if the current security
properties supporting disabling of SSLContext algorithm.

Hope it helps!

Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221115/6698b475/attachment-0001.htm>

From wetmore at openjdk.org  Wed Nov 16 02:09:01 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 16 Nov 2022 02:09:01 GMT
Subject: RFR: 8297074: Use enhanced-for cycle instead of Enumeration in
 javax.crypto
In-Reply-To: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
References: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
Message-ID: <ajoBIo63ZKmaR4rb6wyWELT-xTPV9B5iUXN0Jgb3aN8=.2f3b9dcb-8081-4ce8-9e5f-333813f34adc@github.com>

On Mon, 7 Nov 2022 16:54:32 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.

Since you're down in the code anyway, you might take care of these minor nits as well.

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 232:

> 230:         // find out if there is anything we should add into
> 231:         // ret.
> 232:         Enumeration<String> thisKeys = this.perms.keys();

There are a couple other places where you could do the same enhanced for loop with arrays:  Current lines: 107, 254, 287.

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

Marked as reviewed by wetmore (Reviewer).

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

From xuelei at openjdk.org  Wed Nov 16 03:06:57 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 03:06:57 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
Message-ID: <mA-_UuDQMPa1lG0YRfGSrYHS5omjxwydQi6qcW4Vfwk=.8d4e6597-bf3f-4af9-8f93-63ed5faee83a@github.com>

On Tue, 15 Nov 2022 18:37:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking. Here are some cases I'm aware of:
> > 
> > 1. the protocol is disabled with Security property
> > 2. the protocol is not set while setting the SSLParameters
> > 3. the protocol is not set while set the enabled protocol
> > 4. the protocol is not supported by the peer
> > 5. the protocol is not supported by any cipher suites enabled.
> 
> Good point, but I feel that should be handled in a separate issue, if necessary. Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. 

I think it twice.  It may be not necessary to invoke additional methods subsequently by the application.  The impact could be configurations (security properties, key store, etc) other than `jdk.tls.disabledAlgorithms`.

> For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. 

If the purpose is to make sure an SSLContext instance work later, more options may be considered.  IMO, I did not see the value if we cannot make the description in a general  and accuracy way.  The "jdk.tls.disabledAlgorithms" is just one of many impacts.   All jdk.xxx.disabledAlgorithms properties could play a role to break the connection.  It may be not enough to check the  "jdk.tls.disabledAlgorithms" and than can make sure an SSLContext instance will work for sure.

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

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

From xuelei at openjdk.org  Wed Nov 16 03:26:56 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 03:26:56 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
 <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
Message-ID: <8QrsCBwCGMyThrsz89sQybEo0C4kZSPgmo7YB_OWjlE=.35a376a4-b625-4241-9c82-a646935af0d8@github.com>

On Tue, 15 Nov 2022 22:53:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > BTW, the protocol for SSLContext.getInstance() method is not a TLS protocol. It is more of a context-algorithm. For example, SSLContext.getInstance("TLSv1.3") could support TLS 1.0/1.1/1.2/1.3. It may be not usual, but if TLS 1.3 is disabled, and TLS 1.2 not, the connection should be able to established with TLS 1.2. In the description, it would be nice to make it clean what the 'protocol" means in different circumstances.
> 
> Yes, it might be useful to add something like "The returned SSLContext implements the specified protocol version, and may also implement other protocol versions." But I think it could be covered in a separate issue.
> 

I was not meant to add this kind of description.  I meant that the "specified protocol" in the description is not a TLS protocol version, and hence it could not be referred as TLS protocol version.

> The wording in this PR specifically refers to the protocol version that was specified. It isn't covering other optional protocols that may be supported.

I may be wrong.  But let me check.  For example, the code looks like:
`    SSLContext context = SSLContext.getInstance("TLSv1.3");
`
 
Per "The wording in this PR specifically refers to the protocol version that was specified", I guess "the protocol version that was specified" is "TLSv1.3".  And for code like `SSLContext context = SSLContext.getInstance("TLSv1.2");` I guess the "the protocol version that was specified" is "TLSv1.2".


If the property looks like `jdk.tls.disabledAlgorithms=TLSv1.3`, the `"TLSv1.3"` specified in the security property is not the one specified in `SSLContext.getInstance("TLSv1.3");`. They are two different concepts.  The one in `SSLContext.getInstance("TLSv1.3");` refers to SSLContext protocol, while the one  in `jdk.tls.disabledAlgorithms=TLSv1.3` refers to TLS versions.

However, in the following description:

     * ... However, if the specified provider is "SunJSSE",
     * subsequent operations that attempt to use the specified protocol will
     * fail with an {@code SSLHandshakeException}."

if "the specified protocol" is referring to TLS version, it is not correct. 

If I get it right, the context in the example above can be used to establish connections for TLS 1.0/1.1/1.2.  The description in the PR , "will fail with ...", may be not true.

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

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

From weijun at openjdk.org  Wed Nov 16 03:41:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 03:41:11 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v4]
In-Reply-To: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
Message-ID: <WqcL9a7l_wHN7vc8Z4GrXmQOkI7sgauchtoYtPXIgkw=.2004e322-6cbb-4742-ba4c-7f3a1e3780c6@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:

  comment and exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11067/files
  - new: https://git.openjdk.org/jdk/pull/11067/files/619c6f44..c32d3e7d

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

  Stats: 7 lines in 2 files changed: 3 ins; 0 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  Wed Nov 16 03:41:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 03:41:12 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <mLZz482KWRRnNLRz2vE_T4FrRfamg0nYjPLy74GWa0Y=.26516b97-bd98-403f-b028-67294725db11@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
 <mLZz482KWRRnNLRz2vE_T4FrRfamg0nYjPLy74GWa0Y=.26516b97-bd98-403f-b028-67294725db11@github.com>
Message-ID: <GhP7nSx_LDA03AmyIN3y1eY1cpGse0Ox9V24T9zMcW4=.8f530615-48eb-4157-9d4e-06dcc80b2a4b@github.com>

On Tue, 15 Nov 2022 21:14:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   expected
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 65:
> 
>> 63:     // In all other case, algid is non null and params is null.
>> 64:     private final AlgorithmId algid;
>> 65:     private final AlgorithmParameters params;
> 
> Perhaps add a comment for this field since the others have comments.

These two fields share the same comment above them.

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

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

From benjamin.marwell at f-i.de  Wed Nov 16 07:23:20 2022
From: benjamin.marwell at f-i.de (benjamin.marwell at f-i.de)
Date: Wed, 16 Nov 2022 07:23:20 +0000
Subject: Undo deprecation of brainpool EC
In-Reply-To: <27e37532-be19-3ccd-8d8c-6a19c2b3dda2@oracle.com>
References: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>
 <27e37532-be19-3ccd-8d8c-6a19c2b3dda2@oracle.com>
Message-ID: <B1B4FF4B-6717-426D-B22E-02BAD36327CDf-i.de@s-web.de>

Hi Xuelei and Sean,

We use/see mostly brainpoolP512r1. But it is not just us! 

> , although I will note that the IANA registry
>    still lists them as not recommended for TLS [1].

I agree that brainpoolP512r1 are not particularly interesting when it comes to TLS,
but we still see server certificates (not the TLS algo) created with brainpoolP512r1, as well as keystores.
Not being able to connect due to certificate validation errors OR 
not being able to read a (somewhat) recently created keystore was astonishing, to say the least.

> And with
>    recently added support for EdDSA and the future with PQC, it's not
>    likely we will circle back to them.

This is not about which algorithm is "better" or "can be replaced".
It is only about "what should (still) be supported, because NIST and BSI still list them".

>     We are ok with a contribution,

In my opinion, this is a major breaking change for this reason and should not wait for contributions.

- Ben


?On 15.11.22, 15:35, "security-dev on behalf of Sean Mullan" <security-dev-retn at openjdk.org on behalf of sean.mullan at oracle.com> wrote:

    Hi,

    Thanks for your questions about brainpool. See below for more details.

    On 11/14/22 3:36 AM, benjamin.marwell at f-i.de wrote:
    > 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.

    The word "deprecated" may have been the wrong word to use when referring
    to the brainpool curves, although I will note that the IANA registry
    still lists them as not recommended for TLS [1].

    We don't have any issues with the brainpool curves as we do for
    some of the other legacy curves. But, these curves were implemented in
    native C code and we changed the structure of the JDK EC implementation
    such that all curves that were implemented in C were removed. The
    remaining curves that we do support are implemented in Java and use
    modern techniques and complete formulas.

    It has not been a priority for us to re-implement brainpool. And with
    recently added support for EdDSA and the future with PQC, it's not
    likely we will circle back to them.

    We are ok with a contribution, but they would need to be done using
    the current design structure and using complete formulas.

    --Sean

    [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

    > 
    > 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/20221116/d9cdab26/smime.p7s>

From duke at openjdk.org  Wed Nov 16 07:45:26 2022
From: duke at openjdk.org (pandaapo)
Date: Wed, 16 Nov 2022 07:45:26 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <0JwKXTVP7rKAH_q7PdO4cBxfzqh516EOlvdropX57-M=.5247755b-5536-4695-b5f8-2d02639d9407@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <ZIyMVSrvrcJL7cCkfeYGEo1Ti0uc8r--9seOCzpSTos=.12290c69-ddac-4f2a-a572-9f02d815d679@github.com>
 <1SgjlQatBEnDkM7SKknVvONQZlTwxTM_1fQemk4-MbY=.14a019db-58c0-4dc8-af74-2b7d294c766c@github.com>
 <0JwKXTVP7rKAH_q7PdO4cBxfzqh516EOlvdropX57-M=.5247755b-5536-4695-b5f8-2d02639d9407@github.com>
Message-ID: <MJqr_ODfGGpEjNTTVpu6rGzSTHFTfjJJ1g48RK1ykFQ=.b36d14ed-0951-4081-aa9b-b6efafb326fa@github.com>

On Mon, 14 Nov 2022 18:41:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Yes. I believe the `setEagerValidation` method can also be removed and all code that calls it.

OK, I will remove it and all methods that calls it:
![jdk issue 8296734](https://user-images.githubusercontent.com/35672972/202113084-e7308680-bb15-4b2e-b8ba-514054e42620.png) .

Because `JarVerifier#setEagerValidation` will be removed, the field `eagerValidation` will always be false.

There are some codes using this field:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/JarVerifier.java#L361-L381
Can I remove the `eagerValidation` condition from `if(eagerValidation && sigFileSigners.get(name) != null)`?
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/JarFile.java#L1229-L1247
Can I remove the `if (jv.eagerValidation) {}` code block?

Can I remove this field from `JarVerifier`?

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

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

From aturbanov at openjdk.org  Wed Nov 16 08:10:57 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Nov 2022 08:10:57 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v2]
In-Reply-To: <fIg-QICI6Po-fdH3b3o6KkZW_OgwvnFtx7IBb7E-rQw=.c3e79f1d-e6ff-4d1f-8914-15ba9fa8de36@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
 <fIg-QICI6Po-fdH3b3o6KkZW_OgwvnFtx7IBb7E-rQw=.c3e79f1d-e6ff-4d1f-8914-15ba9fa8de36@github.com>
Message-ID: <b4214iaPzZ_tPPPPMvGrtYyxK9C837kymgRQUNj1wj8=.952fcd39-5882-4ec5-8fd8-ec1497059924@github.com>

On Tue, 15 Nov 2022 02:50:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
>> 
>> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a method called by test

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

> 1322:         throws CertificateParsingException {
> 1323:         // return cached value if we can
> 1324:         if (subjectAlternativeNames != null)  {

Suggestion:

        if (subjectAlternativeNames != null) {

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

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

From weijun at openjdk.org  Wed Nov 16 13:19:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 13:19:12 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v2]
In-Reply-To: <b4214iaPzZ_tPPPPMvGrtYyxK9C837kymgRQUNj1wj8=.952fcd39-5882-4ec5-8fd8-ec1497059924@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
 <fIg-QICI6Po-fdH3b3o6KkZW_OgwvnFtx7IBb7E-rQw=.c3e79f1d-e6ff-4d1f-8914-15ba9fa8de36@github.com>
 <b4214iaPzZ_tPPPPMvGrtYyxK9C837kymgRQUNj1wj8=.952fcd39-5882-4ec5-8fd8-ec1497059924@github.com>
Message-ID: <5zQ90xe2uKdVro3OyqUmC8PBBVVni2oduvy7Yc_dYBo=.e90a32bc-0187-46ea-9b9e-6c59fb31beea@github.com>

On Wed, 16 Nov 2022 08:07:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a method called by test
>
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1324:
> 
>> 1322:         throws CertificateParsingException {
>> 1323:         // return cached value if we can
>> 1324:         if (subjectAlternativeNames != null)  {
> 
> Suggestion:
> 
>         if (subjectAlternativeNames != null) {

Didn't notice that. Will fix. Thanks.

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

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

From weijun at openjdk.org  Wed Nov 16 13:21:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 13:21:49 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v3]
In-Reply-To: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
Message-ID: <m3iytCck8_0wVvjqOy8oLGGfLk7-is0RbcPlB_5MDTo=.78124cd2-ce48-44c5-9951-d599aaa895e3@github.com>

> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
> 
> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.

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

  one extra space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11151/files
  - new: https://git.openjdk.org/jdk/pull/11151/files/3d031083..056daf5c

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

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

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

From mullan at openjdk.org  Wed Nov 16 14:25:57 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 14:25:57 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v4]
In-Reply-To: <WqcL9a7l_wHN7vc8Z4GrXmQOkI7sgauchtoYtPXIgkw=.2004e322-6cbb-4742-ba4c-7f3a1e3780c6@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <WqcL9a7l_wHN7vc8Z4GrXmQOkI7sgauchtoYtPXIgkw=.2004e322-6cbb-4742-ba4c-7f3a1e3780c6@github.com>
Message-ID: <wNOzNgSxbbqIH4wTmUkTyJXxy4LNYLta4pfT6ULZqwA=.3fc6d34e-f37a-4c13-82bf-fefded50e424@github.com>

On Wed, 16 Nov 2022 03:41:11 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:
> 
>   comment and exception message

Did you consider changing `EncryptedPrivateKeyInfo(...,AlgorithmParameters)` to throw `IllegalStateException` if the parameters were not initialized? I know you said you were worried about changing the API, but it would be a cleaner option. I wonder if there is really any code that is initializing the parameters after creating the EPKI.

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 103:

> 101:      * @param oid the identifier for the algorithm.
> 102:      * @param algparams the associated algorithm parameters, can be null.
> 103:      * @exception IllegalStateException if algparams is not initialized

add "or cannot be decoded"

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 493:

> 491:      * @param algparams the associated algorithm parameters.
> 492:      * @exception NoSuchAlgorithmException on error.
> 493:      * @exception IllegalStateException if algparams is not initialized

Add "or cannot be decoded"

test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetAlgName.java line 64:

> 62:             }
> 63: 
> 64:             AlgorithmParameters ap2 = AlgorithmParameters.getInstance(ap.getAlgorithm());

It would be useful to add a comment here that you are testing that an EPKI can be created with an uninitialized AP.

test/jdk/sun/security/x509/AlgorithmId/Uninitialized.java line 35:

> 33: import java.security.AlgorithmParameters;
> 34: 
> 35: public class Uninitialized {

Is this test necessary? It seems to be duplicating the additional test you added to GetAlgName.java

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

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

From mullan at openjdk.org  Wed Nov 16 14:25:59 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 14:25:59 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v3]
In-Reply-To: <GhP7nSx_LDA03AmyIN3y1eY1cpGse0Ox9V24T9zMcW4=.8f530615-48eb-4157-9d4e-06dcc80b2a4b@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
 <mLZz482KWRRnNLRz2vE_T4FrRfamg0nYjPLy74GWa0Y=.26516b97-bd98-403f-b028-67294725db11@github.com>
 <GhP7nSx_LDA03AmyIN3y1eY1cpGse0Ox9V24T9zMcW4=.8f530615-48eb-4157-9d4e-06dcc80b2a4b@github.com>
Message-ID: <ttyiLgfQJ7BNwQ5b0lYw6j9bvM9xnhGc4JGa0PvtlnE=.6414f82f-4197-4bc9-978a-f0e02a94c2d8@github.com>

On Tue, 15 Nov 2022 22:02:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 65:
>> 
>>> 63:     // In all other case, algid is non null and params is null.
>>> 64:     private final AlgorithmId algid;
>>> 65:     private final AlgorithmParameters params;
>> 
>> Perhaps add a comment for this field since the others have comments.
>
> These two fields share the same comment above them.

Ah, I see. Ok.

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

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

From mullan at openjdk.org  Wed Nov 16 14:26:02 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 14:26:02 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v4]
In-Reply-To: <YX1nqE3C7ZPVyDAdjp4-xmDLmTcGxmVQdth9gcK1m_Q=.0e3b6fd9-5db7-4c63-bd68-6abf95191122@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALAnduie629jZyKfkbmaD6tbA0GfvNGdPm0R5f38EiU=.1fc76ef4-f92f-4594-8d3b-59eda6053d51@github.com>
 <mLZz482KWRRnNLRz2vE_T4FrRfamg0nYjPLy74GWa0Y=.26516b97-bd98-403f-b028-67294725db11@github.com>
 <YX1nqE3C7ZPVyDAdjp4-xmDLmTcGxmVQdth9gcK1m_Q=.0e3b6fd9-5db7-4c63-bd68-6abf95191122@github.com>
Message-ID: <3n3vHGGVZ2U-ZHFzbYgBAfVtIz52upf-mspZX4wtEi4=.73ad013f-4c7a-41cf-b7b2-b790e7a515d2@github.com>

On Tue, 15 Nov 2022 21:51:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 119:
>> 
>>> 117:     }
>>> 118: 
>>> 119:     MacData(AlgorithmParameters algParams, byte[] digest,
>> 
>> Is this related to this issue in some way or just a ctor that is not used?
>
> The constructor is not used anywhere, and it has an `AlgorithmParameters ` argument that could also be uninitialized.

Good to see it removed then.

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

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

From mullan at openjdk.org  Wed Nov 16 14:26:05 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 14:26:05 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v4]
In-Reply-To: <2iQ6KeJVGxMH9HD1ovaH86gKEnEHMns4LOtFJomGML8=.6c6caf9b-07f1-4589-aee1-8d88d8e8ce6c@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <aQ4FXH8N6f3_bD9JEkQ3cUpiP7mLS2gbjX2kwwc7QRs=.6778892a-a670-4664-b9f8-660531b42f66@github.com>
 <2iQ6KeJVGxMH9HD1ovaH86gKEnEHMns4LOtFJomGML8=.6c6caf9b-07f1-4589-aee1-8d88d8e8ce6c@github.com>
Message-ID: <VpM9pYvsA7frwUyIc7eQxpaAJoAu5qiTyOMJiUAsaw4=.c6bb615f-33af-4693-8d2e-f9cdc1eec7b6@github.com>

On Thu, 10 Nov 2022 14:51:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

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

Nit on line 168, remove space before "(".

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

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

From jnimeh at openjdk.org  Wed Nov 16 14:45:03 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 16 Nov 2022 14:45:03 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: <RgX5yTd-zwfUyUpMnYhlkV-9sl0-ruKVynqlRjThPH8=.556b380d-6271-44d2-8f20-e4eb6cf426a9@github.com>

On Fri, 21 Oct 2022 12:29:22 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
>> 
>> 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.
>
> Please my friend, let's get this finished or I'm going to have to do it myself.

Hi @theRealAph, since I have the green light on the x86 side I was wondering if I could get your blessing on the aarch64 side of the house or if you have any other concerns.

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

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

From duke at openjdk.org  Wed Nov 16 16:21:55 2022
From: duke at openjdk.org (James Baker)
Date: Wed, 16 Nov 2022 16:21:55 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <YRx8_op_CPaI_ngmFQDzNLdywQHmeS63IWIZC4WT56U=.ca69bdd8-d6f8-42ff-a129-6330cabec687@github.com>

On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

It's possibly worth noting that while this is merely fixing a regression for x86, it's very likely a decent sized performance improvement on arm64, where intrinsics for AES-GCM (depending on JVM vendor) aren't added until after Java 17.

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

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

From mullan at openjdk.org  Wed Nov 16 16:34:08 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 16:34:08 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> > The wording in this PR specifically refers to the protocol version that
> 
> was specified. It isn't covering other optional protocols that may be supported.
> 
> Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version. 

Where in the javadoc APIs does it say that? I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.

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

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

From duke at openjdk.org  Wed Nov 16 16:36:56 2022
From: duke at openjdk.org (Carter Kozak)
Date: Wed, 16 Nov 2022 16:36:56 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <LbJIUYo2qMxWxuFNbbq524_rjCX2VrCjLgChdn2kb7A=.42694bbd-85e3-45f2-81b4-92b44a222f33@github.com>

On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Thanks for looking into this, @ascarpino!

In testing this using a local build, it improves performance in cases using heap buffers (a super-set of the socket case), however servers which use direct byte-buffers still exhibit a similar performance regression (heavy allocation compared to jdk17, ~10% slower TLS performance in HTTP+TLS benchmarks). It's possible that has a different root cause, but the outcome is strikingly similar.

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

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

From duke at openjdk.org  Wed Nov 16 16:48:16 2022
From: duke at openjdk.org (James Baker)
Date: Wed, 16 Nov 2022 16:48:16 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <R7Mgtzeo32hf0T21FtKLI-Xc2UvvXz6PWbzhzLEtJ4M=.6aa08ff8-1e74-4133-a602-f260c76331d0@github.com>

On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Carter, when I looked at this a few months back (admittedly I'm a fairly careless profiler and didn't fully dig down to a root cause) I felt as though direct bytebuffers were possibly getting compromised round about here: https://github.com/openjdk/jdk/blob/3416bfa2560e240b5e602f10e98e8a06c96852df/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java#L722, where... essentially it's easier for intrinsics to operate on byte arrays and so any direct data passed in gets copied into a new byte array which is then passed into the intrinsic.

It's possible that I'm misunderstanding, however. I think one could test this hypothesis by adjusting the size of PARALLEL_LEN. Halving it will lead to a less efficient intrinsic usage but correspondingly halve the allocation rate.

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

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

From xuelei at openjdk.org  Wed Nov 16 17:42:05 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 17:42:05 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>
Message-ID: <tE-XCaAOq7dpJa0np6pcDQJyTD9hSPPWQ7JEYDY9gPw=.14f640d7-aa20-4ee4-bb5e-e17c3aa582a0@github.com>

On Wed, 16 Nov 2022 16:31:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> > > The wording in this PR specifically refers to the protocol version that
> > 
> > 
> > was specified. It isn't covering other optional protocols that may be supported.
> > Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version.
> 
> Where in the javadoc APIs does it say that?

The Javadoc APIs specification does not say it is referring to TLS protocol version.  In the standard algorithm documentation, the word "SSLContext Algorithms" is used and here is an example:


Algorithm Name | Description
-- | --
TLSv1.2 | Supports?RFC 5246: TLS version 1.2; may support other SSL/TLS versions


> I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.

Yes.  So we cannot assume that the literal SSLContext algorithm is the only supported TLS version for an JSSE provider, including the SunJSSE provider.

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

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

From xuelei at openjdk.org  Wed Nov 16 17:46:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 17:46:19 GMT
Subject: Integrated: 8296818: Enhance JMH tests java/security/Signatures.java
In-Reply-To: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
References: <zEPiLngBv_18oGRdiapVxxUuHR4wUd5ez2LspUcslkk=.b8a4966a-d40e-4cda-86ed-fbaa8558cd40@github.com>
Message-ID: <Sd3CQe48vzAFvtV4XjWw1KNV_R-ukEil8THFKhzLRGw=.5763ab19-ff47-466f-8cb9-e0d5090eecde@github.com>

On Mon, 14 Nov 2022 05:11:33 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: 8752bb4b
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8752bb4be8ff71b57ddc262fde73fb3102a1a179
Stats:     147 lines in 1 file changed: 115 ins; 16 del; 16 mod

8296818: Enhance JMH tests java/security/Signatures.java

Reviewed-by: weijun

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

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

From xuelei at openjdk.org  Wed Nov 16 17:48:40 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 17:48:40 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to KeyPairGeneratorBench.java
Message-ID: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>

Hi,

May I have this update reviewed?

In the current key pair generation micro-benchmark, there is no cases for `EdDSA`, `XDH`, and `RSASSA-PSS`.  This PR is trying to add these algorithms.

BTW, here is the benchmarking data on a Linux x86_64 platform.  You can see how much the performance difference could be among key pair generation algorithms.


Benchmark                                                         (algorithm)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          256              thrpt   40  1647.342 ?  8.548  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          384              thrpt   40   698.990 ?  5.647  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          521              thrpt   40   364.970 ?  5.556  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          255              thrpt   40  2400.202 ? 17.685  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          448              thrpt   40   680.304 ?  5.923  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         1024              thrpt   40    69.614 ?  1.907  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         2048              thrpt   40     9.192 ?  0.567  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         3072              thrpt   40     2.352 ?  0.385  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         4096              thrpt   40     0.815 ?  0.221  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         1024              thrpt   40    70.022 ?  2.336  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         2048              thrpt   40     9.260 ?  0.730  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         3072              thrpt   40     2.305 ?  0.369  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         4096              thrpt   40     0.902 ?  0.194  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          255              thrpt   40  5061.279 ? 33.878  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          448              thrpt   40  1404.786 ? 11.083  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         1024              thrpt   40  9486.010 ? 20.242  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         2048              thrpt   40  2174.506 ?  2.514  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         1024              thrpt   40  3532.067 ?  7.882  ops/s
o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         2048              thrpt   40   523.746 ?  0.704  ops/s
o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     DSA         2048              thrpt   40  2171.807 ?  3.505  ops/s
o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     RSA         2048              thrpt   40     9.549 ?  0.809  ops/s



Thanks,
Xuelei

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

Commit messages:
 - 8296910: Add EdDSA/XDH/RSASSA-PSS to KeyPairGeneratorBench.java

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

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

From mpowers at openjdk.org  Wed Nov 16 17:52:18 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 16 Nov 2022 17:52:18 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>

On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 580:

> 578:      * an upper limit on the number of blocks encrypted in the intrinsic.
> 579:      *
> 580:      * For decrypting in-place byte[], calling methods must ct must set to null

end of sentence mangled

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 592:

> 590: 
> 591:         int len = 0;
> 592:         // Loop if input length is greater than the SPLIT_LEN

comment doesn't add anything not already obvious from the code

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 596:

> 594:             int partlen;
> 595:             while (inLen >= SPLIT_LEN) {
> 596:                 partlen = implGCMCrypt0(in, inOfs + len, SPLIT_LEN, ct,

why not `int partlen` and get rid of line 594

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 603:

> 601:         }
> 602: 
> 603:         // Finish any remaining data

comment doesn't add anything special

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 694:

> 692:         int originalOutOfs = 0;
> 693: 
> 694:         // True if op is in-place array decryption with the input & output

// Setting `inPlaceArray` to true turns off combined intrinsic processing.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 764:

> 762:                 byte[] array;
> 763:                 if (encryption) {
> 764:                     array = dst.array();

You could factor out lines 764 and 770 by changing line 762 to
`byte[] array = encryption ? dst.array() : src.array();`

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1644:

> 1642:                 // Clear output data
> 1643:                 dst.reset();
> 1644:                 // If this is an in-place array, don't zero the src

The comment doesn't jive with the line of code on the next line. It is the inverse of the comment.

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

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

From weijun at openjdk.org  Wed Nov 16 18:16:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 18:16:10 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v4]
In-Reply-To: <wNOzNgSxbbqIH4wTmUkTyJXxy4LNYLta4pfT6ULZqwA=.3fc6d34e-f37a-4c13-82bf-fefded50e424@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <WqcL9a7l_wHN7vc8Z4GrXmQOkI7sgauchtoYtPXIgkw=.2004e322-6cbb-4742-ba4c-7f3a1e3780c6@github.com>
 <wNOzNgSxbbqIH4wTmUkTyJXxy4LNYLta4pfT6ULZqwA=.3fc6d34e-f37a-4c13-82bf-fefded50e424@github.com>
Message-ID: <HKB1JpHFWKqjuYfI_k118HsvsyTSiiQ5rqLq4r3rOqM=.432a88db-aea7-4f01-93e0-81c3636fe5b2@github.com>

On Wed, 16 Nov 2022 14:12:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment and exception message
>
> test/jdk/sun/security/x509/AlgorithmId/Uninitialized.java line 35:
> 
>> 33: import java.security.AlgorithmParameters;
>> 34: 
>> 35: public class Uninitialized {
> 
> Is this test necessary? It seems to be duplicating the additional test you added to GetAlgName.java

It is necessary, `GetAlgName.java` is about `EncryptedPrivateKeyInfo` accepting uninitialized AP, but this test is about `AlgorithmId` NOT accepting one.

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

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

From ascarpino at openjdk.org  Wed Nov 16 18:22:16 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 16 Nov 2022 18:22:16 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <YRx8_op_CPaI_ngmFQDzNLdywQHmeS63IWIZC4WT56U=.ca69bdd8-d6f8-42ff-a129-6330cabec687@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <YRx8_op_CPaI_ngmFQDzNLdywQHmeS63IWIZC4WT56U=.ca69bdd8-d6f8-42ff-a129-6330cabec687@github.com>
Message-ID: <3344a55Z7_vytPlf9K9GOHXJVPOZr1Yrf0LTGs3ZhL4=.4ba8d840-6c92-4caf-9892-efe2499455cd@github.com>

On Wed, 16 Nov 2022 16:18:15 GMT, James Baker <duke at openjdk.org> wrote:

> It's possibly worth noting that while this is merely fixing a regression for x86, it's very likely a decent sized performance improvement on arm64, where intrinsics for AES-GCM (depending on JVM vendor) aren't added until after Java 17.

That is why it refers to "combined intrinsic" more than spelling out AVX512.  The change affects all platforms

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

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

From weijun at openjdk.org  Wed Nov 16 18:47:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 18:47:27 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v5]
In-Reply-To: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
Message-ID: <ALg-Iv91VhSEWnDLHrq6aoy65WXUnXr_jFIuJuSgy5A=.8aad25ad-3925-402e-b9db-cee3f1227482@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 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:

 - more comments
 - Merge branch 'master' into 8296442
 - comment and exception message
 - expected
 - address xuelei's comments
 - the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11067/files
  - new: https://git.openjdk.org/jdk/pull/11067/files/c32d3e7d..8f04b8a3

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

  Stats: 6593 lines in 389 files changed: 3724 ins; 1629 del; 1240 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 16 18:47:29 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 18:47:29 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v4]
In-Reply-To: <wNOzNgSxbbqIH4wTmUkTyJXxy4LNYLta4pfT6ULZqwA=.3fc6d34e-f37a-4c13-82bf-fefded50e424@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <WqcL9a7l_wHN7vc8Z4GrXmQOkI7sgauchtoYtPXIgkw=.2004e322-6cbb-4742-ba4c-7f3a1e3780c6@github.com>
 <wNOzNgSxbbqIH4wTmUkTyJXxy4LNYLta4pfT6ULZqwA=.3fc6d34e-f37a-4c13-82bf-fefded50e424@github.com>
Message-ID: <1wOwVXOPPZCyfVnoRXnNwRxroVBXDElksRDXNGA7Q68=.ac11de10-a026-4f0e-997f-c28f8b91def4@github.com>

On Wed, 16 Nov 2022 14:21:48 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Did you consider changing EncryptedPrivateKeyInfo(...,AlgorithmParameters) to throw IllegalStateException if the parameters were not initialized? I know you said you were worried about changing the API, but it would be a cleaner option. I wonder if there is really any code that is initializing the parameters after creating the EPKI.

I thought about that. The change would break some existing tests and need a spec change. I don't think it's worth doing.

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

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

From ascarpino at openjdk.org  Wed Nov 16 18:53:57 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 16 Nov 2022 18:53:57 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <3344a55Z7_vytPlf9K9GOHXJVPOZr1Yrf0LTGs3ZhL4=.4ba8d840-6c92-4caf-9892-efe2499455cd@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <YRx8_op_CPaI_ngmFQDzNLdywQHmeS63IWIZC4WT56U=.ca69bdd8-d6f8-42ff-a129-6330cabec687@github.com>
 <3344a55Z7_vytPlf9K9GOHXJVPOZr1Yrf0LTGs3ZhL4=.4ba8d840-6c92-4caf-9892-efe2499455cd@github.com>
Message-ID: <wb_xytmFE1ahFThXnCv2aZ1sk2I9d8wkAanG6YXx3hQ=.4dc90457-21be-43d8-8353-92224cd20999@github.com>

On Wed, 16 Nov 2022 18:19:30 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> It's possibly worth noting that while this is merely fixing a regression for x86, it's very likely a decent sized performance improvement on arm64, where intrinsics for AES-GCM (depending on JVM vendor) aren't added until after Java 17.
>
>> It's possibly worth noting that while this is merely fixing a regression for x86, it's very likely a decent sized performance improvement on arm64, where intrinsics for AES-GCM (depending on JVM vendor) aren't added until after Java 17.
> 
> That is why it refers to "combined intrinsic" more than spelling out AVX512.  The change affects all platforms

> Thanks for looking into this, @ascarpino!
> 
> In testing this using a local build, it improves performance in cases using heap buffers (a super-set of the socket case), however servers which use direct byte-buffers still exhibit a similar performance regression (heavy allocation compared to jdk17, ~10% slower TLS performance in HTTP+TLS benchmarks). It's possible that has a different root cause, but the outcome is strikingly similar.

Well the provided test ran with heap bytebuffers and direct bytebuffers are handled differently because it has to copy data for the intrinsic.  But that data allocation is pretty low and I believe was the same in 17.  So I'm not aware of a direct bytebuffer slowdown as you now report

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

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

From ascarpino at openjdk.org  Wed Nov 16 18:53:58 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 16 Nov 2022 18:53:58 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
Message-ID: <3BkY-0oqHZbqeoBErFPJkhXP15cX9DqzXxvAb4gL6yo=.ac784ffc-3c08-4743-830d-66920ea1a594@github.com>

On Wed, 16 Nov 2022 17:00:37 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 596:
> 
>> 594:             int partlen;
>> 595:             while (inLen >= SPLIT_LEN) {
>> 596:                 partlen = implGCMCrypt0(in, inOfs + len, SPLIT_LEN, ct,
> 
> why not `int partlen` and get rid of line 594

can reuse the same partlen for all loops through the while

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

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

From mullan at openjdk.org  Wed Nov 16 19:44:03 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 19:44:03 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v4]
In-Reply-To: <HKB1JpHFWKqjuYfI_k118HsvsyTSiiQ5rqLq4r3rOqM=.432a88db-aea7-4f01-93e0-81c3636fe5b2@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <WqcL9a7l_wHN7vc8Z4GrXmQOkI7sgauchtoYtPXIgkw=.2004e322-6cbb-4742-ba4c-7f3a1e3780c6@github.com>
 <wNOzNgSxbbqIH4wTmUkTyJXxy4LNYLta4pfT6ULZqwA=.3fc6d34e-f37a-4c13-82bf-fefded50e424@github.com>
 <HKB1JpHFWKqjuYfI_k118HsvsyTSiiQ5rqLq4r3rOqM=.432a88db-aea7-4f01-93e0-81c3636fe5b2@github.com>
Message-ID: <I-wDL7i3UqSM5dmNNCTyy5b-GuBz3Zug3IVRwsetmng=.8da37d65-8e03-4a14-b101-9d52967974ca@github.com>

On Wed, 16 Nov 2022 18:12:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/x509/AlgorithmId/Uninitialized.java line 35:
>> 
>>> 33: import java.security.AlgorithmParameters;
>>> 34: 
>>> 35: public class Uninitialized {
>> 
>> Is this test necessary? It seems to be duplicating the additional test you added to GetAlgName.java
>
> It is necessary, `GetAlgName.java` is about `EncryptedPrivateKeyInfo` accepting uninitialized AP, but this test is about `AlgorithmId` NOT accepting one.

Right. Ok.

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

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

From mullan at openjdk.org  Wed Nov 16 20:30:14 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 20:30:14 GMT
Subject: RFR: 8296442: EncryptedPrivateKeyInfo can be created with an
 uninitialized AlgorithmParameters [v5]
In-Reply-To: <ALg-Iv91VhSEWnDLHrq6aoy65WXUnXr_jFIuJuSgy5A=.8aad25ad-3925-402e-b9db-cee3f1227482@github.com>
References: <lmHry2CcSTth0cK0BUWfR5eEUZ60poKIythWtTempI0=.c179ff7b-5421-487e-b1ef-090a857e02ef@github.com>
 <ALg-Iv91VhSEWnDLHrq6aoy65WXUnXr_jFIuJuSgy5A=.8aad25ad-3925-402e-b9db-cee3f1227482@github.com>
Message-ID: <3Rmkia6Fn5kTQ8L55GKPfnbm-alqotzlP28h1lrBnng=.fae65cd5-633a-413c-8ee2-b8bfd520f9fa@github.com>

On Wed, 16 Nov 2022 18:47:27 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 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:
> 
>  - more comments
>  - Merge branch 'master' into 8296442
>  - comment and exception message
>  - expected
>  - address xuelei's comments
>  - the fix

Marked as reviewed by mullan (Reviewer).

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

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

From weijun at openjdk.org  Wed Nov 16 20:33:56 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 20:33:56 GMT
Subject: Integrated: 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: <8uocbmggqlDGMp-WOd7gZh4gn63pk6upOt9DXCSTDVs=.8fe11e70-7a54-4943-b9dd-b40fae06d356@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.

This pull request has now been integrated.

Changeset: 68d3ed5c
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68d3ed5ceec38505b934d79f288eb78d09fb3cc4
Stats:     174 lines in 6 files changed: 102 ins; 46 del; 26 mod

8296442: EncryptedPrivateKeyInfo can be created with an uninitialized AlgorithmParameters

Reviewed-by: xuelei, kdriver, mullan

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

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

From weijun at openjdk.org  Wed Nov 16 20:51:43 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 20:51:43 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
Message-ID: <yPCJrDRgPFsFfXKPgnh7EgpXUEtU6KFOM-f36ucqVVU=.f7aaef88-d274-43db-aa8c-64a924be344b@github.com>

On Sun, 13 Nov 2022 19:58:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> In the current key pair generation micro-benchmark, there is no cases for `EdDSA`, `XDH`, and `RSASSA-PSS`.  This PR is trying to add these algorithms.
> 
> BTW, here is the benchmarking data on a Linux x86_64 platform.  You can see how much the performance difference could be among key pair generation algorithms.
> 
> 
> Benchmark                                                         (algorithm)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          256              thrpt   40  1647.342 ?  8.548  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          384              thrpt   40   698.990 ?  5.647  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          521              thrpt   40   364.970 ?  5.556  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          255              thrpt   40  2400.202 ? 17.685  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          448              thrpt   40   680.304 ?  5.923  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         1024              thrpt   40    69.614 ?  1.907  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         2048              thrpt   40     9.192 ?  0.567  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         3072              thrpt   40     2.352 ?  0.385  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         4096              thrpt   40     0.815 ?  0.221  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         1024              thrpt   40    70.022 ?  2.336  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         2048              thrpt   40     9.260 ?  0.730  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         3072              thrpt   40     2.305 ?  0.369  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         4096              thrpt   40     0.902 ?  0.194  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          255              thrpt   40  5061.279 ? 33.878  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          448              thrpt   40  1404.786 ? 11.083  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         1024              thrpt   40  9486.010 ? 20.242  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         2048              thrpt   40  2174.506 ?  2.514  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         1024              thrpt   40  3532.067 ?  7.882  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         2048              thrpt   40   523.746 ?  0.704  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     DSA         2048              thrpt   40  2171.807 ?  3.505  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     RSA         2048              thrpt   40     9.549 ?  0.809  ops/s
> 
> 
> 
> Thanks,
> Xuelei

The generation might depend on secure randoms a lot. How about create a simple `SecureRandom` that is fast and does not depend on any external entropy source?

Maybe you can do the same with the signature benchmark as well. Unfortunately it has already been integrated.

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

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

From duke at openjdk.org  Wed Nov 16 20:52:14 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 20:52:14 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@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:

  redo register alloc with explicit func params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/cbf49380..dbdfd1dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=18-19

  Stats: 387 lines in 2 files changed: 83 ins; 51 del; 253 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 xuelei at openjdk.org  Wed Nov 16 21:01:11 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 21:01:11 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <yPCJrDRgPFsFfXKPgnh7EgpXUEtU6KFOM-f36ucqVVU=.f7aaef88-d274-43db-aa8c-64a924be344b@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
 <yPCJrDRgPFsFfXKPgnh7EgpXUEtU6KFOM-f36ucqVVU=.f7aaef88-d274-43db-aa8c-64a924be344b@github.com>
Message-ID: <8b_KdNpM0FtpceAws-r7OsTWe1O5yPQWEDJHw8BT5Ww=.0f5f0f37-75b6-4672-a95e-ef873b10ddbf@github.com>

On Wed, 16 Nov 2022 20:46:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The generation might depend on secure randoms a lot. How about create a simple `SecureRandom` that is fast and does not depend on any external entropy source?

The secure random generation is part of the key generation.  It may be not the purpose to benchmark algorithms without secure randoms.  It may be helpful to see the math part of algorithms except random number.  What do you think to have the improvement in a different benchmark later?

> Maybe you can do the same with the signature benchmark as well. Unfortunately it has already been integrated.

What do you mean with "the same"?  secure random?

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

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

From weijun at openjdk.org  Wed Nov 16 21:01:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 21:01:12 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <8b_KdNpM0FtpceAws-r7OsTWe1O5yPQWEDJHw8BT5Ww=.0f5f0f37-75b6-4672-a95e-ef873b10ddbf@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
 <yPCJrDRgPFsFfXKPgnh7EgpXUEtU6KFOM-f36ucqVVU=.f7aaef88-d274-43db-aa8c-64a924be344b@github.com>
 <8b_KdNpM0FtpceAws-r7OsTWe1O5yPQWEDJHw8BT5Ww=.0f5f0f37-75b6-4672-a95e-ef873b10ddbf@github.com>
Message-ID: <cadvbaIktQorbAY_rMt6Yor3jHBQFZ_y3OpgXpnz69A=.bd0f9e9a-0a8e-4bff-8858-7697cbf0530f@github.com>

On Wed, 16 Nov 2022 20:57:23 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > Maybe you can do the same with the signature benchmark as well. Unfortunately it has already been integrated.
> 
> What do you mean with "the same"? secure random?

Yes, the secure random that can be provided in `initSign`.

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

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

From duke at openjdk.org  Wed Nov 16 21:02:48 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 21:02:48 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
Message-ID: <rXhkm1_ONxveP0dOC_L9yAf5WyuwUu8-r83-Yts7O1k=.e213bab0-3867-4f5b-8527-c25951d8cc24@github.com>

On Mon, 14 Nov 2022 16:37:41 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>
>
> 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>

Any ideas why it is not scaling linearly with number of threads? One would think that random numbers are the 'definition' of data-independent and should scale linearly with number of CPUs

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 93:

> 91: 
> 92:     // ThreadLocal instance or null if not available
> 93:     private static final ThreadLocal<RandomIO> INSTANCE = initIO(Variant.MIXED);

Should this be a new Variant instead? (i.e. keep the old behavior of the other enum values)

You would need to create a new nested class (perhaps only copy-and-modify the non-blocking one?)

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 204:

> 202:     // return whether the NativePRNG is available
> 203:     static boolean isAvailable() {
> 204:         return INSTANCE.get() != null;

I think this would be cleaner if it were `return INSTANCE() != null;`

i.e. replace the field with a getter. Existing variants return just the field, while thread-local calls `get()`.

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

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

From duke at openjdk.org  Wed Nov 16 21:12:26 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 21:12:26 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <QaZ2HofRpsSEDgL-WPjiOtuuk-WMZ7Hvfm7dgNb6OSo=.cd60e9e2-9470-488e-8889-6860b0d33d73@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <QaZ2HofRpsSEDgL-WPjiOtuuk-WMZ7Hvfm7dgNb6OSo=.cd60e9e2-9470-488e-8889-6860b0d33d73@github.com>
Message-ID: <EFPZsMWQisEevn72ArFgikPetEgcmTW9mAEYSJxTAp0=.b17fabc0-ca03-406e-b967-d979c481b368@github.com>

On Tue, 15 Nov 2022 19:30:23 GMT, Vladimir Ivanov <vlivanov 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 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
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 370:
> 
>> 368:   // Middle 44-bit limbs of new blocks
>> 369:   __ vpsrlq(L1, L0, 44, Assembler::AVX_512bit);
>> 370:   __ vpsllq(TMP2, TMP1, 20, Assembler::AVX_512bit);
> 
> Any particular reason to use `TMP2` here? Can you just update `TMP1` instead (w/ `vpsllq(TMP1, TMP1, 20, Assembler::AVX_512bit);`)?

Thanks for the catch. Removed TMP2. (Several refactors ago, `D[01]` and `L[0-2]` used the same registers, because I was running out.. likely forgot to cleanup after I removed 2/3 of the optimizations and re-did register allocation)

done

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

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

From duke at openjdk.org  Wed Nov 16 21:15:59 2022
From: duke at openjdk.org (Bernd)
Date: Wed, 16 Nov 2022 21:15:59 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
Message-ID: <RxsBP-mWC8riHZuE-42TOlyJGZAV4X8lWfzVbpKUG6s=.8c0d1cd1-9183-4709-9e3f-35137dcb10e3@github.com>

On Mon, 14 Nov 2022 16:37:41 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>
>
> 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>

Would it be easier to remove the state (singleton, thread local) caching completely? If somebody request a new instance just seed and return it. That might in some situations be even less seeding than once per thread and it decreases stat sharing even more.

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

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

From weijun at openjdk.org  Wed Nov 16 21:31:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Nov 2022 21:31:05 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <8b_KdNpM0FtpceAws-r7OsTWe1O5yPQWEDJHw8BT5Ww=.0f5f0f37-75b6-4672-a95e-ef873b10ddbf@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
 <yPCJrDRgPFsFfXKPgnh7EgpXUEtU6KFOM-f36ucqVVU=.f7aaef88-d274-43db-aa8c-64a924be344b@github.com>
 <8b_KdNpM0FtpceAws-r7OsTWe1O5yPQWEDJHw8BT5Ww=.0f5f0f37-75b6-4672-a95e-ef873b10ddbf@github.com>
Message-ID: <PyScw_P7fqTBmfoPMZsxKG0jg7OrYicDcXNap6JAwLI=.6d31bcd1-540e-4d9f-b48a-a7a91fea9b65@github.com>

On Wed, 16 Nov 2022 20:55:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > The generation might depend on secure randoms a lot. How about create a simple `SecureRandom` that is fast and does not depend on any external entropy source?
> 
> The secure random generation is part of the key generation. It may be not the purpose to benchmark algorithms without secure randoms. It may be helpful to see the math part of algorithms except random number. What do you think to have the improvement in a different benchmark later?

I was wondering if secure random generation could be sometimes fast and sometimes slow. I'm also not sure about how NativePRNG behaves in a multi-thread environment.

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

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

From duke at openjdk.org  Wed Nov 16 21:34:22 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 21:34:22 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <r_1O7IZ10L42qLo58Al4P7vopxNimqQf_JGXTozhSrQ=.02f7ac95-6ee2-409c-8730-649eae6835fe@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
 <i2KXAYD9RaayPF684xwQgBredelBO5O6oyO28aETB0E=.329c21c6-84cb-4354-849d-0fdf8ca19e59@github.com>
 <r_1O7IZ10L42qLo58Al4P7vopxNimqQf_JGXTozhSrQ=.02f7ac95-6ee2-409c-8730-649eae6835fe@github.com>
Message-ID: <62fFZ_M2aZHxrUV73RXbAVDUIGtpMOUFL4HdjqLqFJI=.392ad4b7-1917-49c6-b36b-178beee57102@github.com>

On Tue, 15 Nov 2022 19:38:56 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>>> On other hand, there are functions like poly1305_multiply8_avx512 and poly1305_process_blocks_avx512 that use a lot of temp registers. I think it makes sense to keep those as 'function-header declarations'.
>> 
>> I agree with you on `poly1305_process_blocks_avx512`, but `poly1305_multiply8_avx512` already takes 8 arguments. Putting 8 more arguments for temps doesn't look prohibitive. 
>> 
>>> I think it makes sense to keep those as 'function-header declarations'.
>> 
>> IMO it's not enough. Ideally, if there are any implicit usages, those should be clearly spelled out at every call site.
>
> Changed just the three `*limbs*` functions.

Lifted everything pretty much to just `poly1305_process_blocks_avx512` and `generate_poly1305_processBlocks` (i.e. two register maps)

Took some time to make it 'reasonable' again, but I think it makes sense. (But then, true test would be me looking a month later or if it makes sense to others)

Had to cleanup the names; 'local' names could all be play on `tmp`.. but the register reuse is much clearer from the 'global' names.

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

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

From duke at openjdk.org  Wed Nov 16 21:34:22 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 21:34:22 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v16]
In-Reply-To: <jOU2YrKbL5IN9drxis9yPT_AlliER47yfWT82oCm8_g=.92f9a11a-4f49-4897-974d-f77c5d4b6a21@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <QDsvvBP-whhXZ1wVWPPWspd_rbmy6QRmycHBhd0SRw8=.b709dd5e-2b99-4f88-a8af-0df9c7708235@github.com>
 <6oNkr_1EGAdRQqa7GDrsa-tIpV_kO-_HJAjdA8Mkf28=.34da74e0-c6f1-4eec-bc45-8c8dd02f68f0@github.com>
 <-JVYIHKOY_LuVTqyH5xuubtPdk8pK_wi5z-8pestRis=.e63938ab-0ac2-4880-8238-e6e6d8debf03@github.com>
 <OfSiSh0ho8oFGm5lOgCGxw84XjHzQHdXvyDOcZBQBXo=.f243574a-c6aa-47b2-8bb1-7951232bf83d@github.com>
 <9p2RTAI9FPWstQu0OtpSmSB7dqhFwmxbw86zZQg4GtU=.1be10660-ee5d-4654-9d4e-4fe3e449fd9b@github.com>
 <jOU2YrKbL5IN9drxis9yPT_AlliER47yfWT82oCm8_g=.92f9a11a-4f49-4897-974d-f77c5d4b6a21@github.com>
Message-ID: <9Mqr0y4WvsMWZ0WjKVW1gJPZ7tJAuVmZcEVGXNTU8uU=.4d4ffb1c-2813-4567-8495-1d8452079a79@github.com>

On Tue, 15 Nov 2022 23:51:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Added a comment, hopefully less confusing.
>
> On a second thought, passing derived pointers as arguments doesn't mix well with safepoint awareness.
> (And this stub eventually has to become safepoint aware.)
> Deriving a pointer inside the stub from a base oop and offset is trivial, recovering base oop from derived pointer is hard. 
> 
> It doesn't mean we have to address it right now.

Left it as is. I also postponed Bytebuffer support for now, for a separate PR.. we can also fix it then?

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

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

From duke at openjdk.org  Wed Nov 16 21:34:26 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 21:34:26 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v17]
In-Reply-To: <fw96wWvrsbFqCZc16QUimZ6Cg0OhKARsTY-oeRbfT-I=.5bc6a1e2-d99d-4784-9b41-d4722793c613@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <7hXP-vwxc6J7fklu8QuJqiIcSQRff-QyR1SZ0Fzfqmc=.33a38a51-38c3-451a-a756-ed538507f04e@github.com>
 <fw96wWvrsbFqCZc16QUimZ6Cg0OhKARsTY-oeRbfT-I=.5bc6a1e2-d99d-4784-9b41-d4722793c613@github.com>
Message-ID: <uTDRjOOo2n7sl7BHwuZ0y7H-YTuqXmzJYibjIp9RbN0=.718c0b9c-c71b-468f-86e8-a0a40daca038@github.com>

On Tue, 15 Nov 2022 19:44:16 GMT, Vladimir Ivanov <vlivanov 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 25 commits:
>> 
>>  - Vladimir's review comments
>>  - Merge remote-tracking branch 'origin/master' into avx512-poly
>>  - 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
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/7357a1a3...8f5942d9
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1004:
> 
>> 1002:   __ jcc(Assembler::less, L_process16Loop);
>> 1003: 
>> 1004:   poly1305_process_blocks_avx512(input, length,
> 
> I'd like to see a comment here explaining what register effects are implicit.
> 
> `poly1305_process_blocks_avx512` has the following comment, but it doesn't mention xmm registers:
> 
>   // Register Map:
>   // reserved: rsp, rbp, rcx
>   // PARAMs: rdi, rbx, rsi, r8-r12
>   // poly1305_multiply_scalar clobbers: r13-r15, rax, rdx

Just redid the register allocation, comments, names, function parameters.. hope its better

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

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

From xuelei at openjdk.org  Wed Nov 16 22:29:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 22:29:32 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <PyScw_P7fqTBmfoPMZsxKG0jg7OrYicDcXNap6JAwLI=.6d31bcd1-540e-4d9f-b48a-a7a91fea9b65@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
 <yPCJrDRgPFsFfXKPgnh7EgpXUEtU6KFOM-f36ucqVVU=.f7aaef88-d274-43db-aa8c-64a924be344b@github.com>
 <8b_KdNpM0FtpceAws-r7OsTWe1O5yPQWEDJHw8BT5Ww=.0f5f0f37-75b6-4672-a95e-ef873b10ddbf@github.com>
 <PyScw_P7fqTBmfoPMZsxKG0jg7OrYicDcXNap6JAwLI=.6d31bcd1-540e-4d9f-b48a-a7a91fea9b65@github.com>
Message-ID: <QJMXGG79YlvG0gdy5k1UhpNiaXlWcVjqSd9js0Js2DQ=.693198be-6b77-4b44-92ca-f6173f1f997b@github.com>

On Wed, 16 Nov 2022 21:28:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I was wondering if secure random generation could be sometimes fast and sometimes slow. I'm also not sure about how NativePRNG behaves in a multi-thread environment.

I see your point.  But it is still part of the key generation.  Measuring key generation using a fake secure random may be not useful in practice.  

The performance stability impact may be mitigated by the JMH mechanism.   I did not worry about it.

It may be useful to check different secure random providers, but it would be better to be addressed in a different patch.

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

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

From duke at openjdk.org  Wed Nov 16 22:37:50 2022
From: duke at openjdk.org (Johannes Waigel)
Date: Wed, 16 Nov 2022 22:37:50 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
Message-ID: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>

The `PCSCException` is thrown, but the error type is not visible due to the "private-packe" access rule.
By changing the visibility it is possible to handle / access this exception type explicitly in the catch.

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

Commit messages:
 - 8296408: Make the PCSCException public accessible

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

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

From aturbanov at openjdk.org  Wed Nov 16 22:37:54 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Nov 2022 22:37:54 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
Message-ID: <Ox3T4jFHmNQLrbNhoEJ8lecAP0XW22cPdaQZwL7IEA4=.46b98278-256f-4ce0-9047-31b74afcd947@github.com>

On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel <duke at openjdk.org> wrote:

> The `PCSCException` is thrown, but the error type is not visible due to the "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception type explicitly in the catch.

src/java.smartcardio/share/classes/sun/security/smartcardio/PCSCException.java line 38:

> 36:  * @author  Andreas Sterbenz
> 37:  */
> 38: final public class PCSCException extends Exception {

Use blessed modifiers order
Suggestion:

public final class PCSCException extends Exception {

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

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

From duke at openjdk.org  Wed Nov 16 22:37:57 2022
From: duke at openjdk.org (Johannes Waigel)
Date: Wed, 16 Nov 2022 22:37:57 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <Ox3T4jFHmNQLrbNhoEJ8lecAP0XW22cPdaQZwL7IEA4=.46b98278-256f-4ce0-9047-31b74afcd947@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <Ox3T4jFHmNQLrbNhoEJ8lecAP0XW22cPdaQZwL7IEA4=.46b98278-256f-4ce0-9047-31b74afcd947@github.com>
Message-ID: <QnccA23A4EUn2hqSEerTqlKE-qUm5jdBIA6oUIYKS3A=.f0f1a17f-b355-4f86-b308-6673cc086bcd@github.com>

On Sun, 13 Nov 2022 19:41:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> The `PCSCException` is thrown, but the error type is not visible due to the "private-packe" access rule.
>> By changing the visibility it is possible to handle / access this exception type explicitly in the catch.
>
> src/java.smartcardio/share/classes/sun/security/smartcardio/PCSCException.java line 38:
> 
>> 36:  * @author  Andreas Sterbenz
>> 37:  */
>> 38: final public class PCSCException extends Exception {
> 
> Use blessed modifiers order
> Suggestion:
> 
> public final class PCSCException extends Exception {

Thank you for feedback, I have adjusted the order

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

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

From duke at openjdk.org  Wed Nov 16 22:41:13 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 22:41:13 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: <_Syg8xU1sH0-zQuv70r8OKuK9KwSIHvl4GzdJF_Gy9s=.247f2738-5d1e-4bf9-ac1e-93034d446f7b@github.com>

On Fri, 11 Nov 2022 01:43:46 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
>
> Overall, it looks good.

@iwanowww Answered your review comments, please take a look again? Thanks again!

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

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

From duke at openjdk.org  Wed Nov 16 22:47:29 2022
From: duke at openjdk.org (Carter Kozak)
Date: Wed, 16 Nov 2022 22:47:29 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <E_3bz0JxCOscwX5t86vLmvdIGYgpMTMqax8H2FmbD0s=.16601606-d290-4310-b73a-ea3949940ddf@github.com>

On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Great point, I neglected to add benchmark coverage for the direct buffer case. I've updated my benchmark repository with a server using direct buffers:
https://github.com/carterkozak/java-crypto-allocation-performance/blob/develop/java-crypto-allocation-performance/src/main/java/com/palantir/java/crypto/allocations/DirectBufferTransportLayerSecurityBenchmark.java

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

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

From sviswanathan at openjdk.org  Wed Nov 16 22:50:31 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 16 Nov 2022 22:50:31 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
Message-ID: <y8FF70sBOLOjFDFIWvuoM2-AzKHFFoNOmfY4ezyC0EY=.4f5b97fd-8030-4c81-87f4-a698dfd8813d@github.com>

On Wed, 16 Nov 2022 20:52:14 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:
> 
>   redo register alloc with explicit func params

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 917:

> 915:   // Cleanup
> 916:   __ vpxorq(xmm0, xmm0, xmm0, Assembler::AVX_512bit);
> 917:   __ vpxorq(xmm1, xmm1, xmm1, Assembler::AVX_512bit);

You could use T0, T1 in place of xmm0, xmm1 here.

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

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

From vlivanov at openjdk.org  Wed Nov 16 23:10:31 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Nov 2022 23:10:31 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <y8FF70sBOLOjFDFIWvuoM2-AzKHFFoNOmfY4ezyC0EY=.4f5b97fd-8030-4c81-87f4-a698dfd8813d@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
 <y8FF70sBOLOjFDFIWvuoM2-AzKHFFoNOmfY4ezyC0EY=.4f5b97fd-8030-4c81-87f4-a698dfd8813d@github.com>
Message-ID: <9sCYEHe6Q8oPYHxAOWE4DjPGFalX0TIpaXkyWaGSyGk=.eb1e9867-8b83-4fed-a809-8c871cda8a23@github.com>

On Wed, 16 Nov 2022 22:47:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   redo register alloc with explicit func params
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 917:
> 
>> 915:   // Cleanup
>> 916:   __ vpxorq(xmm0, xmm0, xmm0, Assembler::AVX_512bit);
>> 917:   __ vpxorq(xmm1, xmm1, xmm1, Assembler::AVX_512bit);
> 
> You could use T0, T1 in place of xmm0, xmm1 here.

Or simply switch to `vzeroall` for `xmm0` - `xmm15`.

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

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

From vlivanov at openjdk.org  Wed Nov 16 23:19:15 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Nov 2022 23:19:15 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
Message-ID: <8UaOUsGNlGnh87OM1y8tMC6pVfeFn0nYUHyhvT7J-ss=.4e581e46-4759-4f69-8a6a-6383bc6f16de@github.com>

On Wed, 16 Nov 2022 20:52:14 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:
> 
>   redo register alloc with explicit func params

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 756:

> 754: 
> 755:   // Store R^8-R for later use
> 756:   __ evmovdquq(Address(rsp, 64*0), B0, Assembler::AVX_512bit);

Could these vector spills be eliminated? I counted 8 spare zmm registers available across the vector loop (xmm7-xmm12, xmm30, xmm31).

And here's what is explicitly used in `process256Loop`:

D0 D1              = xmm2-xmm3
B0 B1 B2 B3 B4 B5  = xmm19-xmm24
TMP                = xmm6
A0 A1 A2 A3 A4 A5  = xmm13-xmm18
R0 R1 R2 R1P R2P   = xmm25-xmm29
T0 T1 T2 T3 T4 T5  = xmm0-xmm5

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

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

From duke at openjdk.org  Wed Nov 16 23:19:16 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 23:19:16 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <8UaOUsGNlGnh87OM1y8tMC6pVfeFn0nYUHyhvT7J-ss=.4e581e46-4759-4f69-8a6a-6383bc6f16de@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
 <8UaOUsGNlGnh87OM1y8tMC6pVfeFn0nYUHyhvT7J-ss=.4e581e46-4759-4f69-8a6a-6383bc6f16de@github.com>
Message-ID: <Rwzj8FudpIjNzfdKft459T7lSt7O1IFD5FrX2o1fxpg=.c27afeef-dbaa-42d5-b0d8-42d0ce8f9247@github.com>

On Wed, 16 Nov 2022 23:12:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   redo register alloc with explicit func params
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 756:
> 
>> 754: 
>> 755:   // Store R^8-R for later use
>> 756:   __ evmovdquq(Address(rsp, 64*0), B0, Assembler::AVX_512bit);
> 
> Could these vector spills be eliminated? I counted 8 spare zmm registers available across the vector loop (xmm7-xmm12, xmm30, xmm31).
> 
> And here's what is explicitly used in `process256Loop`:
> 
> D0 D1              = xmm2-xmm3
> B0 B1 B2 B3 B4 B5  = xmm19-xmm24
> TMP                = xmm6
> A0 A1 A2 A3 A4 A5  = xmm13-xmm18
> R0 R1 R2 R1P R2P   = xmm25-xmm29
> T0 T1 T2 T3 T4 T5  = xmm0-xmm5

Interesting!! Let me try that!

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

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

From duke at openjdk.org  Wed Nov 16 23:19:19 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 23:19:19 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <9sCYEHe6Q8oPYHxAOWE4DjPGFalX0TIpaXkyWaGSyGk=.eb1e9867-8b83-4fed-a809-8c871cda8a23@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
 <y8FF70sBOLOjFDFIWvuoM2-AzKHFFoNOmfY4ezyC0EY=.4f5b97fd-8030-4c81-87f4-a698dfd8813d@github.com>
 <9sCYEHe6Q8oPYHxAOWE4DjPGFalX0TIpaXkyWaGSyGk=.eb1e9867-8b83-4fed-a809-8c871cda8a23@github.com>
Message-ID: <kyCbBQ9ukAXadLWfvdsrM1-u40o8voaN9PM7sUY8YGs=.ffed6f74-45c0-4fd0-bf9f-967a6f40f6e9@github.com>

On Wed, 16 Nov 2022 23:08:16 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 917:
>> 
>>> 915:   // Cleanup
>>> 916:   __ vpxorq(xmm0, xmm0, xmm0, Assembler::AVX_512bit);
>>> 917:   __ vpxorq(xmm1, xmm1, xmm1, Assembler::AVX_512bit);
>> 
>> You could use T0, T1 in place of xmm0, xmm1 here.
>
> Or simply switch to `vzeroall` for `xmm0` - `xmm15`.

ah.. I remember thinking about doing that.. `vzeroall` isnt encoded yet and I figured since I already have to do the xmm16-29, might as well do them all.. should I add that instruction too?

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

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

From vlivanov at openjdk.org  Wed Nov 16 23:41:16 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Nov 2022 23:41:16 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <kyCbBQ9ukAXadLWfvdsrM1-u40o8voaN9PM7sUY8YGs=.ffed6f74-45c0-4fd0-bf9f-967a6f40f6e9@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
 <y8FF70sBOLOjFDFIWvuoM2-AzKHFFoNOmfY4ezyC0EY=.4f5b97fd-8030-4c81-87f4-a698dfd8813d@github.com>
 <9sCYEHe6Q8oPYHxAOWE4DjPGFalX0TIpaXkyWaGSyGk=.eb1e9867-8b83-4fed-a809-8c871cda8a23@github.com>
 <kyCbBQ9ukAXadLWfvdsrM1-u40o8voaN9PM7sUY8YGs=.ffed6f74-45c0-4fd0-bf9f-967a6f40f6e9@github.com>
Message-ID: <2mAogemIauwWUYmfUtLgDNxtkskab6gjPrcFIQghuYk=.3f88c715-2d68-4995-9eaa-e989b6b5be8f@github.com>

On Wed, 16 Nov 2022 23:14:45 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Or simply switch to `vzeroall` for `xmm0` - `xmm15`.
>
> ah.. I remember thinking about doing that.. `vzeroall` isnt encoded yet and I figured since I already have to do the xmm16-29, might as well do them all.. should I add that instruction too?

Yes, please. And for the upper half of register file, just code it as a loop over register range:

for (int rxmm_num = 16; rxmm_num < 30; rxmm_num++) {
  XMMRegister rxmm = as_XMMRegister(rxmm_num);
  __ vpxorq(rxmm, rxmm, rxmm, Assembler::AVX_512bit);
}

or even

// Zeroes zmm16-zmm31. 
for (XMMRegister rxmm = xmm16; rxmm->is_valid(); rxmm = rxmm->successor()) {
  __ vpxorq(rxmm, rxmm, rxmm, Assembler::AVX_512bit);
}

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

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

From duke at openjdk.org  Wed Nov 16 23:45:29 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Nov 2022 23:45:29 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <2mAogemIauwWUYmfUtLgDNxtkskab6gjPrcFIQghuYk=.3f88c715-2d68-4995-9eaa-e989b6b5be8f@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
 <y8FF70sBOLOjFDFIWvuoM2-AzKHFFoNOmfY4ezyC0EY=.4f5b97fd-8030-4c81-87f4-a698dfd8813d@github.com>
 <9sCYEHe6Q8oPYHxAOWE4DjPGFalX0TIpaXkyWaGSyGk=.eb1e9867-8b83-4fed-a809-8c871cda8a23@github.com>
 <kyCbBQ9ukAXadLWfvdsrM1-u40o8voaN9PM7sUY8YGs=.ffed6f74-45c0-4fd0-bf9f-967a6f40f6e9@github.com>
 <2mAogemIauwWUYmfUtLgDNxtkskab6gjPrcFIQghuYk=.3f88c715-2d68-4995-9eaa-e989b6b5be8f@github.com>
Message-ID: <8Wbchzsuzf9Vx7btDUoVEevuDmCdRCuKMlZZjBEyXmg=.8c6ef831-9f5c-4b32-b007-c0bca9161c9f@github.com>

On Wed, 16 Nov 2022 23:39:00 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> ah.. I remember thinking about doing that.. `vzeroall` isnt encoded yet and I figured since I already have to do the xmm16-29, might as well do them all.. should I add that instruction too?
>
> Yes, please. And for the upper half of register file, just code it as a loop over register range:
> 
> for (int rxmm_num = 16; rxmm_num < 30; rxmm_num++) {
>   XMMRegister rxmm = as_XMMRegister(rxmm_num);
>   __ vpxorq(rxmm, rxmm, rxmm, Assembler::AVX_512bit);
> }
> 
> or even
> 
> // Zeroes zmm16-zmm31. 
> for (XMMRegister rxmm = xmm16; rxmm->is_valid(); rxmm = rxmm->successor()) {
>   __ vpxorq(rxmm, rxmm, rxmm, Assembler::AVX_512bit);
> }

Will do.. ("loop" erm.. wow.. "duh, this isn't assembler!") Thanks!!

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

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

From duke at openjdk.org  Thu Nov 17 03:23:49 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 17 Nov 2022 03:23:49 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v21]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@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:

  vzeroall, no spill, reg re-map

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/dbdfd1dc..56aed9b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=19-20

  Stats: 182 lines in 3 files changed: 15 ins; 44 del; 123 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 17 03:23:49 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 17 Nov 2022 03:23:49 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v21]
In-Reply-To: <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
Message-ID: <VZS2fFxgYgi_z45Infcicw9wcN09O9av5TOjIiuVcl8=.a67c2dfa-6eb0-4073-9d83-258376cc4169@github.com>

On Thu, 17 Nov 2022 03:19:15 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:
> 
>   vzeroall, no spill, reg re-map

@iwanowww Another round ready your way :)

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

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

From duke at openjdk.org  Thu Nov 17 03:23:51 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 17 Nov 2022 03:23:51 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <Rwzj8FudpIjNzfdKft459T7lSt7O1IFD5FrX2o1fxpg=.c27afeef-dbaa-42d5-b0d8-42d0ce8f9247@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
 <8UaOUsGNlGnh87OM1y8tMC6pVfeFn0nYUHyhvT7J-ss=.4e581e46-4759-4f69-8a6a-6383bc6f16de@github.com>
 <Rwzj8FudpIjNzfdKft459T7lSt7O1IFD5FrX2o1fxpg=.c27afeef-dbaa-42d5-b0d8-42d0ce8f9247@github.com>
Message-ID: <42Jq_3oM24kB-AcDEzAdsHIQwcOZX0y9_boTctpLUa4=.6076a16c-9cc6-4755-9eaf-1f6ca4c1fb85@github.com>

On Wed, 16 Nov 2022 23:16:14 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 756:
>> 
>>> 754: 
>>> 755:   // Store R^8-R for later use
>>> 756:   __ evmovdquq(Address(rsp, 64*0), B0, Assembler::AVX_512bit);
>> 
>> Could these vector spills be eliminated? I counted 8 spare zmm registers available across the vector loop (xmm7-xmm12, xmm30, xmm31).
>> 
>> And here's what is explicitly used in `process256Loop`:
>> 
>> D0 D1              = xmm2-xmm3
>> B0 B1 B2 B3 B4 B5  = xmm19-xmm24
>> TMP                = xmm6
>> A0 A1 A2 A3 A4 A5  = xmm13-xmm18
>> R0 R1 R2 R1P R2P   = xmm25-xmm29
>> T0 T1 T2 T3 T4 T5  = xmm0-xmm5
>
> Interesting!! Let me try that!

Done!

PS: This find really was great!
PPS: I also reordered the map alphabetically and counted in-order... it was just really bugging me!!

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

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

From duke at openjdk.org  Thu Nov 17 03:23:52 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 17 Nov 2022 03:23:52 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v20]
In-Reply-To: <8Wbchzsuzf9Vx7btDUoVEevuDmCdRCuKMlZZjBEyXmg=.8c6ef831-9f5c-4b32-b007-c0bca9161c9f@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <vevFyyVp7yfNgrsssGqolR-fqn6eVcc4y-O1_vOyIJI=.9d7af407-5d4b-4785-ae11-3c234111d381@github.com>
 <y8FF70sBOLOjFDFIWvuoM2-AzKHFFoNOmfY4ezyC0EY=.4f5b97fd-8030-4c81-87f4-a698dfd8813d@github.com>
 <9sCYEHe6Q8oPYHxAOWE4DjPGFalX0TIpaXkyWaGSyGk=.eb1e9867-8b83-4fed-a809-8c871cda8a23@github.com>
 <kyCbBQ9ukAXadLWfvdsrM1-u40o8voaN9PM7sUY8YGs=.ffed6f74-45c0-4fd0-bf9f-967a6f40f6e9@github.com>
 <2mAogemIauwWUYmfUtLgDNxtkskab6gjPrcFIQghuYk=.3f88c715-2d68-4995-9eaa-e989b6b5be8f@github.com>
 <8Wbchzsuzf9Vx7btDUoVEevuDmCdRCuKMlZZjBEyXmg=.8c6ef831-9f5c-4b32-b007-c0bca9161c9f@github.com>
Message-ID: <Z4vZFqS5Hb7RXR2BdXRDW2IY4dsnyqS_YBS_08mH3zY=.c9d7a361-b0a4-4438-a4fc-56677236a300@github.com>

On Wed, 16 Nov 2022 23:41:32 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Yes, please. And for the upper half of register file, just code it as a loop over register range:
>> 
>> for (int rxmm_num = 16; rxmm_num < 30; rxmm_num++) {
>>   XMMRegister rxmm = as_XMMRegister(rxmm_num);
>>   __ vpxorq(rxmm, rxmm, rxmm, Assembler::AVX_512bit);
>> }
>> 
>> or even
>> 
>> // Zeroes zmm16-zmm31. 
>> for (XMMRegister rxmm = xmm16; rxmm->is_valid(); rxmm = rxmm->successor()) {
>>   __ vpxorq(rxmm, rxmm, rxmm, Assembler::AVX_512bit);
>> }
>
> Will do.. ("loop" erm.. wow.. "duh, this isn't assembler!") Thanks!!

done
(Note: disassembler proof for vzeroall encoding

   0x7fffed0022f8:      vzeroall
   0x7fffed0022fb:      vpxorq zmm16,zmm16,zmm16
   0x7fffed002301:      vpxorq zmm17,zmm17,zmm17
   0x7fffed002307:      vpxorq zmm18,zmm18,zmm18
   0x7fffed00230d:      vpxorq zmm19,zmm19,zmm19
   0x7fffed002313:      vpxorq zmm20,zmm20,zmm20
   0x7fffed002319:      vpxorq zmm21,zmm21,zmm21
   0x7fffed00231f:      vpxorq zmm22,zmm22,zmm22
   0x7fffed002325:      vpxorq zmm23,zmm23,zmm23
   0x7fffed00232b:      vpxorq zmm24,zmm24,zmm24
   0x7fffed002331:      vpxorq zmm25,zmm25,zmm25
   0x7fffed002337:      vpxorq zmm26,zmm26,zmm26
   0x7fffed00233d:      vpxorq zmm27,zmm27,zmm27
   0x7fffed002343:      vpxorq zmm28,zmm28,zmm28
   0x7fffed002349:      vpxorq zmm29,zmm29,zmm29
   0x7fffed00234f:      vpxorq zmm30,zmm30,zmm30
   0x7fffed002355:      vpxorq zmm31,zmm31,zmm31
   0x7fffed00235b:      cmp    ebx,0x10
   0x7fffed00235e:      jl     0x7fffed0023e6

)

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

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

From djelinski at openjdk.org  Thu Nov 17 09:39:26 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 17 Nov 2022 09:39:26 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <vv42s4M3H1A85iwTTMsaCMSDmthxab_SMngxQYQMVYA=.d7955142-c48a-48d2-bd95-94aac8044e89@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
 <vv42s4M3H1A85iwTTMsaCMSDmthxab_SMngxQYQMVYA=.d7955142-c48a-48d2-bd95-94aac8044e89@github.com>
Message-ID: <M6vQUvk7cfUJ5-av0lxyE8WIr06yKvPRyqMaBVwLnNI=.19df574c-4afd-411f-91e9-7794bc089a0b@github.com>

On Tue, 15 Nov 2022 20:46:43 GMT, Xubo Zhang <duke at openjdk.org> wrote:

>> 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>
>
> Hi [XueleiFan](https://github.com/XueleiFan)
> This shouldn't be the case unless there is a kernel bug. Multiple threads using ThreadLocal to access /dev/random is just like multiple applications accessing it.

Hi @xbzhang99,
Could you explain the problem you are trying to solve?
Random number generation is usually just a tiny fraction of a larger algorithm, and the SecureRandom instance is rarely contended outside of microbenchmark setting. And if it's not contended, users will only pay the cost of using a ThreadLocal for no real benefit.

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

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

From coffeys at openjdk.org  Thu Nov 17 12:33:31 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 17 Nov 2022 12:33:31 GMT
Subject: RFR: 8286575: Document how properties in java.security are parsed
Message-ID: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>

A doc edit to indicate that modifications of values in java.security conf file would require a JVM restart in order for such changes to be detected.

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

Commit messages:
 - 8286575: Document how properties in java.security are parsed

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

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

From alanb at openjdk.org  Thu Nov 17 12:53:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Nov 2022 12:53:22 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
Message-ID: <iRk5pP7r1tnymKDFWnWkiYFAy9f1T8L1H0-Tah8Wx1g=.7fc8f91a-7aec-4922-9294-4b30d955fd83@github.com>

On Mon, 14 Nov 2022 16:37:41 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>
>
> 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>

This proposal doesn't look good when there are short lived threads and problematic when using virtual threads as there will eventually be a RandomIO per task. Has there been any consideration given to a shared cache of RandomIO objects where the current threadId or a ThreadLocalRandom is used to select?

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

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

From weijun at openjdk.org  Thu Nov 17 15:57:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Nov 2022 15:57:40 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v4]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <HMivhpc0AQ2yzuofgX1L8B1yGJvjMLu1tLuwxaui9Hg=.97e18de1-5f5b-42fa-92c8-d8975e442ccc@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  wrong variable checked

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/fc315aeb..491933d2

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Thu Nov 17 16:22:29 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Nov 2022 16:22:29 GMT
Subject: RFR: 8296399: crlNumExtVal might be null inside X509CRLSelector::match
Message-ID: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>

When `X509CRLSelector ` requires a CRL number extension but a CRL does not have it, the CRL should not be selected.

Note: the test uses a new internal API introduced in https://github.com/openjdk/jdk/pull/11151.

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

Commit messages:
 - the fix and the test

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

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

From weijun at openjdk.org  Thu Nov 17 16:25:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Nov 2022 16:25:22 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
Message-ID: <4fokOYO4wwbHMmYSY5wt0R8odLPAQOkAdxdOAxiBx0Y=.321d8ea9-bd6d-46b7-93bb-38bab9822aa3@github.com>

On Sun, 13 Nov 2022 19:58:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> In the current key pair generation micro-benchmark, there is no cases for `EdDSA`, `XDH`, and `RSASSA-PSS`.  This PR is trying to add these algorithms.
> 
> BTW, here is the benchmarking data on a Linux x86_64 platform.  You can see how much the performance difference could be among key pair generation algorithms.
> 
> 
> Benchmark                                                         (algorithm)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          256              thrpt   40  1647.342 ?  8.548  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          384              thrpt   40   698.990 ?  5.647  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          521              thrpt   40   364.970 ?  5.556  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          255              thrpt   40  2400.202 ? 17.685  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          448              thrpt   40   680.304 ?  5.923  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         1024              thrpt   40    69.614 ?  1.907  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         2048              thrpt   40     9.192 ?  0.567  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         3072              thrpt   40     2.352 ?  0.385  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         4096              thrpt   40     0.815 ?  0.221  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         1024              thrpt   40    70.022 ?  2.336  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         2048              thrpt   40     9.260 ?  0.730  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         3072              thrpt   40     2.305 ?  0.369  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         4096              thrpt   40     0.902 ?  0.194  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          255              thrpt   40  5061.279 ? 33.878  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          448              thrpt   40  1404.786 ? 11.083  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         1024              thrpt   40  9486.010 ? 20.242  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         2048              thrpt   40  2174.506 ?  2.514  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         1024              thrpt   40  3532.067 ?  7.882  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         2048              thrpt   40   523.746 ?  0.704  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     DSA         2048              thrpt   40  2171.807 ?  3.505  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     RSA         2048              thrpt   40     9.549 ?  0.809  ops/s
> 
> 
> 
> Thanks,
> Xuelei

If "DSA" and "DH" can be grouped inside a single class, is it also possible to group "RSA" and "RSASSA-PSS", and "XDH" and "EdDSA"?

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

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

From sviswanathan at openjdk.org  Thu Nov 17 18:14:25 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 17 Nov 2022 18:14:25 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: <iXI36w_0YjmY0UPpspZRDe6ZMXEiGM_BDaO4NS8QOGM=.fe990924-094f-433d-9f4b-a25aa5a0f42f@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

May be @nick-arm could review and approve for aarch64.

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

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

From ascarpino at openjdk.org  Thu Nov 17 18:26:20 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 17 Nov 2022 18:26:20 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <wb_xytmFE1ahFThXnCv2aZ1sk2I9d8wkAanG6YXx3hQ=.4dc90457-21be-43d8-8353-92224cd20999@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <YRx8_op_CPaI_ngmFQDzNLdywQHmeS63IWIZC4WT56U=.ca69bdd8-d6f8-42ff-a129-6330cabec687@github.com>
 <3344a55Z7_vytPlf9K9GOHXJVPOZr1Yrf0LTGs3ZhL4=.4ba8d840-6c92-4caf-9892-efe2499455cd@github.com>
 <wb_xytmFE1ahFThXnCv2aZ1sk2I9d8wkAanG6YXx3hQ=.4dc90457-21be-43d8-8353-92224cd20999@github.com>
Message-ID: <85t8lLhxA9vxVAFbwAy8DfkUQT1ZHqUh3EDXlWqtz2I=.acf66f77-7313-4231-9a10-6f1687b81800@github.com>

On Wed, 16 Nov 2022 18:48:58 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Thanks for looking into this, @ascarpino!
> 
> In testing this using a local build, it improves performance in cases using heap buffers (a super-set of the socket case), however servers which use direct byte-buffers still exhibit a similar performance regression (heavy allocation compared to jdk17, ~10% slower TLS performance in HTTP+TLS benchmarks). It's possible that has a different root cause, but the outcome is strikingly similar.

Looking at this, it's not related to the same in-place issues.  This is a result of the combined intrinsics requirement .  Maybe some better tuning can be done, but I think this is unavoidable.  I can consider this in a future PR

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

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

From jnimeh at openjdk.org  Thu Nov 17 18:53:24 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 17 Nov 2022 18:53:24 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: <emKiLeQ71GF0MnhnB12gWSYRIg7ZSe8Efl0tnxPv300=.2c03f75a-2e3f-4708-a864-557119222cfa@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

Another pair of arm-knowledgeable eyes on this is always welcome!

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

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

From duke at openjdk.org  Thu Nov 17 19:04:16 2022
From: duke at openjdk.org (Carter Kozak)
Date: Thu, 17 Nov 2022 19:04:16 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <85t8lLhxA9vxVAFbwAy8DfkUQT1ZHqUh3EDXlWqtz2I=.acf66f77-7313-4231-9a10-6f1687b81800@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <YRx8_op_CPaI_ngmFQDzNLdywQHmeS63IWIZC4WT56U=.ca69bdd8-d6f8-42ff-a129-6330cabec687@github.com>
 <3344a55Z7_vytPlf9K9GOHXJVPOZr1Yrf0LTGs3ZhL4=.4ba8d840-6c92-4caf-9892-efe2499455cd@github.com>
 <wb_xytmFE1ahFThXnCv2aZ1sk2I9d8wkAanG6YXx3hQ=.4dc90457-21be-43d8-8353-92224cd20999@github.com>
 <85t8lLhxA9vxVAFbwAy8DfkUQT1ZHqUh3EDXlWqtz2I=.acf66f77-7313-4231-9a10-6f1687b81800@github.com>
Message-ID: <0hfrSWid1AGx5vcQd4NTNqjZS1Vk8B7VPpoFlFJjgR0=.9dc87150-86b5-4f9f-afc6-cc0030412760@github.com>

On Thu, 17 Nov 2022 18:24:07 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Looking at this, it's not related to the same in-place issues. This is a result of the combined intrinsics requirement . Maybe some better tuning can be done, but I think this is unavoidable. I can consider this in a future PR

That makes sense, perhaps we could document the finding in a new jira issue for posterity in case it impacts other folks as well? I can't overstate my appreciation for your work, thank you!

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

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

From mullan at openjdk.org  Thu Nov 17 19:24:22 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Nov 2022 19:24:22 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
Message-ID: <j_FOCoVVzp8KXoWJ8pwSDMX4_ybXNiUwraYu_kVco-E=.0f835f44-a93e-4c1f-8a20-6763a6508292@github.com>

On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel <duke at openjdk.org> wrote:

> The `PCSCException` is thrown, but the error type is not visible due to the "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception type explicitly in the catch.

Can you explain in a bit more detail why this needs to be public? It is an internal class, so applications should not be accessing it, even if it is public. Perhaps what is really needed is a public *standard* API.

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

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

From vlivanov at openjdk.org  Thu Nov 17 19:36:33 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Nov 2022 19:36:33 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v21]
In-Reply-To: <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
Message-ID: <Bt4UNZU2itTeHs_2ojFCD64AXpGPiI8gveUtRg5mea0=.2926b137-f31e-4505-9a96-815e4f5ab851@github.com>

On Thu, 17 Nov 2022 03:23:49 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:
> 
>   vzeroall, no spill, reg re-map

Overall, looks good. Just one minor cleanup suggestion.

I've submitted the latest patch for testing (hs-tier1 - hs-tier4).

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 377:

> 375:   __ shlq(t0, 40);
> 376:   __ addq(a1, t0);
> 377:   if (a2 == noreg) {

Please, get rid of early return and turn the check into `if (a2 != noreg) { ... }` which guards the following code.

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

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

From mullan at openjdk.org  Thu Nov 17 19:54:17 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Nov 2022 19:54:17 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <MJqr_ODfGGpEjNTTVpu6rGzSTHFTfjJJ1g48RK1ykFQ=.b36d14ed-0951-4081-aa9b-b6efafb326fa@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <ZIyMVSrvrcJL7cCkfeYGEo1Ti0uc8r--9seOCzpSTos=.12290c69-ddac-4f2a-a572-9f02d815d679@github.com>
 <1SgjlQatBEnDkM7SKknVvONQZlTwxTM_1fQemk4-MbY=.14a019db-58c0-4dc8-af74-2b7d294c766c@github.com>
 <0JwKXTVP7rKAH_q7PdO4cBxfzqh516EOlvdropX57-M=.5247755b-5536-4695-b5f8-2d02639d9407@github.com>
 <MJqr_ODfGGpEjNTTVpu6rGzSTHFTfjJJ1g48RK1ykFQ=.b36d14ed-0951-4081-aa9b-b6efafb326fa@github.com>
Message-ID: <5ZyouIzVpFlXHx3lcYTWe4kGLMn76aWK5EICOAY1BiU=.9a19f750-634f-4f34-8cea-e47b9bfc5d0c@github.com>

On Wed, 16 Nov 2022 07:41:45 GMT, pandaapo <duke at openjdk.org> wrote:

> Because `JarVerifier#setEagerValidation` will be removed, the field `eagerValidation` will always be false.
> 
> There are some codes using this field: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/JarVerifier.java#L361-L381 Can I remove the `eagerValidation` condition from `if(eagerValidation && sigFileSigners.get(name) != null)`?

You can remove the whole if block since `eagerValidation` will never be true, and this block was only performed if it was true.

> 
> If I can, can I remove this field from `JarVerifier` then?

Yes.

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

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

From duke at openjdk.org  Thu Nov 17 20:22:25 2022
From: duke at openjdk.org (Xubo Zhang)
Date: Thu, 17 Nov 2022 20:22:25 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <rXhkm1_ONxveP0dOC_L9yAf5WyuwUu8-r83-Yts7O1k=.e213bab0-3867-4f5b-8527-c25951d8cc24@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
 <rXhkm1_ONxveP0dOC_L9yAf5WyuwUu8-r83-Yts7O1k=.e213bab0-3867-4f5b-8527-c25951d8cc24@github.com>
Message-ID: <BFP41s_X4W16A-qCqWERyB2Y-b4CkXBFjBHsxl2thgg=.f442d199-41d2-4adb-ba5d-1f0d8181613d@github.com>

On Wed, 16 Nov 2022 20:59:24 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Any ideas why it is not scaling linearly with number of threads? One would think that random numbers are the 'definition' of data-independent and should scale linearly with number of CPUs

it could be that the singleton RandomIO object has to be serialized among multiple threads

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

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

From aturbanov at openjdk.org  Thu Nov 17 20:26:32 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 17 Nov 2022 20:26:32 GMT
Subject: RFR: 8297074: Use enhanced-for cycle instead of Enumeration in
 javax.crypto
In-Reply-To: <ajoBIo63ZKmaR4rb6wyWELT-xTPV9B5iUXN0Jgb3aN8=.2f3b9dcb-8081-4ce8-9e5f-333813f34adc@github.com>
References: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
 <ajoBIo63ZKmaR4rb6wyWELT-xTPV9B5iUXN0Jgb3aN8=.2f3b9dcb-8081-4ce8-9e5f-333813f34adc@github.com>
Message-ID: <FFGjbDgK4G0RlUTPhRNJh-6_A-NoLOtUA2Fe2-jgv8M=.6fd6b41c-dea9-4205-88ff-8c2dc06c9b88@github.com>

On Wed, 16 Nov 2022 02:00:23 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> java.util.Enumeration is a legacy interface from java 1.0.
>> There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.
>
> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 232:
> 
>> 230:         // find out if there is anything we should add into
>> 231:         // ret.
>> 232:         Enumeration<String> thisKeys = this.perms.keys();
> 
> There are a couple other places where you could do the same enhanced for loop with arrays:  Current lines: 107, 254, 287.

There are many places in javax crypto which iterate over an array. I think it's worth to create a separate issue

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

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

From aturbanov at openjdk.org  Thu Nov 17 20:28:26 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 17 Nov 2022 20:28:26 GMT
Subject: Integrated: 8297074: Use enhanced-for cycle instead of Enumeration in
 javax.crypto
In-Reply-To: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
References: <fLjeZUfcV3CXTRqSDHwNmcjCI3j8P_d9mhU3yzx_lqw=.102a02b7-cd0f-44e0-8236-2ffe6f490134@github.com>
Message-ID: <Z3P-RfrJhOu11pPxI22_gnfqk4DaVoOruUngxgAj3G4=.e5a66f2a-8a6a-4697-a57d-2915b10706dc@github.com>

On Mon, 7 Nov 2022 16:54:32 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: 66228f77
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66228f77fe37899722fb414ca6fa45f94be85116
Stats:     36 lines in 3 files changed: 0 ins; 30 del; 6 mod

8297074: Use enhanced-for cycle instead of Enumeration in javax.crypto

Reviewed-by: weijun, wetmore

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

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

From duke at openjdk.org  Thu Nov 17 20:32:19 2022
From: duke at openjdk.org (pandaapo)
Date: Thu, 17 Nov 2022 20:32:19 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map
In-Reply-To: <5ZyouIzVpFlXHx3lcYTWe4kGLMn76aWK5EICOAY1BiU=.9a19f750-634f-4f34-8cea-e47b9bfc5d0c@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <ZIyMVSrvrcJL7cCkfeYGEo1Ti0uc8r--9seOCzpSTos=.12290c69-ddac-4f2a-a572-9f02d815d679@github.com>
 <1SgjlQatBEnDkM7SKknVvONQZlTwxTM_1fQemk4-MbY=.14a019db-58c0-4dc8-af74-2b7d294c766c@github.com>
 <0JwKXTVP7rKAH_q7PdO4cBxfzqh516EOlvdropX57-M=.5247755b-5536-4695-b5f8-2d02639d9407@github.com>
 <MJqr_ODfGGpEjNTTVpu6rGzSTHFTfjJJ1g48RK1ykFQ=.b36d14ed-0951-4081-aa9b-b6efafb326fa@github.com>
 <5ZyouIzVpFlXHx3lcYTWe4kGLMn76aWK5EICOAY1BiU=.9a19f750-634f-4f34-8cea-e47b9bfc5d0c@github.com>
Message-ID: <tzP4Rmumcezcx-wySsmGHrlp5h0r9zzHU4596vaFkDk=.2434f0f9-9ace-4e07-a8bd-7b19375a9037@github.com>

On Thu, 17 Nov 2022 19:50:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > Because `JarVerifier#setEagerValidation` will be removed, the field `eagerValidation` will always be false.
> > There are some codes using this field: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/JarVerifier.java#L361-L381 Can I remove the `eagerValidation` condition from `if(eagerValidation && sigFileSigners.get(name) != null)`?
> 
> You can remove the whole if block since `eagerValidation` will never be true, and this block was only performed if it was true.

OK, then the first param `JarFile jar` of this method will be redundant, I will refactor it and related code.

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

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

From weijun at openjdk.org  Thu Nov 17 20:35:23 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Nov 2022 20:35:23 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
Message-ID: <leRMK1-xqn_fd8x36iR6Hoeg5k9rFXpHd5b3jEn3B7I=.8e68eefc-efac-4520-922f-58cf446d29ef@github.com>

On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel <duke at openjdk.org> wrote:

> The `PCSCException` is thrown, but the error type is not visible due to the "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception type explicitly in the catch.

Making an exception public is only useful if you want to catch it after calling a public API. Since it does not appear in any of the throws clause in the public APIs, is there a place where it might be the cause of an exception and you're thinking about using `getCause() instanceof PSCSException pe` to drill into it?

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

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

From duke at openjdk.org  Thu Nov 17 20:42:27 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 17 Nov 2022 20:42:27 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v22]
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <encTlnf9qtjfjtVa-jDoWJMcUc6AwRtSDj7tk_OyBM0=.9728a3c6-6009-4873-9cb3-28ac8c262282@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:

  remove early return

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10582/files
  - new: https://git.openjdk.org/jdk/pull/10582/files/56aed9b1..08ea45e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10582&range=20-21

  Stats: 29 lines in 1 file changed: 13 ins; 14 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 17 20:42:27 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 17 Nov 2022 20:42:27 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v21]
In-Reply-To: <Bt4UNZU2itTeHs_2ojFCD64AXpGPiI8gveUtRg5mea0=.2926b137-f31e-4505-9a96-815e4f5ab851@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
 <Bt4UNZU2itTeHs_2ojFCD64AXpGPiI8gveUtRg5mea0=.2926b137-f31e-4505-9a96-815e4f5ab851@github.com>
Message-ID: <irGzi76yjKKgch-zgHgreUxprgdldCOQV1_p9RXCuoQ=.2f4a9cae-e119-448d-8de4-e326e3e79b47@github.com>

On Thu, 17 Nov 2022 19:30:14 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   vzeroall, no spill, reg re-map
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 377:
> 
>> 375:   __ shlq(t0, 40);
>> 376:   __ addq(a1, t0);
>> 377:   if (a2 == noreg) {
> 
> Please, get rid of early return and turn the check into `if (a2 != noreg) { ... }` which guards the following code.

done (some golang-ism slipped in.. rewiring habits again)

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

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

From duke at openjdk.org  Thu Nov 17 21:04:22 2022
From: duke at openjdk.org (Xubo Zhang)
Date: Thu, 17 Nov 2022 21:04:22 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <RxsBP-mWC8riHZuE-42TOlyJGZAV4X8lWfzVbpKUG6s=.8c0d1cd1-9183-4709-9e3f-35137dcb10e3@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
 <RxsBP-mWC8riHZuE-42TOlyJGZAV4X8lWfzVbpKUG6s=.8c0d1cd1-9183-4709-9e3f-35137dcb10e3@github.com>
Message-ID: <4ykVt6IPCFtXIYiislW861qGzRNVX-Hw2Hw5N9NBlUc=.1307869a-8982-4e01-92f4-6a42339973b7@github.com>

On Wed, 16 Nov 2022 21:12:09 GMT, Bernd <duke at openjdk.org> wrote:

> Would it be easier to remove the state (singleton, thread local) caching completely? If somebody request a new instance just seed and return it. That might in some situations be even less seeding than once per thread and it decreases stat sharing even more.

ThreadLocal is basically a middle path. Creating a RandomIO to for access /dev/random each time 

> Would it be easier to remove the state (singleton, thread local) caching completely? If somebody request a new instance just seed and return it. That might in some situations be even less seeding than once per thread and it decreases stat sharing even more.

that would require too many open and close of /dev/(urandom). ThreadLocal is basically the middle path. The singleton approach only needs one open and close, however it would require threads to be sync'ed to access /dev/(urandom)

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

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

From mullan at openjdk.org  Thu Nov 17 21:22:23 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Nov 2022 21:22:23 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v3]
In-Reply-To: <m3iytCck8_0wVvjqOy8oLGGfLk7-is0RbcPlB_5MDTo=.78124cd2-ce48-44c5-9951-d599aaa895e3@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
 <m3iytCck8_0wVvjqOy8oLGGfLk7-is0RbcPlB_5MDTo=.78124cd2-ce48-44c5-9951-d599aaa895e3@github.com>
Message-ID: <bacpntJps9H0dm-CXgQpQX8RzmqR4a087V2LBdeXYRM=.c3ebcc08-387a-4881-a35a-74aefe7d9c32@github.com>

On Wed, 16 Nov 2022 13:21:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
>> 
>> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one extra space

Wondering why you named the methods "signNew" instead of just "sign" which seems simpler to me.
Otherwise looks fine.

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

Marked as reviewed by mullan (Reviewer).

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

From duke at openjdk.org  Thu Nov 17 21:23:34 2022
From: duke at openjdk.org (Xubo Zhang)
Date: Thu, 17 Nov 2022 21:23:34 GMT
Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads
 [v2]
In-Reply-To: <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
References: <cKk_qdPEmDSFPABJ3TKjNyjZKjvFsNZ2b7ZacZ3SajM=.261f426f-b38b-44f7-a59c-7276df76d666@github.com>
 <o4CBuHegbvp76-FPR2b7zNCHOTU4lBXPv4op43xc80g=.c7ab8e20-e685-4134-bc45-39b73cbc5324@github.com>
Message-ID: <fuep0rRiua59akDyyMdFhqsTn1Pltfi3im4NiWRZp_Y=.ac586eaa-2e10-473d-ab48-7c15b7bdd5e3@github.com>

On Mon, 14 Nov 2022 16:37:41 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>
>
> 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>

> Could you explain the problem you are trying to solve?
> Random number generation is usually just a tiny fraction of a larger algorithm, and the SecureRandom instance is rarely contended outside of microbenchmark setting. And if it's not contended, users will only pay the cost of using a ThreadLocal for no real benefit.



> This proposal doesn't look good when there are short lived threads and problematic when using virtual threads as there will eventually be a RandomIO per task. Has there been any consideration given to a shared cache of RandomIO objects where the current threadId or a ThreadLocalRandom is used to select?

That might be an issue. Could you provide some example of such approach?

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

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

From weijun at openjdk.org  Thu Nov 17 21:53:24 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Nov 2022 21:53:24 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v5]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <dnnHeHurVhZtw6XG5zl4pf1wT_dtcy0bdLxLzCXzi78=.c00c78d2-3638-4f5f-b5a3-b98440c9266b@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  another wrong variable checked

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/491933d2..2d944433

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Thu Nov 17 21:53:24 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Nov 2022 21:53:24 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v4]
In-Reply-To: <HMivhpc0AQ2yzuofgX1L8B1yGJvjMLu1tLuwxaui9Hg=.97e18de1-5f5b-42fa-92c8-d8975e442ccc@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <HMivhpc0AQ2yzuofgX1L8B1yGJvjMLu1tLuwxaui9Hg=.97e18de1-5f5b-42fa-92c8-d8975e442ccc@github.com>
Message-ID: <NzENakFUuJD_R7bcTFZFctqtENA74LBxWT-cTKp70vE=.9f1efa38-81fa-4d3c-a5d0-2d3aa70a1ccc@github.com>

On Thu, 17 Nov 2022 15:57:40 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong variable checked

Sigh. Found 2 wrong variables used. I'll add a regression test.

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

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

From jjg at openjdk.org  Thu Nov 17 22:31:43 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 17 Nov 2022 22:31:43 GMT
Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java
Message-ID: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>

Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
(See https://bugs.openjdk.org/browse/JDK-8297165)

In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

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

Commit messages:
 - JDK-8297164: Update troff man pages and CheckManPageOptions.java

Changes: https://git.openjdk.org/jdk/pull/11223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297164
  Stats: 8944 lines in 29 files changed: 471 ins; 1589 del; 6884 mod
  Patch: https://git.openjdk.org/jdk/pull/11223.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223

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

From duke at openjdk.org  Thu Nov 17 23:10:21 2022
From: duke at openjdk.org (Johannes Waigel)
Date: Thu, 17 Nov 2022 23:10:21 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
Message-ID: <MhOjIIg9TntJoNUHWK54oNmv6Eslhn1mz5nSOusdh80=.828ae267-6650-411e-b77f-8585026a84bf@github.com>

On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel <duke at openjdk.org> wrote:

> The `PCSCException` is thrown, but the error type is not visible due to the "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception type explicitly in the catch.

Exactly what wangweij says. Checking the instance is fundamental to find out the real cause. Especially because `PCSCException` is thrown not only on PCSC errors, but also on internal module errors.
In this case also the error messages of `CardException` are not really helpful. (`CardException: list() failed`)
The suggestion to extend the constructor sounds reasonable for me.

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

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

From weijun at openjdk.org  Thu Nov 17 23:52:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Nov 2022 23:52:02 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v6]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <ZGRIo_UiX9-dNgwLgQVF-vmBMPzDlHDXFdo7z05M8Kg=.e89c92b2-18f9-491b-98b9-93733152241c@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/2d944433..509ce1c6

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

  Stats: 140 lines in 1 file changed: 140 ins; 0 del; 0 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  Fri Nov 18 01:18:20 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 01:18:20 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v3]
In-Reply-To: <bacpntJps9H0dm-CXgQpQX8RzmqR4a087V2LBdeXYRM=.c3ebcc08-387a-4881-a35a-74aefe7d9c32@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
 <m3iytCck8_0wVvjqOy8oLGGfLk7-is0RbcPlB_5MDTo=.78124cd2-ce48-44c5-9951-d599aaa895e3@github.com>
 <bacpntJps9H0dm-CXgQpQX8RzmqR4a087V2LBdeXYRM=.c3ebcc08-387a-4881-a35a-74aefe7d9c32@github.com>
Message-ID: <H4X5cjSK3oiz1rRxEVAQ-7gwWLBMRR1GKXiO9inyiTg=.a763e9b5-c99c-42bf-b882-f9eb86f12a34@github.com>

On Thu, 17 Nov 2022 21:20:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Wondering why you named the methods "signNew" instead of just "sign" which seems simpler to me.
> Otherwise looks fine.

I just want to emphasize that a new object is created. If we can use "new" as a verb, maybe "newSigned" is better. I can revert to "sign" if you think they sound weird.

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

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

From mullan at openjdk.org  Fri Nov 18 01:33:19 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Nov 2022 01:33:19 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v3]
In-Reply-To: <m3iytCck8_0wVvjqOy8oLGGfLk7-is0RbcPlB_5MDTo=.78124cd2-ce48-44c5-9951-d599aaa895e3@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
 <m3iytCck8_0wVvjqOy8oLGGfLk7-is0RbcPlB_5MDTo=.78124cd2-ce48-44c5-9951-d599aaa895e3@github.com>
Message-ID: <jYf6cHgBT7XUbCR2XzLa4K5jyXZpXhLBYUM7aW-77wo=.609ff516-803d-4c21-99ff-051faa2c9ec9@github.com>

On Wed, 16 Nov 2022 13:21:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
>> 
>> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one extra space

Not worth spending too many cycles because it is internal code. Maybe `newSignedCert`. I'm ok with whatever you decide.

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

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

From weijun at openjdk.org  Fri Nov 18 01:47:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 01:47:12 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v4]
In-Reply-To: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
Message-ID: <xuUloTAlFaajHIDpkn2xRjzgRBnHYp73LgDujaOoJhE=.d9ce30ec-d3fc-446f-a0fb-6568262a2037@github.com>

> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
> 
> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.

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

  rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11151/files
  - new: https://git.openjdk.org/jdk/pull/11151/files/056daf5c..23acf1b8

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

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

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

From weijun at openjdk.org  Fri Nov 18 01:47:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 01:47:12 GMT
Subject: RFR: 8296901: Do not create unsigned certificate and CRL [v4]
In-Reply-To: <xuUloTAlFaajHIDpkn2xRjzgRBnHYp73LgDujaOoJhE=.d9ce30ec-d3fc-446f-a0fb-6568262a2037@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
 <xuUloTAlFaajHIDpkn2xRjzgRBnHYp73LgDujaOoJhE=.d9ce30ec-d3fc-446f-a0fb-6568262a2037@github.com>
Message-ID: <lxX94QG-5sax-jW_je2y1Ts-yglLNp9G-EzTRWlrqKw=.adc9c47f-1d09-4c97-8efe-4716535a1385@github.com>

On Fri, 18 Nov 2022 01:43:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
>> 
>> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

I chose `newSigned`. Same method name for both certificate and CRL.

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

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

From weijun at openjdk.org  Fri Nov 18 01:52:33 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 01:52:33 GMT
Subject: RFR: 8296399: crlNumExtVal might be null inside
 X509CRLSelector::match [v2]
In-Reply-To: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>
References: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>
Message-ID: <69JnNn7_VOQ7HntnCp3NTpCsinG04j3DwBdcIGAPxq8=.c23194da-9a5d-41a8-a838-bc243b2e79a1@github.com>

> When `X509CRLSelector ` requires a CRL number extension but a CRL does not have it, the CRL should not be selected.
> 
> Note: the test uses a new internal API introduced in https://github.com/openjdk/jdk/pull/11151.

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

  rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11215/files
  - new: https://git.openjdk.org/jdk/pull/11215/files/61c374ad..8ecde98b

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

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

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

From weijun at openjdk.org  Fri Nov 18 02:25:09 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 02:25:09 GMT
Subject: Integrated: 8296901: Do not create unsigned certificate and CRL
In-Reply-To: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
References: <AGNzAjCbIP11x3pKn5_T2sqlQFsBYEgA86FwFBYSzT4=.63f0e5e0-4a1c-4206-b7f4-ef8610fd57f0@github.com>
Message-ID: <5ngEWhW8MKkxdGBHlrMZjMH_1j3q5DEaXjq5LC6YdXc=.07282b69-d784-49fe-815f-c47fdfa94f0f@github.com>

On Tue, 15 Nov 2022 00:35:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo` inside, a new static method `signNew` is introduced to create a newly signed certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure an `X509CertImpl` is always signed and there is no read to keep its `readOnly` flag.
> 
> The same for `X509CRLImpl`. A new inner class `TBSCertList` is added which is equivalent to `X509CertInfo` inside `X509CertImpl`.

This pull request has now been integrated.

Changeset: ab6b7ef9
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab6b7ef98800bee5e87e39a616af642874eb154a
Stats:     708 lines in 11 files changed: 294 ins; 313 del; 101 mod

8296901: Do not create unsigned certificate and CRL

Reviewed-by: mullan

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

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

From dholmes at openjdk.org  Fri Nov 18 02:35:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Nov 2022 02:35:11 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Hi @jonathan-gibbons ,

I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly?

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

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

From xuelei at openjdk.org  Fri Nov 18 03:27:20 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 03:27:20 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <MhOjIIg9TntJoNUHWK54oNmv6Eslhn1mz5nSOusdh80=.828ae267-6650-411e-b77f-8585026a84bf@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <MhOjIIg9TntJoNUHWK54oNmv6Eslhn1mz5nSOusdh80=.828ae267-6650-411e-b77f-8585026a84bf@github.com>
Message-ID: <wg2w74XFXgR8uqgc9k-Khx0TyDatrTePl7lT-HDADDo=.5974d00c-95bc-4b42-a8e8-42631ce37026@github.com>

On Thu, 17 Nov 2022 23:07:46 GMT, Johannes Waigel <duke at openjdk.org> wrote:

> Checking the instance is fundamental to find out the real cause.

Please don't do that in a serious application.  The exception stack is belong to implementation details, and may change any time.

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

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

From xuelei at openjdk.org  Fri Nov 18 03:33:55 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 03:33:55 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <4fokOYO4wwbHMmYSY5wt0R8odLPAQOkAdxdOAxiBx0Y=.321d8ea9-bd6d-46b7-93bb-38bab9822aa3@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
 <4fokOYO4wwbHMmYSY5wt0R8odLPAQOkAdxdOAxiBx0Y=.321d8ea9-bd6d-46b7-93bb-38bab9822aa3@github.com>
Message-ID: <GKtF5oz27adwy8pK8LzQMN7ENZ-nUjgMbn7J9tM2YdI=.c37f3489-a03c-4c07-8126-1648d497c94c@github.com>

On Thu, 17 Nov 2022 16:23:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> If "DSA" and "DH" can be grouped inside a single class, is it also possible to group "RSA" and "RSASSA-PSS", and "XDH" and "EdDSA"?

The sub-class name appears in the he benchmark result (See `EC` in `KeyPairGeneratorBench.EC.generateKeyPair`). Combining different types of algorithms may be not as clear as using separately sub-class names.

`o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair EC 521 thrpt 40 364.970 ? 5.556 ops/s
`

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

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

From xuelei at openjdk.org  Fri Nov 18 03:39:18 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 03:39:18 GMT
Subject: RFR: 8296399: crlNumExtVal might be null inside
 X509CRLSelector::match [v2]
In-Reply-To: <69JnNn7_VOQ7HntnCp3NTpCsinG04j3DwBdcIGAPxq8=.c23194da-9a5d-41a8-a838-bc243b2e79a1@github.com>
References: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>
 <69JnNn7_VOQ7HntnCp3NTpCsinG04j3DwBdcIGAPxq8=.c23194da-9a5d-41a8-a838-bc243b2e79a1@github.com>
Message-ID: <nSC3FbRUHjz7z4morB1Uzs-S3enWtQqXnw4MfQgH4wI=.6c1ac734-64d9-4ae1-bb7f-dec5e89cb131@github.com>

On Fri, 18 Nov 2022 01:52:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When `X509CRLSelector ` requires a CRL number extension but a CRL does not have it, the CRL should not be selected.
>> 
>> Note: the test uses a new internal API introduced in https://github.com/openjdk/jdk/pull/11151.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

I guess the compatibility impact is low?

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

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

From duke at openjdk.org  Fri Nov 18 03:57:32 2022
From: duke at openjdk.org (pandaapo)
Date: Fri, 18 Nov 2022 03:57:32 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v2]
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

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

 - Remove some unused methods and refactor some reldated codes.
 - Merge branch 'master' into master-JDK-8296734
 - Make signerToCodeSource cache work.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11072/files
  - new: https://git.openjdk.org/jdk/pull/11072/files/59d5c534..b3dbd279

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

  Stats: 27017 lines in 785 files changed: 9648 ins; 14794 del; 2575 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 ascarpino at openjdk.org  Fri Nov 18 04:59:00 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 18 Nov 2022 04:59:00 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
Message-ID: <A_1yDk1TqB6Kqml1nPgzHOv2cQpL5dove9I3y_zCAvM=.aeea8cad-d9f5-4761-a4ae-95f6b35336a3@github.com>

On Wed, 16 Nov 2022 17:38:19 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 764:
> 
>> 762:                 byte[] array;
>> 763:                 if (encryption) {
>> 764:                     array = dst.array();
> 
> You could factor out lines 764 and 770 by changing line 762 to
> `byte[] array = encryption ? dst.array() : src.array();`

That was intentional since 763 checks the encryption boolean, I can define 'array' in that condition instead of having two conditions for the same thing

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

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

From ascarpino at openjdk.org  Fri Nov 18 05:22:30 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 18 Nov 2022 05:22:30 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
Message-ID: <RRDZOxcaPOXvAhu9EVFLNStkjA4JZoZfJcZ96oehdUs=.54166783-3808-4b98-9b70-24d71c3de323@github.com>

On Wed, 16 Nov 2022 16:57:14 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 592:
> 
>> 590: 
>> 591:         int len = 0;
>> 592:         // Loop if input length is greater than the SPLIT_LEN
> 
> comment doesn't add anything not already obvious from the code

yeah.. probably right

> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 694:
> 
>> 692:         int originalOutOfs = 0;
>> 693: 
>> 694:         // True if op is in-place array decryption with the input & output
> 
> // Setting `inPlaceArray` to true turns off combined intrinsic processing.

yeah that's better

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

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

From weijun at openjdk.org  Fri Nov 18 12:37:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 12:37:22 GMT
Subject: RFR: 8296399: crlNumExtVal might be null inside
 X509CRLSelector::match [v2]
In-Reply-To: <nSC3FbRUHjz7z4morB1Uzs-S3enWtQqXnw4MfQgH4wI=.6c1ac734-64d9-4ae1-bb7f-dec5e89cb131@github.com>
References: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>
 <69JnNn7_VOQ7HntnCp3NTpCsinG04j3DwBdcIGAPxq8=.c23194da-9a5d-41a8-a838-bc243b2e79a1@github.com>
 <nSC3FbRUHjz7z4morB1Uzs-S3enWtQqXnw4MfQgH4wI=.6c1ac734-64d9-4ae1-bb7f-dec5e89cb131@github.com>
Message-ID: <VoSSEH4_DtHOVeQmh_oOoxAZAo-uh-086BXjBRoWkZY=.339b80b9-757b-4fa6-a50b-d45ce1adfaff@github.com>

On Fri, 18 Nov 2022 03:37:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> I guess the compatibility impact is low?

Without the fix, an NPE will be thrown.

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

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

From duke at openjdk.org  Fri Nov 18 13:09:24 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Fri, 18 Nov 2022 13:09:24 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <FfVUYgwI3-HDqr0WnmxhStKIJvoVZ70fp7FcnoE-bkM=.ed69e593-623d-4ad3-aaa8-b7a732cffe41@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
 <FfVUYgwI3-HDqr0WnmxhStKIJvoVZ70fp7FcnoE-bkM=.ed69e593-623d-4ad3-aaa8-b7a732cffe41@github.com>
Message-ID: <v__R-7DqHYZExc-3k6wKS0dXDyDNP_eL6SLV4AabyNQ=.da7d17bf-46b4-4c03-9ee4-e002ec508efb@github.com>

On Tue, 8 Nov 2022 16:41:07 GMT, Xue-Lei Andrew Fan <xuelei 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
>
> 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?

@XueleiFan I have removed the Test and related policy files
(Comparator.Combined.Policy/ Comparator.Comparator.Policy/Comparator.Principal.Policy), is this what you were expecting? I can confirm I am still getting a successful test run.

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

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

From weijun at openjdk.org  Fri Nov 18 15:41:18 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 15:41:18 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v2]
In-Reply-To: <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>
Message-ID: <CaWACcqNddwEiRVr3YJZCaEph42jzjsLh_uOh04J7LQ=.4273912b-1522-4322-b068-2f97162367fe@github.com>

On Fri, 18 Nov 2022 03:57:32 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo 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:
> 
>  - Remove some unused methods and refactor some reldated codes.
>  - Merge branch 'master' into master-JDK-8296734
>  - Make signerToCodeSource cache work.

src/java.base/share/classes/jdk/internal/access/JavaUtilJarAccess.java line 40:

> 38: public interface JavaUtilJarAccess {
> 39:     public boolean jarFileHasClassPathAttribute(JarFile jar) throws IOException;
> 40:     public Enumeration<JarEntry> entries2(JarFile jar);

I think `entries2` and `getManifestDigests` are also useless now.

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

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

From weijun at openjdk.org  Fri Nov 18 15:47:09 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 15:47:09 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v2]
In-Reply-To: <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>
Message-ID: <b2VFZUxCFvxe528eC5YzqPdnZl9fSrr2ssLBWgjvMUw=.18382dba-55fe-417c-9ced-f5b31b35549f@github.com>

On Fri, 18 Nov 2022 03:57:32 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo 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:
> 
>  - Remove some unused methods and refactor some reldated codes.
>  - Merge branch 'master' into master-JDK-8296734
>  - Make signerToCodeSource cache work.

src/java.base/share/classes/java/util/jar/JarVerifier.java line 340:

> 338:     public java.security.cert.Certificate[] getCerts(String name)
> 339:     {
> 340:         return mapSignersToCertArray(getCodeSigners(name));

This `getCerts(String)` method seems useless as well.

src/java.base/share/classes/java/util/jar/JarVerifier.java line 343:

> 341:     }
> 342: 
> 343:     public java.security.cert.Certificate[] getCerts(JarEntry entry)

I would suggest changing the `import java.security.*` at the beginning to individual imports with class names. And then you can `import java.security.cert.Certificate` and there is no need to write this long class name. The long name also appears in other places in this file.

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

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

From weijun at openjdk.org  Fri Nov 18 15:50:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 15:50:37 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v2]
In-Reply-To: <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>
Message-ID: <I6X0kvb4UfImsaaU9E9pMkHb5eiVY_qJtmpFrBdfeBE=.4cd6d01d-5ae0-4b3e-96ca-5a47d39ddd59@github.com>

On Fri, 18 Nov 2022 03:57:32 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo 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:
> 
>  - Remove some unused methods and refactor some reldated codes.
>  - Merge branch 'master' into master-JDK-8296734
>  - Make signerToCodeSource cache work.

src/java.base/share/classes/java/util/jar/JavaUtilJarAccessImpl.java line 43:

> 41:     }
> 42: 
> 43:     public CodeSource[] getCodeSources(JarFile jar, URL url) {

After you remove these methods, some imports at the beginning can also be removed.

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

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

From weijun at openjdk.org  Fri Nov 18 16:06:24 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 18 Nov 2022 16:06:24 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
Message-ID: <6Id3zUV7JWzIzDVDOzO0WU8lX1q6jhC1Hfd3FltRVKk=.492835a0-f854-4193-bd00-6f800c1af392@github.com>

On Sun, 13 Nov 2022 19:58:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> In the current key pair generation micro-benchmark, there is no cases for `EdDSA`, `XDH`, and `RSASSA-PSS`.  This PR is trying to add these algorithms.
> 
> BTW, here is the benchmarking data on a Linux x86_64 platform.  You can see how much the performance difference could be among key pair generation algorithms.
> 
> 
> Benchmark                                                         (algorithm)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          256              thrpt   40  1647.342 ?  8.548  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          384              thrpt   40   698.990 ?  5.647  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          521              thrpt   40   364.970 ?  5.556  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          255              thrpt   40  2400.202 ? 17.685  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          448              thrpt   40   680.304 ?  5.923  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         1024              thrpt   40    69.614 ?  1.907  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         2048              thrpt   40     9.192 ?  0.567  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         3072              thrpt   40     2.352 ?  0.385  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         4096              thrpt   40     0.815 ?  0.221  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         1024              thrpt   40    70.022 ?  2.336  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         2048              thrpt   40     9.260 ?  0.730  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         3072              thrpt   40     2.305 ?  0.369  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         4096              thrpt   40     0.902 ?  0.194  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          255              thrpt   40  5061.279 ? 33.878  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          448              thrpt   40  1404.786 ? 11.083  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         1024              thrpt   40  9486.010 ? 20.242  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         2048              thrpt   40  2174.506 ?  2.514  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         1024              thrpt   40  3532.067 ?  7.882  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         2048              thrpt   40   523.746 ?  0.704  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     DSA         2048              thrpt   40  2171.807 ?  3.505  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     RSA         2048              thrpt   40     9.549 ?  0.809  ops/s
> 
> 
> 
> Thanks,
> Xuelei

Sure, you can choose your style. It's just that the original test was able to use multiple algorithm names in a single class but your enhancement abandoned this feature.

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

Marked as reviewed by weijun (Reviewer).

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

From mullan at openjdk.org  Fri Nov 18 16:43:27 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Nov 2022 16:43:27 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: <GChc6AxKYcaCuIw26YPdh4Lhv_SqcwLX8rI3WL9f3Ng=.df2a816e-519c-401e-8324-ae1f9b48dcce@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.

I'm ok with this now, but please check with other reviewers to make sure their comments have been addressed.

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

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

From djelinski at openjdk.org  Fri Nov 18 17:03:28 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 18 Nov 2022 17:03:28 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v5]
In-Reply-To: <izZBwGm2sxd1IrWBYYRAEhutZ0P8CaS39i8MplqstiQ=.fab07331-87a9-4f13-a406-93d3be844fa5@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <izZBwGm2sxd1IrWBYYRAEhutZ0P8CaS39i8MplqstiQ=.fab07331-87a9-4f13-a406-93d3be844fa5@github.com>
Message-ID: <R0QKRmNjmY-5hVlIGsvaD1vZlwD98pBvQIn24qQEPt0=.caf35eef-1587-48ee-b350-a97ad8303536@github.com>

On Thu, 3 Nov 2022 18:18:42 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:
> 
>   wordsmithing

Marked as reviewed by djelinski (Committer).

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

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

From xuelei at openjdk.org  Fri Nov 18 17:38:00 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 17:38:00 GMT
Subject: RFR: 8296399: crlNumExtVal might be null inside
 X509CRLSelector::match [v2]
In-Reply-To: <69JnNn7_VOQ7HntnCp3NTpCsinG04j3DwBdcIGAPxq8=.c23194da-9a5d-41a8-a838-bc243b2e79a1@github.com>
References: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>
 <69JnNn7_VOQ7HntnCp3NTpCsinG04j3DwBdcIGAPxq8=.c23194da-9a5d-41a8-a838-bc243b2e79a1@github.com>
Message-ID: <vpg0uNhmcKWWKH8PQHPxG1rN2INIXXgoBRoqjN5zk48=.2e1badcb-4b35-4253-8de6-05a5d38945c8@github.com>

On Fri, 18 Nov 2022 01:52:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When `X509CRLSelector ` requires a CRL number extension but a CRL does not have it, the CRL should not be selected.
>> 
>> Note: the test uses a new internal API introduced in https://github.com/openjdk/jdk/pull/11151.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

Looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From xuelei at openjdk.org  Fri Nov 18 17:46:04 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 17:46:04 GMT
Subject: RFR: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <6Id3zUV7JWzIzDVDOzO0WU8lX1q6jhC1Hfd3FltRVKk=.492835a0-f854-4193-bd00-6f800c1af392@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
 <6Id3zUV7JWzIzDVDOzO0WU8lX1q6jhC1Hfd3FltRVKk=.492835a0-f854-4193-bd00-6f800c1af392@github.com>
Message-ID: <yY4hqSmueuHROC1FdoMKEIZhRP01_2UhAbVpMVaBJv0=.b3562498-60bc-41c6-a30d-f5e26c98e2f4@github.com>

On Fri, 18 Nov 2022 16:02:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Sure, you can choose your style. It's just that the original test was able to use multiple algorithm names in a single class but your enhancement abandoned this feature.

Did you refer to other bench case, like Signatures.java where  I used a single class?  For this one, the original test used sub-classes and I just add more sub-classes for new cases.

Thank you for the review.  I'm going to integrate it.

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

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

From xuelei at openjdk.org  Fri Nov 18 17:46:42 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 17:46:42 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: <GVhp9uZ3Z1sdMJS3aGbQeSqxzeSeMZnScecVa9GeVAQ=.73e992fe-41e0-4a30-b78c-8230c985dea0@github.com>

On Thu, 3 Nov 2022 16:51:47 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:
>> 
>>   typo correction
>
> Is this improvement also derived from the paper by Renes, Costello, and Batina?

@mcpowers @ferakocz Did you have further comments, or more time for the review?

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

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

From xuelei at openjdk.org  Fri Nov 18 17:47:26 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 17:47:26 GMT
Subject: Integrated: 8296910: Add EdDSA/XDH/RSASSA-PSS to
 KeyPairGeneratorBench.java
In-Reply-To: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
References: <bTBJrr2W_qGh9nvjS44ZGY1DdRx6SEH7KN6sTKCpM44=.ed2bf839-0fda-4861-8355-24be5fddc68f@github.com>
Message-ID: <rS5H0dkrUJ1UK530GW7f0Pl2UKBO0SeUhRpWNEuhklU=.d30d8dcd-2117-486f-b24b-5627a6b3d8e7@github.com>

On Sun, 13 Nov 2022 19:58:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> In the current key pair generation micro-benchmark, there is no cases for `EdDSA`, `XDH`, and `RSASSA-PSS`.  This PR is trying to add these algorithms.
> 
> BTW, here is the benchmarking data on a Linux x86_64 platform.  You can see how much the performance difference could be among key pair generation algorithms.
> 
> 
> Benchmark                                                         (algorithm)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          256              thrpt   40  1647.342 ?  8.548  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          384              thrpt   40   698.990 ?  5.647  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EC.generateKeyPair                    EC          521              thrpt   40   364.970 ?  5.556  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          255              thrpt   40  2400.202 ? 17.685  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.EdDSA.generateKeyPair              EdDSA          448              thrpt   40   680.304 ?  5.923  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         1024              thrpt   40    69.614 ?  1.907  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         2048              thrpt   40     9.192 ?  0.567  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         3072              thrpt   40     2.352 ?  0.385  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSA.generateKeyPair                  RSA         4096              thrpt   40     0.815 ?  0.221  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         1024              thrpt   40    70.022 ?  2.336  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         2048              thrpt   40     9.260 ?  0.730  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         3072              thrpt   40     2.305 ?  0.369  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.RSASSAPSS.generateKeyPair     RSASSA-PSS         4096              thrpt   40     0.902 ?  0.194  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          255              thrpt   40  5061.279 ? 33.878  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.XDH.generateKeyPair                  XDH          448              thrpt   40  1404.786 ? 11.083  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         1024              thrpt   40  9486.010 ? 20.242  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair                      DSA         2048              thrpt   40  2174.506 ?  2.514  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         1024              thrpt   40  3532.067 ?  7.882  ops/s
> o.o.b.j.c.full.KeyPairGeneratorBench.generateKeyPair            DiffieHellman         2048              thrpt   40   523.746 ?  0.704  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     DSA         2048              thrpt   40  2171.807 ?  3.505  ops/s
> o.o.b.j.c.small.KeyPairGeneratorBench.generateKeyPair                     RSA         2048              thrpt   40     9.549 ?  0.809  ops/s
> 
> 
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

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

8296910: Add EdDSA/XDH/RSASSA-PSS to KeyPairGeneratorBench.java

Reviewed-by: weijun

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

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

From xuelei at openjdk.org  Fri Nov 18 17:53:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 17:53:19 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <v__R-7DqHYZExc-3k6wKS0dXDyDNP_eL6SLV4AabyNQ=.da7d17bf-46b4-4c03-9ee4-e002ec508efb@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
 <FfVUYgwI3-HDqr0WnmxhStKIJvoVZ70fp7FcnoE-bkM=.ed69e593-623d-4ad3-aaa8-b7a732cffe41@github.com>
 <v__R-7DqHYZExc-3k6wKS0dXDyDNP_eL6SLV4AabyNQ=.da7d17bf-46b4-4c03-9ee4-e002ec508efb@github.com>
Message-ID: <cKc1kbQujBAsGtrdpZFqDRm9zDgTvG4Q7txUJeZFUPE=.48e6c3c6-5259-450e-80fa-3fb0f2851137@github.com>

On Fri, 18 Nov 2022 13:07:06 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> 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?
>
> @XueleiFan I have removed the Test and related policy files
> (Comparator.Combined.Policy/ Comparator.Comparator.Policy/Comparator.Principal.Policy), is this what you were expecting? I can confirm I am still getting a successful test run.

I meant to remove the Comparator.java.   As SubjectCodeSource has been removed, the note you added may be confusing for future readers.  If you want to have a record, you could use bug comment in JDK-8294526.

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

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

From xuelei at openjdk.org  Fri Nov 18 17:56:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 18 Nov 2022 17:56:27 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v6]
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <lh7be1odp-vRlI1pMhkna_6MH_GI4M_vnVTq9Pk5xa8=.befa8999-a174-4cc0-b3a5-40a3105bd0c3@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
> 
> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
> 
> ## SSLHandshake.java benchmark
> ### Use secp256r1 as the named group
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
> 
> ### Use default TLS named groups
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
> 
> ## KeyPairGenerators.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
> 
> 
> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
> 
> ## Signatures.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
> 
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
> 
> 
> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

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

  remove duplicated bench cases

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

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

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

  Stats: 167 lines in 2 files changed: 0 ins; 167 del; 0 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 jjg at openjdk.org  Fri Nov 18 18:56:31 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 18 Nov 2022 18:56:31 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
 <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>
Message-ID: <l58Z_Qi8-iqqqDhcbhgRgqetaiapUzMdHPPpqMgXzPY=.83952a70-fb4a-43e0-8d1b-4ec22689e398@github.com>

On Fri, 18 Nov 2022 02:31:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi @jonathan-gibbons ,
> 
> I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly?

Yes, at least in all the files I verified and I have no reason to believe it might be different in any other files.

On a Mac, you can just do `man <path-to-file>` to render the contents of a troff file. That is how I checked the files that I did.

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

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

From duke at openjdk.org  Fri Nov 18 19:13:49 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 18 Nov 2022 19:13:49 GMT
Subject: RFR: 8295011: EC point multiplication improvement for secp256r1
 [v6]
In-Reply-To: <lh7be1odp-vRlI1pMhkna_6MH_GI4M_vnVTq9Pk5xa8=.befa8999-a174-4cc0-b3a5-40a3105bd0c3@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
 <lh7be1odp-vRlI1pMhkna_6MH_GI4M_vnVTq9Pk5xa8=.befa8999-a174-4cc0-b3a5-40a3105bd0c3@github.com>
Message-ID: <2l0csdzYJaiMQ89IB7MExtVJ6CDPHvEFlt4zncTnYIk=.9c7170db-fe2b-4694-bb96-d8d4832914ef@github.com>

On Fri, 18 Nov 2022 17:56:27 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 duplicated bench cases

No more comments..

Ferenc

From: Xuelei Fan ***@***.***>
Date: Friday, 2022. November 18. 18:44
To: openjdk/jdk ***@***.***>
Cc: Ferenc Rakoczi ***@***.***>, Mention ***@***.***>
Subject: [External] : Re: [openjdk/jdk] 8295011: EC point multiplication improvement for secp256r1 (PR #10893)

@mcpowers<https://urldefense.com/v3/__https:/github.com/mcpowers__;!!ACWV5N9M2RV99hQ!KZ5It1T7Uh_FAeR6mCOcpO2b7Wya2RwFpyueKkHY2qpqSAtkxJGKEFUdX8hS-EFembHvuQNB55txyOzMg_MkFzwj7j4Y8Q$> @ferakocz<https://urldefense.com/v3/__https:/github.com/ferakocz__;!!ACWV5N9M2RV99hQ!KZ5It1T7Uh_FAeR6mCOcpO2b7Wya2RwFpyueKkHY2qpqSAtkxJGKEFUdX8hS-EFembHvuQNB55txyOzMg_MkFzyWE8qvSw$> Did you have further comments, or more time for the review?

?
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/10893*issuecomment-1320335607__;Iw!!ACWV5N9M2RV99hQ!KZ5It1T7Uh_FAeR6mCOcpO2b7Wya2RwFpyueKkHY2qpqSAtkxJGKEFUdX8hS-EFembHvuQNB55txyOzMg_MkFzyVVnYDCg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AY5ZNSDCVZ7LQBNUP2NOKOLWI657ZANCNFSM6AAAAAARQQAIO4__;!!ACWV5N9M2RV99hQ!KZ5It1T7Uh_FAeR6mCOcpO2b7Wya2RwFpyueKkHY2qpqSAtkxJGKEFUdX8hS-EFembHvuQNB55txyOzMg_MkFzxBmKn8ZQ$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>

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

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

From mullan at openjdk.org  Fri Nov 18 22:52:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Nov 2022 22:52:29 GMT
Subject: RFR: 8286575: Document how properties in java.security are parsed
In-Reply-To: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
References: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
Message-ID: <oCTGCyTu-RsVLidVpNRnTf6PjBTJtaPm0nNLTZOCv-o=.69bded1a-e3bf-4a62-b562-86086573fd0a@github.com>

On Thu, 17 Nov 2022 12:26:18 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> A doc edit to indicate that modifications of values in java.security conf file would require a JVM restart in order for such changes to be detected.

src/java.base/share/conf/security/java.security line 29:

> 27: # an unspecified error when initializing the java.security.Security class.
> 28: # Properties in this file are typically parsed only once. Any modification
> 29: # would require an application restart to reflect changes.

Maybe change the second sentence to "If any of the properties are modified, applications should be restarted to ensure the changes are properly reflected."

This makes it more consistent with the words in the first sentence.

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

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

From duke at openjdk.org  Sat Nov 19 03:42:35 2022
From: duke at openjdk.org (pandaapo)
Date: Sat, 19 Nov 2022 03:42:35 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v3]
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <3crch5fupeKeWgTykHJX-VQKQh1k9cBrJS_s-JpS1Do=.c097be2e-f4c7-417c-accc-71ce2f260ed1@github.com>

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

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

  Modify as reviews.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11072/files
  - new: https://git.openjdk.org/jdk/pull/11072/files/b3dbd279..ef4ba3df

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

  Stats: 45 lines in 4 files changed: 2 ins; 34 del; 9 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 duke at openjdk.org  Sat Nov 19 03:42:37 2022
From: duke at openjdk.org (pandaapo)
Date: Sat, 19 Nov 2022 03:42:37 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v2]
In-Reply-To: <CaWACcqNddwEiRVr3YJZCaEph42jzjsLh_uOh04J7LQ=.4273912b-1522-4322-b068-2f97162367fe@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <PdbaUX4w5ZUf5lbETFakAOi-1EMhXoxNWKD34Ov3PbQ=.68c0718f-6882-453a-bf8d-702fb8f04e0d@github.com>
 <CaWACcqNddwEiRVr3YJZCaEph42jzjsLh_uOh04J7LQ=.4273912b-1522-4322-b068-2f97162367fe@github.com>
Message-ID: <RKSQwFeXVVPktAon254V-9pDLy8wXZFV9chH7uKcA4c=.ca789db9-1fd3-488b-88ec-0f3bbca5f5ea@github.com>

On Fri, 18 Nov 2022 15:38:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> pandaapo 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:
>> 
>>  - Remove some unused methods and refactor some reldated codes.
>>  - Merge branch 'master' into master-JDK-8296734
>>  - Make signerToCodeSource cache work.
>
> src/java.base/share/classes/jdk/internal/access/JavaUtilJarAccess.java line 40:
> 
>> 38: public interface JavaUtilJarAccess {
>> 39:     public boolean jarFileHasClassPathAttribute(JarFile jar) throws IOException;
>> 40:     public Enumeration<JarEntry> entries2(JarFile jar);
> 
> I think `entries2` and `getManifestDigests` are also useless now.

OK. Thanks.

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

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

From duke at openjdk.org  Sat Nov 19 04:31:13 2022
From: duke at openjdk.org (pandaapo)
Date: Sat, 19 Nov 2022 04:31:13 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v4]
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

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

  Modify as reviews.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11072/files
  - new: https://git.openjdk.org/jdk/pull/11072/files/ef4ba3df..c4cfb499

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 xuelei at openjdk.org  Sat Nov 19 07:17:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 19 Nov 2022 07:17:19 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be reduced if required in EC limbs operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs if required for EC limbs operations.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1417.507 ?  5.809  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1412.620 ?  7.040  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1417.364 ?  6.643  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1364.720 ? 44.354  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   609.924 ?  9.858  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   610.873 ?  5.519  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   608.573 ? 13.324  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   597.802 ?  7.074  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   301.954 ?  6.449  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   300.774 ?  5.849  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   295.831 ?  8.423  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   276.258 ? 43.146  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1171.878 ?  4.187  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1175.175 ?  4.611  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1168.459 ?  5.750  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1086.906 ?  6.514  ops/s
> Signatures.sign        Ed448               64  thrpt   15   326.475 ?  3.274  ops/s
> Signatures.sign        Ed448              512  thrpt   15   328.709 ?  3.867  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   315.480 ? 15.377  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   312.388 ?  1.067  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1377.447 ? 38.889  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1403.149 ?  5.151  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1401.101 ?  6.937  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1381.855 ? 10.606  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   595.979 ?  1.967  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   592.419 ?  6.087  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   581.800 ? 18.815  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   583.224 ?  9.856  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   264.772 ? 36.883  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   302.084 ?  1.074  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   296.619 ?  3.272  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   290.112 ?  5.085  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1163.293 ?  4.266  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1157.093 ?  8.145  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1140.900 ?  8.660  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1053.233 ? 40.591  ops/s
> Signatures.sign        Ed448               64  thrpt   15   317.509 ?  6.870  ops/s
> Signatures.sign        Ed448              512  thrpt   15   320.975 ?  1.534  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   322.157 ?  1.914  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   303.532 ?  6.419  ops/s
> 
> 
> From the numbers, it looks like the performance impact is limited.  Based on this update, the performance could get rewarded by using less limbs.  For examples if using less limbs for secp256r1/secp384r1/secp521r1/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 incrementally with one additional commit since the last revision:

  remove duplicated bench test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10624/files
  - new: https://git.openjdk.org/jdk/pull/10624/files/c78b382e..5b6dfa9f

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

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

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

From xuelei at openjdk.org  Sat Nov 19 07:21:54 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 19 Nov 2022 07:21:54 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation [v2]
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <mhD36uS2mpq6TBlwzpUiRm4nxl_0f4pTlNpCmGzWRFs=.449d60cb-bc97-4f7b-b1e2-892ebbcde33d@github.com>

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

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

  remove duplicated bench tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10398/files
  - new: https://git.openjdk.org/jdk/pull/10398/files/a5e0f775..9b724e93

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

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

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

From weijun at openjdk.org  Sat Nov 19 22:57:50 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 19 Nov 2022 22:57:50 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v4]
In-Reply-To: <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>
Message-ID: <uBS1_-7F3L7-EVJwjPAILHF4SHqH5tLQxsvQAOtMaJU=.2b571483-bdee-46f6-ad81-616da44929c2@github.com>

On Sat, 19 Nov 2022 04:31:13 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify as reviews.

Great to see more lines removed. Since `entries2` in `JavaUtilJarAccess` is removed, I assume the `entries2` in `JarFile` is also useless, and there are 2 `newEntry` methods who claims to be invoked by `entries2`. Also, in `JarVerifier`, it seems all lines after `// Extended JavaUtilJarAccess CodeSource API Support` before `isTrustedManifestEntry` are related to those removed methods.

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

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

From weijun at openjdk.org  Sat Nov 19 23:04:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 19 Nov 2022 23:04:12 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v4]
In-Reply-To: <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>
Message-ID: <2r_sJzA7aMXKj2VWtihrimlJwtloDKAZtBkKy0Jfss0=.eb6fa61c-421f-4261-a1f6-ab975da3d8b9@github.com>

On Sat, 19 Nov 2022 04:31:13 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify as reviews.

BTW, since this bug description is about a coding error but you fix is about cleanup, how about I file another bug and you use it in the title? I am trying to add a `noreg-cleanup` label to the bug and it does not apply to the jdk8u fix (suppose there will be one).

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

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

From duke at openjdk.org  Sat Nov 19 23:25:15 2022
From: duke at openjdk.org (pandaapo)
Date: Sat, 19 Nov 2022 23:25:15 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v4]
In-Reply-To: <2r_sJzA7aMXKj2VWtihrimlJwtloDKAZtBkKy0Jfss0=.eb6fa61c-421f-4261-a1f6-ab975da3d8b9@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>
 <2r_sJzA7aMXKj2VWtihrimlJwtloDKAZtBkKy0Jfss0=.eb6fa61c-421f-4261-a1f6-ab975da3d8b9@github.com>
Message-ID: <hiD0S4HxDC2Fdrs26KRS7-PKv0uyKEi516vq_cv1nsQ=.c89a363d-2fb3-4967-8957-8479975f6823@github.com>

On Sat, 19 Nov 2022 23:00:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> since this bug description is about a coding error but you fix is about cleanup, how about I file another bug and you use it in the title?

OK. Thanks.
>  I am trying to add a noreg-cleanup label to the bug and it does not apply to the jdk8u fix (suppose there will be one).

I had sent an email to [jdk8u-dev at openjdk.java.net](mailto:jdk8u-dev at openjdk.java.net) for asking which repository I can fork if I want to fix 8296734. And waiting for reply.

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

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

From weijun at openjdk.org  Sun Nov 20 01:31:25 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 20 Nov 2022 01:31:25 GMT
Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in
 map [v4]
In-Reply-To: <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <hYz4okfnJfDMz3Oos2euqwm1Z7LEeNiXwb_99Jb_2q0=.4f0afa9b-5c1f-4af8-9da9-2c79f0d28ca4@github.com>
Message-ID: <JbVz_btfg_jokjzsffFxa9A_uCUEJTfogvI5CK_rC9k=.999a4fa9-0fd5-4187-89f3-36d7bc687496@github.com>

On Sat, 19 Nov 2022 04:31:13 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify as reviews.

I just filed https://bugs.openjdk.org/browse/JDK-8297301.

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

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

From duke at openjdk.org  Sun Nov 20 06:27:32 2022
From: duke at openjdk.org (pandaapo)
Date: Sun, 20 Nov 2022 06:27:32 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v5]
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <5G907msMRcfWwG4y8u9u9wQq5oNGWuGFJGk7Bm46RN8=.a1c914ba-aaa0-46b3-b2dd-6b27aff4a389@github.com>

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

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

  Modify as reviews.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11072/files
  - new: https://git.openjdk.org/jdk/pull/11072/files/c4cfb499..a8fb419c

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

  Stats: 249 lines in 2 files changed: 0 ins; 249 del; 0 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 weijun at openjdk.org  Sun Nov 20 15:41:25 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 20 Nov 2022 15:41:25 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v5]
In-Reply-To: <5G907msMRcfWwG4y8u9u9wQq5oNGWuGFJGk7Bm46RN8=.a1c914ba-aaa0-46b3-b2dd-6b27aff4a389@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <5G907msMRcfWwG4y8u9u9wQq5oNGWuGFJGk7Bm46RN8=.a1c914ba-aaa0-46b3-b2dd-6b27aff4a389@github.com>
Message-ID: <i2e1jMJyA61KGsfmOZJxC-KbBIdF22Vg3Z-io5Ohk8o=.39b70d57-05dd-447b-b10f-45319bf283ab@github.com>

On Sun, 20 Nov 2022 06:27:32 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify as reviews.

`codomain`, `VerifierCodeSource`, `isSigningRelated`, and `getUnsignedCS` also used nowhere.

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

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

From duke at openjdk.org  Mon Nov 21 00:29:34 2022
From: duke at openjdk.org (pandaapo)
Date: Mon, 21 Nov 2022 00:29:34 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v6]
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <51Ppy4DuBRLKLVx791XoBw0QMuafO7TWBEDtfIMVU-g=.2daad272-8b8f-4f35-91d2-5337ea2fc74b@github.com>

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

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

  Modify as review and update copyright.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11072/files
  - new: https://git.openjdk.org/jdk/pull/11072/files/a8fb419c..fb933804

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

  Stats: 92 lines in 3 files changed: 0 ins; 90 del; 2 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 duke at openjdk.org  Mon Nov 21 00:32:26 2022
From: duke at openjdk.org (pandaapo)
Date: Mon, 21 Nov 2022 00:32:26 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v5]
In-Reply-To: <i2e1jMJyA61KGsfmOZJxC-KbBIdF22Vg3Z-io5Ohk8o=.39b70d57-05dd-447b-b10f-45319bf283ab@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <5G907msMRcfWwG4y8u9u9wQq5oNGWuGFJGk7Bm46RN8=.a1c914ba-aaa0-46b3-b2dd-6b27aff4a389@github.com>
 <i2e1jMJyA61KGsfmOZJxC-KbBIdF22Vg3Z-io5Ohk8o=.39b70d57-05dd-447b-b10f-45319bf283ab@github.com>
Message-ID: <uyaKrd8hkUZNCQkY-bmFD0a0KuAU5yuHFF81BIWUigM=.2aec19c4-c46f-4072-b9c9-b4aaf773f30c@github.com>

On Sun, 20 Nov 2022 15:37:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `codomain`, `VerifierCodeSource`, `isSigningRelated`, and `getUnsignedCS` also used nowhere.

Thanks. I think your `codomain` must mean `csdomain`.

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

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

From dholmes at openjdk.org  Mon Nov 21 01:35:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Nov 2022 01:35:20 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <RjHY72h2dKDge8MpnS7cKpLDKWBiwNVCBPYmd-uJfjY=.76af7ca7-77db-4d55-b097-d0641701aab8@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Looks okay.

Thanks for doing this before the end-of-release updates!

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

Marked as reviewed by dholmes (Reviewer).

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

From jwaters at openjdk.org  Mon Nov 21 02:45:19 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 21 Nov 2022 02:45:19 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
 <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
Message-ID: <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>

On Tue, 15 Nov 2022 06:33:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 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
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 50:
> 
>> 48: 
>> 49: #ifndef ATTRIBUTE_ALIGNED
>> 50: #define ATTRIBUTE_ALIGNED(x) alignas(x)
> 
> HotSpot Group has not discussed or approved use of `alignas` - see https://bugs.openjdk.org/browse/JDK-8250269.  This is another change that is independent of most of the rest of this PR, and should be dealt with separately.  The various MSVC-conditional direct uses of `_declspec(align(N))` should probably currently be using `ATTRIBUTE_ALIGNED`.

Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? I've read through 8250269 briefly and unlike the issues that come with C++ attributes, alignas looks relatively straightforward to switch to, without much effect on existing code. Seems like a bit of a waste to leave the JBS entry sitting on the shelf to me

> The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.

The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)

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

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

From jjiang at openjdk.org  Mon Nov 21 06:21:11 2022
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 21 Nov 2022 06:21:11 GMT
Subject: RFR: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
Message-ID: <PtlNtRUeZ2NdKzdbej6oDWurg6swQHbLqVvgSV_hkpk=.9026032e-b114-48b4-965d-95afda3e76a2@github.com>

On Tue, 20 Sep 2022 22:12:04 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> In the message digest implementation, for example SHA256, in JDK, two bitwise operations could be improved with equivalent arithmetic, and then the number bitwise operations could be reduced accordingly.  Specifically
> "(x and y) xor ((complement x) and z)" could be replaced with the equivalent "z xor (x and (y xor z))", and "(x and y) xor (x and z) xor (y and z)" could be replaced with the equivalent "(x and y) xor ((x xor y) and z)".  Each replacement reduces one bitwise operation, and thus improve the performance.
> 
> Per my testing on my MacOS laptop, the update on SHA256 improves the message digest throughput by 0.5%-0.8%.  The improvement is not significant, but might be worthy of it as the update is pretty simple and trivial, for those platforms that do not support CPU intrinsic for a certain hash algorithm.
> 
> This patch update SHA2 implementation only.  Please let me know what do you think.  If you are good  with this little bit performance, I will update more message digest implementations.  If no one interested in these little benefits, I will close this PR later.
> 
> Thanks,
> Xuelei

Marked as reviewed by jjiang (Reviewer).

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

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

From jnimeh at openjdk.org  Mon Nov 21 06:28:32 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 21 Nov 2022 06:28:32 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v4]
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <7dgYny7behfzrurUf7PH-jfhKYdDIMV4hInwIlZwg-Y=.9a97cf5b-fe58-4855-911b-43ec710c9539@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:

  Pull out common macro code into function parameter pack

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7702/files
  - new: https://git.openjdk.org/jdk/pull/7702/files/8d4b7ba7..0fd87c28

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

  Stats: 44 lines in 1 file changed: 23 ins; 17 del; 4 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 xuelei at openjdk.org  Mon Nov 21 06:38:36 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 21 Nov 2022 06:38:36 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: <7yv16ND_X74NRuQbKdOsiVu1RwY6ugNgXdlJQN7E01E=.60aa3666-6b8e-4d3a-b95f-8027fc8def7b@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.
>
>> > 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.

@seanjmullan Did you have cycle to review this PR and CSR?  This CSR is similar to the one we did for signature algorithms.  I was wondering if it is possible to have it in JDK 20 so that more specific TLS benchmarks could be introduced sooner.  Thanks!

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

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

From xuelei.f at gmail.com  Mon Nov 21 06:48:47 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Sun, 20 Nov 2022 22:48:47 -0800
Subject: Undo deprecation of brainpool EC
In-Reply-To: <B1B4FF4B-6717-426D-B22E-02BAD36327CDf-i.de@s-web.de>
References: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>
 <27e37532-be19-3ccd-8d8c-6a19c2b3dda2@oracle.com>
 <B1B4FF4B-6717-426D-B22E-02BAD36327CDf-i.de@s-web.de>
Message-ID: <42B141BE-86C4-4B36-8054-A174096FB269@gmail.com>

Hi,

As I?m working on this area recently, I will see if I can contribute.  But it may be no easier than JDK 21.  If you don?t mind, I may ask for more requirement details later and help for testing.

Thanks,
Xuelei

> On Nov 15, 2022, at 11:23 PM, <benjamin.marwell at f-i.de> <benjamin.marwell at f-i.de> wrote:
> 
> Hi Xuelei and Sean,
> 
> We use/see mostly brainpoolP512r1. But it is not just us! 
> 
>> , although I will note that the IANA registry
>>   still lists them as not recommended for TLS [1].
> 
> I agree that brainpoolP512r1 are not particularly interesting when it comes to TLS,
> but we still see server certificates (not the TLS algo) created with brainpoolP512r1, as well as keystores.
> Not being able to connect due to certificate validation errors OR 
> not being able to read a (somewhat) recently created keystore was astonishing, to say the least.
> 
>> And with
>>   recently added support for EdDSA and the future with PQC, it's not
>>   likely we will circle back to them.
> 
> This is not about which algorithm is "better" or "can be replaced".
> It is only about "what should (still) be supported, because NIST and BSI still list them".
> 
>>    We are ok with a contribution,
> 
> In my opinion, this is a major breaking change for this reason and should not wait for contributions.
> 
> - Ben
> 
> 
> ?On 15.11.22, 15:35, "security-dev on behalf of Sean Mullan" <security-dev-retn at openjdk.org on behalf of sean.mullan at oracle.com> wrote:
> 
>    Hi,
> 
>    Thanks for your questions about brainpool. See below for more details.
> 
>    On 11/14/22 3:36 AM, benjamin.marwell at f-i.de wrote:
>> 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.
> 
>    The word "deprecated" may have been the wrong word to use when referring
>    to the brainpool curves, although I will note that the IANA registry
>    still lists them as not recommended for TLS [1].
> 
>    We don't have any issues with the brainpool curves as we do for
>    some of the other legacy curves. But, these curves were implemented in
>    native C code and we changed the structure of the JDK EC implementation
>    such that all curves that were implemented in C were removed. The
>    remaining curves that we do support are implemented in Java and use
>    modern techniques and complete formulas.
> 
>    It has not been a priority for us to re-implement brainpool. And with
>    recently added support for EdDSA and the future with PQC, it's not
>    likely we will circle back to them.
> 
>    We are ok with a contribution, but they would need to be done using
>    the current design structure and using complete formulas.
> 
>    --Sean
> 
>    [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
> 
>> 
>> 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
>> 


From xuelei at openjdk.org  Mon Nov 21 07:17:04 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 21 Nov 2022 07:17:04 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations
In-Reply-To: <N5AS7hNT4XpvMjQnvFILMwf0Pt1d81x-gGveYpBWPd0=.4812c26d-f930-4852-87e5-f99af5ddf198@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <N5AS7hNT4XpvMjQnvFILMwf0Pt1d81x-gGveYpBWPd0=.4812c26d-f930-4852-87e5-f99af5ddf198@github.com>
Message-ID: <xHfRN5nIM8lLRifJInpN5HnFvDc642OtXuHFL3wIpn8=.9c998649-c5d1-462c-bceb-123a63beca12@github.com>

On Mon, 10 Oct 2022 12:11:54 GMT, Daniel Jeli?ski <djelinski 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
>
> That's a pretty significant performance degradation (8%?), and as far as I could tell, it will affect all EC and XEC implementations. On the other hand, #10398 only improves performance of P256. I'm not sure that's a tradeoff we want to make.
> 
> IMO working with setReduced is not that bad; we always invoke the same set of operations in the same sequence, so if we forget to reduce a number before multiplying, every EC operation will fail. Could we introduce just enough reduce / setReduced calls to make P256 work reliably with 9 limbs? What impact would it have on P384?

@djelinski The update has been significantly differently from the first patch.  Did you have a cycle to have another look?

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

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

From xuelei at openjdk.org  Mon Nov 21 07:17:07 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 21 Nov 2022 07:17:07 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: <5QeyJ1CQy1tOOskADY157O5UHdwawb5B0dBLRYB1xFk=.5b28c196-1239-458f-9ee3-a311d7c69361@github.com>

On Wed, 9 Nov 2022 14:27:26 GMT, Ferenc Rakoczi <duke 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 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).

@ferakocz Did you have further comments or concerns?  Please let me know if I'm on the right direction for the performance improvement.  Thanks!

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

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

From djelinski at openjdk.org  Mon Nov 21 07:43:14 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 21 Nov 2022 07:43:14 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
Message-ID: <2Rl6JMh5zE52kYYxwrV-XnDZM2JQ4AGAZb_HoKaP5W8=.13e4dc52-2e7c-4766-a737-da2b4336ed70@github.com>

On Sat, 19 Nov 2022 07:17:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?  With this update, the result will be 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 incrementally with one additional commit since the last revision:
> 
>   remove duplicated bench test

src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 561:

> 559:             // Reduce if required.
> 560:             // if (numAdds >= maxAdds) {
> 561:             if (numAdds > 32 - bitsPerLimb) {

if we allow this number of additions, `setProduct(SmallValue)` might overflow in the future. Currently it's safe - we only create a limited set of SmallValues, and they are all small enough to avoid this risk.
`getSmallValue` allows numbers up to `bitsPerLimb` bits. I think we can adjust that.

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

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

From djelinski at openjdk.org  Mon Nov 21 07:46:29 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 21 Nov 2022 07:46:29 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
Message-ID: <IeNqLbReNSKudHHptSXHrs3GHU6C3ZUaMgdhPOVw-RQ=.6877fdb5-f4e3-4cca-ac62-700c79eaf75b@github.com>

On Sat, 19 Nov 2022 07:17:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?  With this update, the result will be 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 incrementally with one additional commit since the last revision:
> 
>   remove duplicated bench test

Can you share the updated benchmarks?

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

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

From xuelei at openjdk.org  Mon Nov 21 08:18:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 21 Nov 2022 08:18:30 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <IeNqLbReNSKudHHptSXHrs3GHU6C3ZUaMgdhPOVw-RQ=.6877fdb5-f4e3-4cca-ac62-700c79eaf75b@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <IeNqLbReNSKudHHptSXHrs3GHU6C3ZUaMgdhPOVw-RQ=.6877fdb5-f4e3-4cca-ac62-700c79eaf75b@github.com>
Message-ID: <DFEGuptXrvJdjk7tvjnfYrGowpo5Ht0Ld6vTrVgB4PE=.b15b75e0-5269-42b4-abab-3370cc82c397@github.com>

On Mon, 21 Nov 2022 07:44:15 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Can you share the updated benchmarks?

The benchmark number in the PR description is the latest run that I have.  I may run it again after the integration of multiplicative inversion and point  multiplication improvement.

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

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

From ngasson at openjdk.org  Mon Nov 21 09:21:26 2022
From: ngasson at openjdk.org (Nick Gasson)
Date: Mon, 21 Nov 2022 09:21:26 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v4]
In-Reply-To: <7dgYny7behfzrurUf7PH-jfhKYdDIMV4hInwIlZwg-Y=.9a97cf5b-fe58-4855-911b-43ec710c9539@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <7dgYny7behfzrurUf7PH-jfhKYdDIMV4hInwIlZwg-Y=.9a97cf5b-fe58-4855-911b-43ec710c9539@github.com>
Message-ID: <ysGrVsVrKfy29pKxNB9rSWZ72WCXHVJkUL4MMUS6pl4=.9a49d61a-7e59-4017-a890-0c300470396d@github.com>

On Mon, 21 Nov 2022 06:28:32 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:
> 
>   Pull out common macro code into function parameter pack

Marked as reviewed by ngasson (Reviewer).

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

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

From ngasson at openjdk.org  Mon Nov 21 09:21:29 2022
From: ngasson at openjdk.org (Nick Gasson)
Date: Mon, 21 Nov 2022 09:21:29 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v3]
In-Reply-To: <emKiLeQ71GF0MnhnB12gWSYRIg7ZSe8Efl0tnxPv300=.2c03f75a-2e3f-4708-a864-557119222cfa@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <L1ZTSckdP_iY9bvifRX-00Qqw6VLq3sWU9k93TrLW_w=.fc29ffb4-78dc-4d31-b36c-c296e3f48a91@github.com>
 <emKiLeQ71GF0MnhnB12gWSYRIg7ZSe8Efl0tnxPv300=.2c03f75a-2e3f-4708-a864-557119222cfa@github.com>
Message-ID: <pvu4K9OI9qAaL5tZG_IYJQ7puDgafOS7wEp5R8MSZJI=.1f658db1-9d77-4e12-9738-1ecc55929025@github.com>

On Thu, 17 Nov 2022 18:50:48 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
>
> Another pair of arm-knowledgeable eyes on this is always welcome!

AArch64 code looks OK to me, and I believe @jnimeh already discussed the implementation with one of my colleagues who works on crypto optimisation at Arm.

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

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

From coffeys at openjdk.org  Mon Nov 21 09:38:41 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 21 Nov 2022 09:38:41 GMT
Subject: RFR: 8286575: Document how properties in java.security are parsed
 [v2]
In-Reply-To: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
References: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
Message-ID: <XJCuQPdCzE1pY1Yxs7gv4nvifebfhaMGlhEAczMce-Y=.1d4c2757-4a89-4258-81ad-05c6ae946eff@github.com>

> A doc edit to indicate that modifications of values in java.security conf file would require a JVM restart in order for such changes to be detected.

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

  Review comment from Sean M

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11208/files
  - new: https://git.openjdk.org/jdk/pull/11208/files/32b1e7c7..cc8ca1dd

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

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

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

From coffeys at openjdk.org  Mon Nov 21 09:38:41 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 21 Nov 2022 09:38:41 GMT
Subject: RFR: 8286575: Document how properties in java.security are parsed
 [v2]
In-Reply-To: <oCTGCyTu-RsVLidVpNRnTf6PjBTJtaPm0nNLTZOCv-o=.69bded1a-e3bf-4a62-b562-86086573fd0a@github.com>
References: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
 <oCTGCyTu-RsVLidVpNRnTf6PjBTJtaPm0nNLTZOCv-o=.69bded1a-e3bf-4a62-b562-86086573fd0a@github.com>
Message-ID: <rCIYtYs6mqSmoycJoA61bLAmR2mAODifLGI40em9C-8=.625d3cf9-25f7-47d6-abef-b688ccffd594@github.com>

On Fri, 18 Nov 2022 22:50:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment from Sean M
>
> src/java.base/share/conf/security/java.security line 29:
> 
>> 27: # an unspecified error when initializing the java.security.Security class.
>> 28: # Properties in this file are typically parsed only once. Any modification
>> 29: # would require an application restart to reflect changes.
> 
> Maybe change the second sentence to "If any of the properties are modified, applications should be restarted to ensure the changes are properly reflected."
> 
> This makes it more consistent with the words in the first sentence.

Thanks for the review. Change implemented.

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

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

From pminborg at openjdk.org  Mon Nov 21 11:00:13 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 11:00:13 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
Message-ID: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>

This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 

Design choices in this PR:

There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.

The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.

In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.

On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".

I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.

This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

Commit messages:
 - Guard usages of DirectBuffer::address

Changes: https://git.openjdk.org/jdk/pull/11260/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296024
  Stats: 277 lines in 26 files changed: 191 ins; 4 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From alanb at openjdk.org  Mon Nov 21 11:31:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 11:31:16 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

src/java.base/share/classes/java/nio/Buffer.java line 785:

> 783:                 static final JavaNioAccess.SessionAcquisition NO_OP_CLOSE = new JavaNioAccess.SessionAcquisition() {
> 784:                     @Override
> 785:                     public void close() throws RuntimeException {}

The throws RuntimeException is not needed here. Also would it be possible to reflow the comment to avoid the wildly long line.

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 161:

> 159: 
> 160:         @Override
> 161:         void close() throws RuntimeException;

You can drop throws RuntimeEXcepton here too.

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 38:

> 36:     // try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
> 37:     //     performOperation(bb.address());
> 38:     // }

This comment is very messy and needs to be cleaned up.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:

> 250:         try {
> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
> 252:             // Hence, there is no need for acquiring any session.

This comment is will be confusing to anyone reading this code. Is this really needed?

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

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

From alanb at openjdk.org  Mon Nov 21 11:36:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 11:36:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

src/java.base/share/classes/java/util/zip/Adler32.java line 102:

> 100:             return;
> 101:         if (buffer.isDirect()) {
> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {

We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.

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

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

From pminborg at openjdk.org  Mon Nov 21 11:40:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 11:40:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
Message-ID: <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>

On Mon, 21 Nov 2022 11:29:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:
> 
>> 250:         try {
>> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
>> 252:             // Hence, there is no need for acquiring any session.
> 
> This comment is will be confusing to anyone reading this code. Is this really needed?

The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:09:20 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
Message-ID: <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>

On Mon, 21 Nov 2022 11:32:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> src/java.base/share/classes/java/util/zip/Adler32.java line 102:
> 
>> 100:             return;
>> 101:         if (buffer.isDirect()) {
>> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {
> 
> We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.

Eventually, I hope most of them will be named `_`.

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

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

From alanb at openjdk.org  Mon Nov 21 12:09:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 12:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
 <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
Message-ID: <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>

On Mon, 21 Nov 2022 11:36:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:
>> 
>>> 250:         try {
>>> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
>>> 252:             // Hence, there is no need for acquiring any session.
>> 
>> This comment is will be confusing to anyone reading this code. Is this really needed?
>
> The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.

I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:20:01 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:20:01 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <IdvkKlVEKF8ztjOHvgSwd3z2aJLRJtbUA-2P4H4A42Y=.faab2987-1d1d-4f4f-82df-f9f8db576caf@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/23a6fd14..9fafafac

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

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

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

From mcimadamore at openjdk.org  Mon Nov 21 12:20:05 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 12:20:05 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
Message-ID: <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>

On Mon, 21 Nov 2022 12:03:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/Adler32.java line 102:
>> 
>>> 100:             return;
>>> 101:         if (buffer.isDirect()) {
>>> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {
>> 
>> We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.
>
> Eventually, I hope most of them will be named `_`.

maybe just `bufferLock` and and just `acquireBuffer` ?

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

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

From alanb at openjdk.org  Mon Nov 21 12:21:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 12:21:56 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
Message-ID: <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>

On Mon, 21 Nov 2022 12:16:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Eventually, I hope most of them will be named `_`.
>
> maybe just `bufferLock` and and just `acquireBuffer` ?

Would it be possible to re-examine acquireSession returning Runnable and 
acquireSessionAsAutoCloseable returning AutoCloseable. The naming is awkward at most of the use sites and maybe we can do better.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:37:33 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:37:33 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v3]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <hhDVmcADk7zrfplELPNulJjOm0n56IKFmBE8Dmr2K4w=.d4f2ee38-2199-4323-85f7-b840e084904c@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/9fafafac..9fcf2bb3

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

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

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

From pminborg at openjdk.org  Mon Nov 21 12:54:17 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:54:17 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v3]
In-Reply-To: <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
 <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
Message-ID: <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>

On Mon, 21 Nov 2022 12:19:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> maybe just `bufferLock` and and just `acquireBuffer` ?
>
> Would it be possible to re-examine acquireSession returning Runnable and 
> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better.

I think it would be confusing to have overloads with the same name. 

The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`.

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

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

From pminborg at openjdk.org  Mon Nov 21 13:02:48 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:02:48 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/9fcf2bb3..c081b4ae

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

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

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

From duke at openjdk.org  Mon Nov 21 13:39:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Nov 2022 13:39:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
Message-ID: <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>

On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename methods

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 94:

> 92:      * required to guarantee safety.
> 93:      * {@snippet lang = java:
> 94:      * var handler = acquireSessionOrNoOp(buffer);

Suggestion:

     * var handler = acquireSessionOrNull(buffer, async);

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:

> 39:     // An example of a guarded use of a memory address is shown here:
> 40:     //
> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {

Suggestion:

    // try (var guard = NIO_ACCESS.acquireSession(bb)) {

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

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

From pminborg at openjdk.org  Mon Nov 21 13:43:21 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:43:21 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v5]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <iECO8UBKUoYcWn5I67E9kbCsy4tLqdswYhddUllpcLQ=.494414bf-1401-4e40-bc14-4f86f60b335e@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup static declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/c081b4ae..eca7c388

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

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

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

From pminborg at openjdk.org  Mon Nov 21 13:49:09 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:49:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
Message-ID: <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>

On Mon, 21 Nov 2022 13:32:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename methods
>
> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:
> 
>> 39:     // An example of a guarded use of a memory address is shown here:
>> 40:     //
>> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
> 
> Suggestion:
> 
>     // try (var guard = NIO_ACCESS.acquireSession(bb)) {

Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time?

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

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

From duke at openjdk.org  Mon Nov 21 13:49:09 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Nov 2022 13:49:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
 <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>
Message-ID: <UQL92ereV30YE4RxJFFHfF8YQFznI0les962qyQjsT4=.6123ea57-7532-41c3-a8d6-b00282d4fa3b@github.com>

On Mon, 21 Nov 2022 13:43:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:
>> 
>>> 39:     // An example of a guarded use of a memory address is shown here:
>>> 40:     //
>>> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
>> 
>> Suggestion:
>> 
>>     // try (var guard = NIO_ACCESS.acquireSession(bb)) {
>
> Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time?

This?change was?missed in?commit?<https://github.com/openjdk/jdk/pull/11260/commits/c081b4aebb7b52c7161656b4cba9b0a60d36202a>.

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

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

From pminborg at openjdk.org  Mon Nov 21 14:02:38 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 14:02:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/eca7c388..a0de3bcf

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

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

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

From pminborg at openjdk.org  Mon Nov 21 14:06:08 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 14:06:08 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v7]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <85JCc27fZGJjTrQbm1vJfA6BY1KgAZ9PLlRJQgbcj3M=.1707b29d-4c0c-4f0f-9be9-acbfc341d571@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains six commits:

 - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Cleanup static declarations
 - Rename methods
 - Remove comments
 - Cleanup after comments
 - Guard usages of DirectBuffer::address

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/a0de3bcf..17a72e9f

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

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

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

From weijun at openjdk.org  Mon Nov 21 14:02:32 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Nov 2022 14:02:32 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v6]
In-Reply-To: <51Ppy4DuBRLKLVx791XoBw0QMuafO7TWBEDtfIMVU-g=.2daad272-8b8f-4f35-91d2-5337ea2fc74b@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <51Ppy4DuBRLKLVx791XoBw0QMuafO7TWBEDtfIMVU-g=.2daad272-8b8f-4f35-91d2-5337ea2fc74b@github.com>
Message-ID: <0ImiP6uglDLfXTD0-fnQhgXcTxXzX7uwPBea-NxT1NQ=.699d9f54-3eea-425d-97ed-872d6dc9c7c0@github.com>

On Mon, 21 Nov 2022 00:29:34 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify as review and update copyright.

Looks almost complete. Just 2 small comments.

src/java.base/share/classes/java/util/jar/JarVerifier.java line 330:

> 328:     }
> 329: 
> 330:     public Certificate[] getCerts(JarEntry entry)

You might want to move the javadoc of the removed `getCerts(String)` method here. It looks there was a single javadoc for 2 methods. We should keep one.

src/java.base/share/classes/java/util/jar/JarVerifier.java line 345:

> 343:     }
> 344: 
> 345:     public CodeSigner[] getCodeSigners(JarEntry entry)

Since the 1st `getCodeSigners` is only used by the 2nd one. We can inline the 1st one into the 2nd one.

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

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

From alanb at openjdk.org  Mon Nov 21 14:11:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 14:11:31 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
Message-ID: <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>

On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename methods

src/java.base/share/classes/java/util/zip/Adler32.java line 105:

> 103:                 adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
> 104:             } finally {
> 105:                 Reference.reachabilityFence(buffer);

The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible.  I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites?

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

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

From alanb at openjdk.org  Mon Nov 21 14:16:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 14:16:41 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
Message-ID: <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>

On Mon, 21 Nov 2022 14:02:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92:

> 90:      * allocated from the heap.
> 91:      * <p>
> 92:      * The returned NativeBuffer is guaranteed not to be asynchronously closeable.

This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of  asynchronously close so maybe it would best to not add this comment to these sources.

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

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

From mullan at openjdk.org  Mon Nov 21 14:23:21 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Nov 2022 14:23:21 GMT
Subject: RFR: 8286575: Document how properties in java.security are parsed
 [v2]
In-Reply-To: <XJCuQPdCzE1pY1Yxs7gv4nvifebfhaMGlhEAczMce-Y=.1d4c2757-4a89-4258-81ad-05c6ae946eff@github.com>
References: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
 <XJCuQPdCzE1pY1Yxs7gv4nvifebfhaMGlhEAczMce-Y=.1d4c2757-4a89-4258-81ad-05c6ae946eff@github.com>
Message-ID: <_xkps6LhJ7cMWcYw-CqL48gbhz9MaMYipsgH98Ha6sY=.faaf5744-6c67-4629-ba82-ccbf3dd163c0@github.com>

On Mon, 21 Nov 2022 09:38:41 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> A doc edit to indicate that modifications of values in java.security conf file would require a JVM restart in order for such changes to be detected.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment from Sean M

Add a noreg-doc label to the issue. Looks good otherwise.

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

Marked as reviewed by mullan (Reviewer).

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

From coffeys at openjdk.org  Mon Nov 21 14:31:21 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 21 Nov 2022 14:31:21 GMT
Subject: Integrated: 8286575: Document how properties in java.security are
 parsed
In-Reply-To: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
References: <9u8FYcy8o3R3gSiQcgaVEtselmuK74OJObQTEr5B5nI=.cb34a160-3134-4293-90f2-b7a909050c00@github.com>
Message-ID: <MuT4YwifMQP8v6y31myxgPRP3GB3URravEt7DqtupvE=.9f8eb2b9-7c8c-4c37-a33c-bf8cfd1d90bf@github.com>

On Thu, 17 Nov 2022 12:26:18 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> A doc edit to indicate that modifications of values in java.security conf file would require a JVM restart in order for such changes to be detected.

This pull request has now been integrated.

Changeset: d0a7938e
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0a7938eb7637acd0b1b559963a939dde30f6dcf
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8286575: Document how properties in java.security are parsed

Reviewed-by: mullan

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

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

From weijun at openjdk.org  Mon Nov 21 15:28:00 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Nov 2022 15:28:00 GMT
Subject: Integrated: 8296399: crlNumExtVal might be null inside
 X509CRLSelector::match
In-Reply-To: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>
References: <hXfGCoj67kDp6GnZemmfvfYjI6htB776mLkwGze5t5E=.edc1809b-482e-40a0-a214-12f52ae836fb@github.com>
Message-ID: <Cji9MNj6db3DHbAN3HD9eqI_Yudlq4AJHUTKqrFODC8=.0632e563-d016-4010-8150-d750b58404f3@github.com>

On Thu, 17 Nov 2022 16:14:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> When `X509CRLSelector ` requires a CRL number extension but a CRL does not have it, the CRL should not be selected.
> 
> Note: the test uses a new internal API introduced in https://github.com/openjdk/jdk/pull/11151.

This pull request has now been integrated.

Changeset: 57f5cfde
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57f5cfdeb52b160e58968fb177b4432b3e079607
Stats:     78 lines in 2 files changed: 78 ins; 0 del; 0 mod

8296399: crlNumExtVal might be null inside X509CRLSelector::match

Reviewed-by: xuelei

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

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

From pminborg at openjdk.org  Mon Nov 21 15:31:32 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 15:31:32 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
 <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
Message-ID: <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>

On Mon, 21 Nov 2022 14:14:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92:
> 
>> 90:      * allocated from the heap.
>> 91:      * <p>
>> 92:      * The returned NativeBuffer is guaranteed not to be asynchronously closeable.
> 
> This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of  asynchronously close so maybe it would best to not add this comment to these sources.

That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments.

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

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

From pminborg at openjdk.org  Mon Nov 21 15:34:54 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 15:34:54 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v8]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <wajuJrHs8kgD4SezHUCBWvAceHqa5YSY2olr7QPLSms=.42f6db8c-23bf-486d-97d4-0ebaac18f7e1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'guard-directbuffer-address' of https://github.com/minborg/jdk into guard-directbuffer-address
 - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Remove comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/17a72e9f..88ed3aa2

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

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

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

From xuelei at openjdk.org  Mon Nov 21 15:59:46 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 21 Nov 2022 15:59:46 GMT
Subject: Integrated: 8294073: Performance improvement for message digest
 implementations
In-Reply-To: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
References: <bxHQxPbdQu3nJYLTGfn-qm56JjigCqzeCJbUfUndctM=.4da39a4e-b8c7-489a-80a2-130d125607ab@github.com>
Message-ID: <rw80FAqk2bfhwPDPURQSvWIirLveyuuPrRXvcOuqsXk=.2dec67fb-e0e0-4adc-9ea5-702235b6ce22@github.com>

On Tue, 20 Sep 2022 22:12:04 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> In the message digest implementation, for example SHA256, in JDK, two bitwise operations could be improved with equivalent arithmetic, and then the number bitwise operations could be reduced accordingly.  Specifically
> "(x and y) xor ((complement x) and z)" could be replaced with the equivalent "z xor (x and (y xor z))", and "(x and y) xor (x and z) xor (y and z)" could be replaced with the equivalent "(x and y) xor ((x xor y) and z)".  Each replacement reduces one bitwise operation, and thus improve the performance.
> 
> Per my testing on my MacOS laptop, the update on SHA256 improves the message digest throughput by 0.5%-0.8%.  The improvement is not significant, but might be worthy of it as the update is pretty simple and trivial, for those platforms that do not support CPU intrinsic for a certain hash algorithm.
> 
> This patch update SHA2 implementation only.  Please let me know what do you think.  If you are good  with this little bit performance, I will update more message digest implementations.  If no one interested in these little benefits, I will close this PR later.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

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

8294073: Performance improvement for message digest implementations

Reviewed-by: jjiang

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

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

From pminborg at openjdk.org  Mon Nov 21 16:10:27 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 16:10:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
Message-ID: <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>

On Mon, 21 Nov 2022 14:07:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename methods
>
> src/java.base/share/classes/java/util/zip/Adler32.java line 105:
> 
>> 103:                 adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
>> 104:             } finally {
>> 105:                 Reference.reachabilityFence(buffer);
> 
> The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible.  I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites?

This can certainly be done. We could, for example, add a new method to the `JavaNioAccess` interface:

```AddressAcquisition acquireSession2(Buffer buffer); // to be renamed```

This would allow us to go from:


            try (var guard = NIO_ACCESS.acquireSession(buffer)) {
                adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
            } finally {
                Reference.reachabilityFence(buffer);
            }


to


            try (var guard = NIO_ACCESS.acquireSession2(buffer)) {
                adler = updateByteBuffer(adler, guard.address(), pos, rem);
            }


Although this looks much simpler and concise, it means "a new object is created for each invocation" (*). This also allows us to remove the `@SupressWarnings("try")` annotations.

Here is how the undercarriage might look like:


                @Override
                public AddressAcquisition acquireSession2(Buffer buffer) {
                    var session = buffer.session();
                    if (session == null) {
                        return AddressAcquisition.create(buffer, () -> {});
                    }
                    session.acquire0();
                    return AddressAcquisition.create(buffer, session::release0);
                }



and


sealed interface AddressAcquisition extends AutoCloseable {

        long address();

        @Override
        void close();

        static AddressAcquisition create(Buffer buffer, Runnable closeActions) {
            return new AddressAcquisitionImpl(buffer, closeActions);
        }

        final class AddressAcquisitionImpl implements AddressAcquisition {

            private final DirectBuffer directBuffer;
            private final Runnable closeAction;

            public AddressAcquisitionImpl(Buffer buffer,
                                          Runnable closeAction) {
                this.directBuffer = (DirectBuffer) buffer;
                this.closeAction = closeAction;
            }

            @Override
            public long address() {
                return directBuffer.address();
            }

            @Override
            public void close() {
                try {
                    closeAction.run();
                } finally {
                    Reference.reachabilityFence(directBuffer);
                }
            }
        }

    }



(*) In reality,  a representation of the object might be allocated on the stack instead.

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

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

From xuelei at openjdk.org  Mon Nov 21 16:21:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 21 Nov 2022 16:21:30 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <2Rl6JMh5zE52kYYxwrV-XnDZM2JQ4AGAZb_HoKaP5W8=.13e4dc52-2e7c-4766-a737-da2b4336ed70@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <2Rl6JMh5zE52kYYxwrV-XnDZM2JQ4AGAZb_HoKaP5W8=.13e4dc52-2e7c-4766-a737-da2b4336ed70@github.com>
Message-ID: <vkJrjIigECQjrrvb_sKmx-Z-BH1Aixqip_4QRsLcKBo=.a7ffb1b7-68f2-4295-a7f3-cf3c3d4252d7@github.com>

On Mon, 21 Nov 2022 07:41:12 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove duplicated bench test
>
> src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 561:
> 
>> 559:             // Reduce if required.
>> 560:             // if (numAdds >= maxAdds) {
>> 561:             if (numAdds > 32 - bitsPerLimb) {
> 
> if we allow this number of additions, `setProduct(SmallValue)` might overflow in the future. Currently it's safe - we only create a limited set of SmallValues, and they are all small enough to avoid this risk.
> `getSmallValue` allows numbers up to `bitsPerLimb` bits. I think we can adjust that.

Sorry, I did not get the ideas.  Did you meant to adjust the implementation of getSmallValue to allow 32 bits int value?

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

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

From mullan at openjdk.org  Mon Nov 21 16:36:28 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Nov 2022 16:36:28 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: <5JDd7s4X4Iy0YzM2tLQimSyyFigR7W9cWixtgmcK3WY=.5e27e22c-03c3-4aa9-bb6a-0a9d6b36b109@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.
>
>> > 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.

> @seanjmullan Did you have cycle to review this PR and CSR? This CSR is similar to the one we did for signature algorithms. I was wondering if it is possible to have it in JDK 20 so that more specific TLS benchmarks could be introduced sooner. Thanks!

I added my name as Reviewer to the CSR, so you can finalize that, as that will give you a better chance of it being approved and getting this into JDK 20. It will take me a little while longer to review the code changes, though I don't expect it will impact the API.

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

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

From alanb at openjdk.org  Mon Nov 21 16:37:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 16:37:33 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
Message-ID: <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>

On Mon, 21 Nov 2022 16:08:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Although this looks much simpler and concise, it means "a new object is created for each invocation" 

My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case.  Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.

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

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

From mcimadamore at openjdk.org  Mon Nov 21 17:05:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 17:05:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
Message-ID: <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>

On Mon, 21 Nov 2022 16:34:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
> 
> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.

Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.

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

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

From mcimadamore at openjdk.org  Mon Nov 21 17:05:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 17:05:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v8]
In-Reply-To: <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
 <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
 <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>
Message-ID: <GtZ7D3vC5YXHj_8J1pOlB7FceWDEWD4FiSvBB-cLqAI=.00dc532b-de35-4766-8d9b-abd9102246e6@github.com>

On Mon, 21 Nov 2022 12:50:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Would it be possible to re-examine acquireSession returning Runnable and 
>> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better.
>
> I think it would be confusing to have overloads with the same name. 
> 
> The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`.

IIRC, Runnable was chosen back then because of the issues with using TWR which was generating warnings (because resource not accessed in body of TWR). I don't have strong opinions on this, other than we should only have one way to do things, rather than 2-3. Since the JDK has capabilities to acquire and release a session w/o a TWR and/or Runnable, one might also consider whether exposing acquire/release separately, and just use those.

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

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

From duke at openjdk.org  Mon Nov 21 17:44:36 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Nov 2022 17:44:36 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v21]
In-Reply-To: <Bt4UNZU2itTeHs_2ojFCD64AXpGPiI8gveUtRg5mea0=.2926b137-f31e-4505-9a96-815e4f5ab851@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
 <Bt4UNZU2itTeHs_2ojFCD64AXpGPiI8gveUtRg5mea0=.2926b137-f31e-4505-9a96-815e4f5ab851@github.com>
Message-ID: <EseUb0cgdeigmu9nNWflTuRMLKo6T0nEruj3TaPqfYQ=.bedc9bf5-5f1f-48be-8846-0064a88036a0@github.com>

On Thu, 17 Nov 2022 19:32:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   vzeroall, no spill, reg re-map
>
> Overall, looks good. Just one minor cleanup suggestion.
> 
> I've submitted the latest patch for testing (hs-tier1 - hs-tier4).

@iwanowww Hope the extra tests passed? (Or do you have to re-run them on the latest patch again?)

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

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

From jjg at openjdk.org  Mon Nov 21 17:54:15 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 21 Nov 2022 17:54:15 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java [v2]
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Fix merge issue
 - Merge with upstream/master
 - JDK-8297164: Update troff man pages and CheckManPageOptions.java

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

Changes: https://git.openjdk.org/jdk/pull/11223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=01
  Stats: 8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod
  Patch: https://git.openjdk.org/jdk/pull/11223.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223

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

From dfuchs at openjdk.org  Mon Nov 21 18:19:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Nov 2022 18:19:23 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java [v2]
In-Reply-To: <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
 <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>
Message-ID: <BfqsAA59PbkyFi7ceXdE3JClChGmOoN7zxbWxPP_pxw=.7948deb7-49d0-4553-8923-69f4daefb1ea@github.com>

On Mon, 21 Nov 2022 17:54:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
>> (See https://bugs.openjdk.org/browse/JDK-8297165)
>> 
>> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Fix merge issue
>  - Merge with upstream/master
>  - JDK-8297164: Update troff man pages and CheckManPageOptions.java

The diffs are a bit difficult to read but I didn't spot anything obviously wrong with jwebserver. I could see that the new compress option was there in jmod man page too. +1.

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

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

From ascarpino at openjdk.org  Mon Nov 21 18:20:09 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 21 Nov 2022 18:20:09 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <ou7e_ZdGVZUQXF_fZIUX-ssabz-9ggfd0dVPRchNUdo=.e36b0b9f-abed-4c1e-abc2-1c8eec14981f@github.com>

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  comment cleanup & finesse ByteBuffer implGCMCrypt better

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11121/files
  - new: https://git.openjdk.org/jdk/pull/11121/files/3ecebd61..f595dc24

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

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

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

From ascarpino at openjdk.org  Mon Nov 21 18:20:14 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 21 Nov 2022 18:20:14 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
Message-ID: <3gmEAK_iMgq3wsVlOsCZm4BZsOAjcQtYm8qvZBQsqNU=.1342feb4-db48-4dc0-90c5-2a920e0a4850@github.com>

On Wed, 16 Nov 2022 17:01:50 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment cleanup & finesse ByteBuffer implGCMCrypt better
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 603:
> 
>> 601:         }
>> 602: 
>> 603:         // Finish any remaining data
> 
> comment doesn't add anything special

ok

> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1644:
> 
>> 1642:                 // Clear output data
>> 1643:                 dst.reset();
>> 1644:                 // If this is an in-place array, don't zero the src
> 
> The comment doesn't jive with the line of code on the next line. It is the inverse of the comment.

ok

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

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

From ascarpino at openjdk.org  Mon Nov 21 18:20:11 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 21 Nov 2022 18:20:11 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <dhhyhbM44ycRzTNpihez1xcKl2qAv2F5LKggg1lWJuM=.0a91ebf9-3e5d-4221-a4b2-b529e2b5fcf7@github.com>

On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

btw. that last commit comment is wrong.. it's cleaning up from mcpowers's comments.

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

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

From ascarpino at openjdk.org  Mon Nov 21 18:20:15 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 21 Nov 2022 18:20:15 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <RRDZOxcaPOXvAhu9EVFLNStkjA4JZoZfJcZ96oehdUs=.54166783-3808-4b98-9b70-24d71c3de323@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
 <RRDZOxcaPOXvAhu9EVFLNStkjA4JZoZfJcZ96oehdUs=.54166783-3808-4b98-9b70-24d71c3de323@github.com>
Message-ID: <Eu5twwTlFSlvJyzOYZAd34ePMYyJTjOz8UugZcIVprg=.c1a65c75-dee3-4135-a5a4-d27717fedbdc@github.com>

On Fri, 18 Nov 2022 05:19:31 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 694:
>> 
>>> 692:         int originalOutOfs = 0;
>>> 693: 
>>> 694:         // True if op is in-place array decryption with the input & output
>> 
>> // Setting `inPlaceArray` to true turns off combined intrinsic processing.
>
> yeah that's better

Actually the replacement isn't entirely accurate.  This only applies to decryption and for buffers that don't overlap where input is ahead of output.  That's why the comment is so wordy

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

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

From vlivanov at openjdk.org  Mon Nov 21 19:00:31 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 21 Nov 2022 19:00:31 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v22]
In-Reply-To: <encTlnf9qtjfjtVa-jDoWJMcUc6AwRtSDj7tk_OyBM0=.9728a3c6-6009-4873-9cb3-28ac8c262282@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <encTlnf9qtjfjtVa-jDoWJMcUc6AwRtSDj7tk_OyBM0=.9728a3c6-6009-4873-9cb3-28ac8c262282@github.com>
Message-ID: <K3ahvJ23eDT3tc4Dn8Chwm8xXb5Xm47iWccekma2bMY=.02bdd22b-866a-4239-8105-a3219e8df259@github.com>

On Thu, 17 Nov 2022 20:42:27 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:
> 
>   remove early return

JVM part looks good.

The test results look good. (Had to wait until testing is complete.)

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

Marked as reviewed by vlivanov (Reviewer).

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

From alanb at openjdk.org  Mon Nov 21 20:08:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 20:08:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
 <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
Message-ID: <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>

On Mon, 21 Nov 2022 17:00:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Although this looks much simpler and concise, it means "a new object is created for each invocation" 
>> 
>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case.  Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
>
>> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
>> 
>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
> 
> Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.

Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already.

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

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

From duke at openjdk.org  Mon Nov 21 21:05:39 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Nov 2022 21:05:39 GMT
Subject: Integrated: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions
In-Reply-To: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
Message-ID: <JY-BfrL1Sa8AycQ-uBdqwju80n0b8rwxvFEHQxVIyyU=.33674f8b-e1fe-4775-aeec-80dc48039d1f@github.com>

On Wed, 5 Oct 2022 21:28:26 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

This pull request has now been integrated.

Changeset: f12710e9
Author:    Volodymyr Paprotski <volodymyr.paprotski at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f12710e938b36594623e9c82961d8aa0c0ef29c2
Stats:     1860 lines in 32 files changed: 1824 ins; 3 del; 33 mod

8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions

Reviewed-by: sviswanathan, vlivanov

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

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

From jjg at openjdk.org  Mon Nov 21 22:06:36 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 21 Nov 2022 22:06:36 GMT
Subject: Integrated: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <heN0GBRdomaSVnNUZIi7L1vA_uegGEvn0ZQ1mOD6Mwc=.fb15980e-f807-42bb-976a-f112e0f642e3@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

This pull request has now been integrated.

Changeset: 5a45c251
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a45c25151b1da8e329ea2be21a0e4d2652f8b4a
Stats:     8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod

8297164: Update troff man pages and CheckManPageOptions.java

Reviewed-by: dholmes

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

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

From duke at openjdk.org  Tue Nov 22 00:45:00 2022
From: duke at openjdk.org (pandaapo)
Date: Tue, 22 Nov 2022 00:45:00 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7]
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <PmzKdNZqSfU-2h4Dh0pR2n9RKqjxVhjZT6TvS9EHznI=.0e59d7f8-ecdb-4b5c-8555-8f074c191352@github.com>

> The cache named `signerToCodeSource` in `JarVerifier` is never used now.

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

  Modify as reviews.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11072/files
  - new: https://git.openjdk.org/jdk/pull/11072/files/fb933804..1aa65b2b

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

  Stats: 10 lines in 1 file changed: 4 ins; 5 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 dholmes at openjdk.org  Tue Nov 22 00:45:57 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Nov 2022 00:45:57 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v22]
In-Reply-To: <encTlnf9qtjfjtVa-jDoWJMcUc6AwRtSDj7tk_OyBM0=.9728a3c6-6009-4873-9cb3-28ac8c262282@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <encTlnf9qtjfjtVa-jDoWJMcUc6AwRtSDj7tk_OyBM0=.9728a3c6-6009-4873-9cb3-28ac8c262282@github.com>
Message-ID: <PLZFHnt40pDDB__eeQp57j8KTKs1CmndGhvQCQlbiiY=.55f9fa6d-7716-4cac-9a3a-6b825455ea48@github.com>

On Thu, 17 Nov 2022 20:42:27 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:
> 
>   remove early return

Testing is broken:

test/jdk/sun/security/util/math/BigIntegerModuloP.java:160: error: BigIntegerModuloP.ImmutableElement is not abstract and does not override abstract method getLimbs() in IntegerModuloP
    private class ImmutableElement extends Element

Did you forget to commit a test file?

I will file a new bug for this.

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

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

From vlivanov at openjdk.org  Tue Nov 22 00:53:27 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 22 Nov 2022 00:53:27 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v4]
In-Reply-To: <7dgYny7behfzrurUf7PH-jfhKYdDIMV4hInwIlZwg-Y=.9a97cf5b-fe58-4855-911b-43ec710c9539@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <7dgYny7behfzrurUf7PH-jfhKYdDIMV4hInwIlZwg-Y=.9a97cf5b-fe58-4855-911b-43ec710c9539@github.com>
Message-ID: <Lqk3lBEBV7QKGZ2IhKVF0ekFlGOypcnAydHG_y1lZlE=.6199a3af-55f3-4c6c-bed5-4448e83faeb6@github.com>

On Mon, 21 Nov 2022 06:28:32 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:
> 
>   Pull out common macro code into function parameter pack

Looks good.

src/hotspot/cpu/x86/stubGenerator_x86_64_chacha.cpp line 107:

> 105:     if (VM_Version::supports_evex()) {
> 106:       StubRoutines::_chacha20Block = generate_chacha20Block_avx512();
> 107:     } else {    // Either AVX or AVX2 is supported

Worth to supplement the comment with an assert (either `UseAVX > 0` or `VM_Version::supports_avx() == true`).

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

Marked as reviewed by vlivanov (Reviewer).

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

From weijun at openjdk.org  Tue Nov 22 01:46:43 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 01:46:43 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7]
In-Reply-To: <PmzKdNZqSfU-2h4Dh0pR2n9RKqjxVhjZT6TvS9EHznI=.0e59d7f8-ecdb-4b5c-8555-8f074c191352@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <PmzKdNZqSfU-2h4Dh0pR2n9RKqjxVhjZT6TvS9EHznI=.0e59d7f8-ecdb-4b5c-8555-8f074c191352@github.com>
Message-ID: <vN7AjRNdmzwDhOn-iJ-zCwgeX4X8c8pUCMeoL9E9lqM=.fcaadca5-c1d7-4684-a205-0a808a457020@github.com>

On Tue, 22 Nov 2022 00:45:00 GMT, pandaapo <duke at openjdk.org> wrote:

>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify as reviews.

Everything looks fine now. Thanks so much for the cleanup. It's always nice to see unused lines removed.

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

Marked as reviewed by weijun (Reviewer).

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

From duke at openjdk.org  Tue Nov 22 01:58:22 2022
From: duke at openjdk.org (pandaapo)
Date: Tue, 22 Nov 2022 01:58:22 GMT
Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7]
In-Reply-To: <vN7AjRNdmzwDhOn-iJ-zCwgeX4X8c8pUCMeoL9E9lqM=.fcaadca5-c1d7-4684-a205-0a808a457020@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
 <PmzKdNZqSfU-2h4Dh0pR2n9RKqjxVhjZT6TvS9EHznI=.0e59d7f8-ecdb-4b5c-8555-8f074c191352@github.com>
 <vN7AjRNdmzwDhOn-iJ-zCwgeX4X8c8pUCMeoL9E9lqM=.fcaadca5-c1d7-4684-a205-0a808a457020@github.com>
Message-ID: <5BMq7qlR9msrDdQONoHzHFKw4T99g0CcYuFh03SKuD8=.809ab694-3694-4a2a-80a6-2b13136c43ae@github.com>

On Tue, 22 Nov 2022 01:44:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Everything looks fine now. Thanks so much for the cleanup. It's always nice to see unused lines removed.

Thank you for your review.

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

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

From duke at openjdk.org  Tue Nov 22 03:24:38 2022
From: duke at openjdk.org (pandaapo)
Date: Tue, 22 Nov 2022 03:24:38 GMT
Subject: Integrated: 8297301: Cleanup unused methods in JavaUtilJarAccess
In-Reply-To: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
References: <GrHFhwPaoVUDDOiQxCFjMUgnuAh55PVXiQogoEGNfLw=.1e96d6d9-bc84-48f4-8169-d33b4bc01213@github.com>
Message-ID: <jGgsk75Hjhscb21gICoC9XXN9Z0xhUgxoHpZ5koLJgc=.27ae601e-4e7b-42ff-b427-a44ea9c2f231@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.

This pull request has now been integrated.

Changeset: f0e99c63
Author:    pandaapo <1052156701 at qq.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0e99c634693fafc0c5d1103184e73c6669629db
Stats:     652 lines in 4 files changed: 3 ins; 636 del; 13 mod

8297301: Cleanup unused methods in JavaUtilJarAccess

Reviewed-by: weijun

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

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

From jnimeh at openjdk.org  Tue Nov 22 05:28:05 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 22 Nov 2022 05:28:05 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v5]
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <7-omMJqslZjYB-nYcKyasj5bkNSDyCTXyj53yg7hpPI=.d9b796da-cf58-4591-8767-72beb67faf1e@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 with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Merge with main
 - Add AVX assertion guard
 - Pull out common macro code into function parameter pack
 - replace hi/lo word shuffles and left-right shift/or operations for vpshufd on byte-aligned rotations
 - 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
 - ... and 40 more: https://git.openjdk.org/jdk/compare/392ac705...bb3f4264

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

Changes: https://git.openjdk.org/jdk/pull/7702/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7702&range=04
  Stats: 1593 lines in 28 files changed: 1555 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 jnimeh at openjdk.org  Tue Nov 22 05:29:56 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 22 Nov 2022 05:29:56 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v4]
In-Reply-To: <Lqk3lBEBV7QKGZ2IhKVF0ekFlGOypcnAydHG_y1lZlE=.6199a3af-55f3-4c6c-bed5-4448e83faeb6@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <7dgYny7behfzrurUf7PH-jfhKYdDIMV4hInwIlZwg-Y=.9a97cf5b-fe58-4855-911b-43ec710c9539@github.com>
 <Lqk3lBEBV7QKGZ2IhKVF0ekFlGOypcnAydHG_y1lZlE=.6199a3af-55f3-4c6c-bed5-4448e83faeb6@github.com>
Message-ID: <d44txx0W_WbncibBXz1b87LUpdop3VWPu3Cko5Os9O0=.08bb0ff3-45bf-457b-bd83-69395f85ef18@github.com>

On Mon, 21 Nov 2022 19:06:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pull out common macro code into function parameter pack
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_chacha.cpp line 107:
> 
>> 105:     if (VM_Version::supports_evex()) {
>> 106:       StubRoutines::_chacha20Block = generate_chacha20Block_avx512();
>> 107:     } else {    // Either AVX or AVX2 is supported
> 
> Worth to supplement the comment with an assert (either `UseAVX > 0` or `VM_Version::supports_avx() == true`).

Good catch.  This has been implemented.

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

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

From djelinski at openjdk.org  Tue Nov 22 08:43:26 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Nov 2022 08:43:26 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <vkJrjIigECQjrrvb_sKmx-Z-BH1Aixqip_4QRsLcKBo=.a7ffb1b7-68f2-4295-a7f3-cf3c3d4252d7@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <2Rl6JMh5zE52kYYxwrV-XnDZM2JQ4AGAZb_HoKaP5W8=.13e4dc52-2e7c-4766-a737-da2b4336ed70@github.com>
 <vkJrjIigECQjrrvb_sKmx-Z-BH1Aixqip_4QRsLcKBo=.a7ffb1b7-68f2-4295-a7f3-cf3c3d4252d7@github.com>
Message-ID: <a32U3g6FKvGOMOsYyVkpf1OX8SHgpyJeCtIsSkXc4cc=.527ec58f-c7b0-44a3-9125-918ed1ed333d@github.com>

On Mon, 21 Nov 2022 16:19:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 561:
>> 
>>> 559:             // Reduce if required.
>>> 560:             // if (numAdds >= maxAdds) {
>>> 561:             if (numAdds > 32 - bitsPerLimb) {
>> 
>> if we allow this number of additions, `setProduct(SmallValue)` might overflow in the future. Currently it's safe - we only create a limited set of SmallValues, and they are all small enough to avoid this risk.
>> `getSmallValue` allows numbers up to `bitsPerLimb` bits. I think we can adjust that.
>
> Sorry, I did not get the ideas.  Did you meant to adjust the implementation of getSmallValue to allow 32 bits int value?

Apologies, I was looking at the wrong branch, didn't notice `setProduct(SmallValue)` also does a reduce if required.

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

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

From djelinski at openjdk.org  Tue Nov 22 09:00:25 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Nov 2022 09:00:25 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
Message-ID: <nsKqVBHkmdnniWGF2OQfbiQaAV3o_j5MCYxg90dYOLQ=.43a9cc46-083d-48ae-a8f6-bb6129e8280d@github.com>

On Sat, 19 Nov 2022 07:17:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?  With this update, the result will be 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 incrementally with one additional commit since the last revision:
> 
>   remove duplicated bench test

Now that `reduce` is called as needed, how do we guarantee that `ECOperations.multiply` will remain constant-time, i.e. call `reduce` a fixed number of times regardless of the input?

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

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

From pminborg at openjdk.org  Tue Nov 22 09:11:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 09:11:44 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework Acquisition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/88ed3aa2..0526e3dc

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

  Stats: 249 lines in 19 files changed: 66 ins; 91 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From pminborg at openjdk.org  Tue Nov 22 09:11:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 09:11:44 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
 <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
 <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>
Message-ID: <LI4GrAv6ZiaCaopZaAhzdzyCpchKYlV43-0W0aObAeU=.020fac2b-6e3d-4911-9f5a-13673f9ce7b0@github.com>

On Mon, 21 Nov 2022 20:06:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
>>> 
>>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
>> 
>> Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.
>
> Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already.

I have reworked Acquisition. I think we could merge the old and new way in a separate PR.

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

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

From alanb at openjdk.org  Tue Nov 22 09:34:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 09:34:36 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
 <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
 <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>
Message-ID: <CHWjD0UP6P-l-JvOzxkaosyV6qcfXEtjPwpgSVDz2PU=.7c420616-8bc4-43de-8e32-91d2f1d4d0ff@github.com>

On Mon, 21 Nov 2022 15:29:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments.

The faraway use sites look much better now. The performance sensitive usages need close attention. Can you summarise the changes to DatagramChannel, are you creating a NoOpScopeAcquisition for every  send/receive? This is low level code where we do do something different to avoid the try-with-resources.

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

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

From duke at openjdk.org  Tue Nov 22 09:38:12 2022
From: duke at openjdk.org (Ismael Juma)
Date: Tue, 22 Nov 2022 09:38:12 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <vrCPeO8q_rSPwnS51968i5vGlFh4Z-xxQxkT9LWkYuQ=.55b3889b-80c5-4823-a2f8-1a7e9368ae2d@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

> because this PR is touching several low level and performance critical code paths

Indeed. Have we verified that performance doesn't regress with these changes?

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

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

From mcimadamore at openjdk.org  Tue Nov 22 09:38:15 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Nov 2022 09:38:15 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:

> 912:          * If so, make a copy to put the dst data in.
> 913:          */
> 914:         @SuppressWarnings("try")

After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).

src/java.base/share/classes/java/nio/Buffer.java line 827:

> 825: 
> 826:                 @Override
> 827:                 public Runnable acquireSessionOrNull(Buffer buffer, boolean async) {

If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this:


Buffer b = ...
try {
    // use buffer.address();
} finally {
    Reference.reachabilityFence(b);
}


We could transform to this:


Buffer b = ...
acquire(b); // calls MemorySessionImpl.acquire0 if session is not null
try {
    // use buffer.address();
} finally {
    release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case)
}

This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:

> 588:                                         int pos)
> 589:             throws IOException {
> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {

Why was the old code not using reachability fences? Bug or feature?

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

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

From mcimadamore at openjdk.org  Tue Nov 22 09:42:23 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Nov 2022 09:42:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>

On Tue, 22 Nov 2022 09:32:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
> 
>> 588:                                         int pos)
>> 589:             throws IOException {
>> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {
> 
> Why was the old code not using reachability fences? Bug or feature?

I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing).

Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code?

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

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

From alexander.krumeich at gmail.com  Tue Nov 22 09:56:54 2022
From: alexander.krumeich at gmail.com (Alexander Krumeich)
Date: Tue, 22 Nov 2022 10:56:54 +0100
Subject: Undo deprecation of brainpool EC
In-Reply-To: <42B141BE-86C4-4B36-8054-A174096FB269@gmail.com>
References: <A1F21AE2-F30C-4D2F-BD4D-76605886AC97f-i.de@s-web.de>
 <27e37532-be19-3ccd-8d8c-6a19c2b3dda2@oracle.com>
 <B1B4FF4B-6717-426D-B22E-02BAD36327CDf-i.de@s-web.de>
 <42B141BE-86C4-4B36-8054-A174096FB269@gmail.com>
Message-ID: <CALeLr1n7GBSkfUY8KYd07eDvif9anfhGCMjXTTS=r9CHMWdJhQ@mail.gmail.com>

Hi there!

Brainpool curves are mandatory for products/projects in which the
German government is a stakeholder. BSI Technical Guidelines require
the use of brainpoolP256r1, brainpoolP384r1, and the brainpoolP512r1
that Benjamin already mentioned (thanks, Benjamin, for raising this
issue). As for use cases, ECDSA and TLS are a must.

It would be very convenient to see the brainpool curves re-introduced
to OpenJDK!

Thank you for considering this.


   Alexander

On Mon, Nov 21, 2022 at 7:49 AM Xuelei Fan <xuelei.f at gmail.com> wrote:
>
> Hi,
>
> As I?m working on this area recently, I will see if I can contribute.  But it may be no easier than JDK 21.  If you don?t mind, I may ask for more requirement details later and help for testing.
>
> Thanks,
> Xuelei
>
> > On Nov 15, 2022, at 11:23 PM, <benjamin.marwell at f-i.de> <benjamin.marwell at f-i.de> wrote:
> >
> > Hi Xuelei and Sean,
> >
> > We use/see mostly brainpoolP512r1. But it is not just us!
> >
> >> , although I will note that the IANA registry
> >>   still lists them as not recommended for TLS [1].
> >
> > I agree that brainpoolP512r1 are not particularly interesting when it comes to TLS,
> > but we still see server certificates (not the TLS algo) created with brainpoolP512r1, as well as keystores.
> > Not being able to connect due to certificate validation errors OR
> > not being able to read a (somewhat) recently created keystore was astonishing, to say the least.
> >
> >> And with
> >>   recently added support for EdDSA and the future with PQC, it's not
> >>   likely we will circle back to them.
> >
> > This is not about which algorithm is "better" or "can be replaced".
> > It is only about "what should (still) be supported, because NIST and BSI still list them".
> >
> >>    We are ok with a contribution,
> >
> > In my opinion, this is a major breaking change for this reason and should not wait for contributions.
> >
> > - Ben
> >
> >
> > ?On 15.11.22, 15:35, "security-dev on behalf of Sean Mullan" <security-dev-retn at openjdk.org on behalf of sean.mullan at oracle.com> wrote:
> >
> >    Hi,
> >
> >    Thanks for your questions about brainpool. See below for more details.
> >
> >    On 11/14/22 3:36 AM, benjamin.marwell at f-i.de wrote:
> >> 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.
> >
> >    The word "deprecated" may have been the wrong word to use when referring
> >    to the brainpool curves, although I will note that the IANA registry
> >    still lists them as not recommended for TLS [1].
> >
> >    We don't have any issues with the brainpool curves as we do for
> >    some of the other legacy curves. But, these curves were implemented in
> >    native C code and we changed the structure of the JDK EC implementation
> >    such that all curves that were implemented in C were removed. The
> >    remaining curves that we do support are implemented in Java and use
> >    modern techniques and complete formulas.
> >
> >    It has not been a priority for us to re-implement brainpool. And with
> >    recently added support for EdDSA and the future with PQC, it's not
> >    likely we will circle back to them.
> >
> >    We are ok with a contribution, but they would need to be done using
> >    the current design structure and using complete formulas.
> >
> >    --Sean
> >
> >    [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
> >
> >>
> >> 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
> >>
>

From duke at openjdk.org  Tue Nov 22 10:23:04 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 22 Nov 2022 10:23:04 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <UwTUKJq45-sC2tDcnUGqv1Uwv9cVn7etUEBK88WJhvw=.f30994f7-a292-43f7-a9c7-5d68abfead96@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 43:

> 41:     // try (var guard = NIO_ACCESS.acquireSession(bb)) {
> 42:     //     performOperation(bb.address());
> 43:     // }

Again, updating?this?comment was?missed:
Suggestion:

    // try (var guard = NIO_ACCESS.acquireScope(bb)) {
    //     performOperation(guard.address());
    // }

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

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

From alanb at openjdk.org  Tue Nov 22 12:00:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 12:00:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <4GRnrg0zNGXoQdiG3uL9JeQyj4bdDVubzv0oMoIuSnM=.1dabdf13-e8b7-477d-86d0-20e5ba2f47bf@github.com>

On Tue, 22 Nov 2022 09:29:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/java.base/share/classes/java/nio/Buffer.java line 827:
> 
>> 825: 
>> 826:                 @Override
>> 827:                 public Runnable acquireSessionOrNull(Buffer buffer, boolean async) {
> 
> If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this:
> 
> 
> Buffer b = ...
> try {
>     // use buffer.address();
> } finally {
>     Reference.reachabilityFence(b);
> }
> 
> 
> We could transform to this:
> 
> 
> Buffer b = ...
> acquire(b); // calls MemorySessionImpl.acquire0 if session is not null
> try {
>     // use buffer.address();
> } finally {
>     release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case)
> }
> 
> This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too.

The AutoCloseable experiment was interesting to try but I think you are right, acquire try { .. } finally release would be simpler and also remove the concerns about the performance critical code paths.

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

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

From alanb at openjdk.org  Tue Nov 22 12:00:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 12:00:24 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
 <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>
Message-ID: <WHS_9EM_JrRB2ZtSQmTO4qJLhOjPv5XCP0iGLbiqQ0k=.75963d9c-1c9b-4506-b234-74e8658e0d9a@github.com>

On Tue, 22 Nov 2022 09:38:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
>> 
>>> 588:                                         int pos)
>>> 589:             throws IOException {
>>> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {
>> 
>> Why was the old code not using reachability fences? Bug or feature?
>
> I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing).
> 
> Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code?

Yes, once the memory/linker APIs are permanent then the SCTP implementation would be a good candidate to redo.

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

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

From pminborg at openjdk.org  Tue Nov 22 13:52:22 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 13:52:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>

On Tue, 22 Nov 2022 09:23:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:
> 
>> 912:          * If so, make a copy to put the dst data in.
>> 913:          */
>> 914:         @SuppressWarnings("try")
> 
> After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).

Well spotted. I will remove the guarding here.

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

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

From pminborg at openjdk.org  Tue Nov 22 14:01:39 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 14:01:39 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v10]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <VU9F8S77u_MTYUEeJNuEIVQzsDSvFjj5IrAp81VPJOw=.8408fba0-e45a-4551-9a41-9255e39640b1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant guard and fix comment permanently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/0526e3dc..06c764ca

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

  Stats: 59 lines in 2 files changed: 19 ins; 26 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From thartmann at openjdk.org  Tue Nov 22 15:25:42 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Nov 2022 15:25:42 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v21]
In-Reply-To: <EseUb0cgdeigmu9nNWflTuRMLKo6T0nEruj3TaPqfYQ=.bedc9bf5-5f1f-48be-8846-0064a88036a0@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
 <Bt4UNZU2itTeHs_2ojFCD64AXpGPiI8gveUtRg5mea0=.2926b137-f31e-4505-9a96-815e4f5ab851@github.com>
 <EseUb0cgdeigmu9nNWflTuRMLKo6T0nEruj3TaPqfYQ=.bedc9bf5-5f1f-48be-8846-0064a88036a0@github.com>
Message-ID: <K2ZrVCTZ9ZPdbTZRncB_cBAB_PoluPuy0bwzMTmWqZQ=.37ea58fb-e6f0-4a4b-9742-c59c84ac2fb9@github.com>

On Mon, 21 Nov 2022 17:42:28 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Overall, looks good. Just one minor cleanup suggestion.
>> 
>> I've submitted the latest patch for testing (hs-tier1 - hs-tier4).
>
> @iwanowww Hope the extra tests passed? (Or do you have to re-run them on the latest patch again?)

I fixed the test issue with [JDK-8297382](https://bugs.openjdk.org/browse/JDK-8297382) but this also caused a regression with one of the crypto tests: [JDK-8297417](https://bugs.openjdk.org/browse/JDK-8297417). @vpaprotsk, @sviswa7 could you please have a look at this?

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

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

From duke at openjdk.org  Tue Nov 22 15:30:45 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 22 Nov 2022 15:30:45 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v21]
In-Reply-To: <K2ZrVCTZ9ZPdbTZRncB_cBAB_PoluPuy0bwzMTmWqZQ=.37ea58fb-e6f0-4a4b-9742-c59c84ac2fb9@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <oaQBTRrtslpMJcgFY4XfZBse2Vgo9p1EMqvDzE2fFj8=.a7e037a5-2a7c-4f1b-b846-6f6f6394b21e@github.com>
 <Bt4UNZU2itTeHs_2ojFCD64AXpGPiI8gveUtRg5mea0=.2926b137-f31e-4505-9a96-815e4f5ab851@github.com>
 <EseUb0cgdeigmu9nNWflTuRMLKo6T0nEruj3TaPqfYQ=.bedc9bf5-5f1f-48be-8846-0064a88036a0@github.com>
 <K2ZrVCTZ9ZPdbTZRncB_cBAB_PoluPuy0bwzMTmWqZQ=.37ea58fb-e6f0-4a4b-9742-c59c84ac2fb9@github.com>
Message-ID: <Mneyy4gDLmypoILIjA9Tv800aYfLdoJ-mEBrq5egvXg=.9aa50db3-9eeb-436b-9f60-a3807023edd1@github.com>

On Tue, 22 Nov 2022 15:21:44 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @iwanowww Hope the extra tests passed? (Or do you have to re-run them on the latest patch again?)
>
> I fixed the test issue with [JDK-8297382](https://bugs.openjdk.org/browse/JDK-8297382) but this also caused a regression with one of the crypto tests: [JDK-8297417](https://bugs.openjdk.org/browse/JDK-8297417). @vpaprotsk, @sviswa7 could you please have a look at this?

@TobiHartmann @dholmes-ora Sorry about that, looking

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

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

From xuelei at openjdk.org  Tue Nov 22 16:23:36 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 22 Nov 2022 16:23:36 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <nsKqVBHkmdnniWGF2OQfbiQaAV3o_j5MCYxg90dYOLQ=.43a9cc46-083d-48ae-a8f6-bb6129e8280d@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <nsKqVBHkmdnniWGF2OQfbiQaAV3o_j5MCYxg90dYOLQ=.43a9cc46-083d-48ae-a8f6-bb6129e8280d@github.com>
Message-ID: <w3s5Qa8QT4Pl07fnsKBMBs-bLM-yUyHe3tuZFQo-TCI=.08583b5c-77e2-4816-9ecd-31e0f63c59a4@github.com>

On Tue, 22 Nov 2022 08:58:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Now that `reduce` is called as needed, how do we guarantee that `ECOperations.multiply` will remain constant-time, i.e. call `reduce` a fixed number of times regardless of the input?

As the reducing operation is depends on the numbers of adds (not the number bits), the operation is depends on the formulas, rather than the sensitive information.  For a EC curve, the use of reducing operation is determined, just as what it was used  in the ECOperations.  For example, if a curve for sum operation needs to call reduce at the 3rd product and 5th addition, the operations will always called at that steps.  If I am right, the reduce operation is still called a fixed number of times.

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

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

From mullan at openjdk.org  Tue Nov 22 16:28:25 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 16:28:25 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v6]
In-Reply-To: <ZGRIo_UiX9-dNgwLgQVF-vmBMPzDlHDXFdo7z05M8Kg=.e89c92b2-18f9-491b-98b9-93733152241c@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <ZGRIo_UiX9-dNgwLgQVF-vmBMPzDlHDXFdo7z05M8Kg=.e89c92b2-18f9-491b-98b9-93733152241c@github.com>
Message-ID: <SaQmQgLyf4Up-sElYVMGfnhLTkxQMMAiRqreEM4YKx0=.2244e9fb-2ac0-492f-ba07-1beb8dc480cf@github.com>

On Thu, 17 Nov 2022 23:52:02 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test
>   
>   only in patch2:
>   unchanged:

A couple of initial comments, will finish review later.

src/java.base/share/classes/sun/security/x509/CRLReasonCodeExtension.java line 72:

> 70:      *
> 71:      * @param critical true if the extension is to be treated as critical.
> 72:      * @param reason the enumerated value for the reason code, cannot be null.

s/null/0/

src/java.base/share/classes/sun/security/x509/CRLReasonCodeExtension.java line 76:

> 74:     public CRLReasonCodeExtension(boolean critical, int reason)
> 75:             throws IOException {
> 76:         if (reason == 0) {

Do you also want to reject reason codes < 0?

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

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

From weijun at openjdk.org  Tue Nov 22 16:33:16 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 16:33:16 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
Message-ID: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>

With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.

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

Commit messages:
 - the change

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

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

From weijun at openjdk.org  Tue Nov 22 16:37:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 16:37:40 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v6]
In-Reply-To: <SaQmQgLyf4Up-sElYVMGfnhLTkxQMMAiRqreEM4YKx0=.2244e9fb-2ac0-492f-ba07-1beb8dc480cf@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <ZGRIo_UiX9-dNgwLgQVF-vmBMPzDlHDXFdo7z05M8Kg=.e89c92b2-18f9-491b-98b9-93733152241c@github.com>
 <SaQmQgLyf4Up-sElYVMGfnhLTkxQMMAiRqreEM4YKx0=.2244e9fb-2ac0-492f-ba07-1beb8dc480cf@github.com>
Message-ID: <DQslpGiujxLgKMjW82X0WSj2CrLNwW8_T57Zr1Yigx4=.cafea7fb-24aa-4d0d-b9f5-ef6498c0c732@github.com>

On Tue, 22 Nov 2022 16:22:44 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 test
>>   
>>   only in patch2:
>>   unchanged:
>
> src/java.base/share/classes/sun/security/x509/CRLReasonCodeExtension.java line 76:
> 
>> 74:     public CRLReasonCodeExtension(boolean critical, int reason)
>> 75:             throws IOException {
>> 76:         if (reason == 0) {
> 
> Do you also want to reject reason codes < 0?

Yes, I will. Negative number is illegal for ASN.1 Enumerated Type, and the `toString` method of this class returns `UNSPECIFIED` which is equivalent to 0.

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

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

From weijun at openjdk.org  Tue Nov 22 16:44:56 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 16:44:56 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v7]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <1rIpzFbi0gN5LPayC0Irj2Y7PRGvdh5ymgYMBnGIPJE=.682d9af3-28b3-4ce6-9a34-252da8b22cc8@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  reason code must be positive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/509ce1c6..ff49dffe

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

  Stats: 6 lines in 3 files changed: 1 ins; 0 del; 5 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 xuelei at openjdk.org  Tue Nov 22 17:08:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 22 Nov 2022 17:08:28 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
Message-ID: <wNpHYPOISp_ceiHc4uqreMuilcDm-8VjcdVScwMTJzo=.2c30784a-520a-40cf-ba3c-049c2ae6b400@github.com>

On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.

src/java.base/share/classes/javax/security/auth/Subject.java line 329:

> 327:      * subject is {@code null} before the first call of {@code callAs()}.
> 328:      * <p>
> 329:      * When a new thread is created, its current subject is the same as

what about change from"when" to "if", in case some implementation still create a new thread?

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

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

From weijun at openjdk.org  Tue Nov 22 17:15:18 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 17:15:18 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <wNpHYPOISp_ceiHc4uqreMuilcDm-8VjcdVScwMTJzo=.2c30784a-520a-40cf-ba3c-049c2ae6b400@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
 <wNpHYPOISp_ceiHc4uqreMuilcDm-8VjcdVScwMTJzo=.2c30784a-520a-40cf-ba3c-049c2ae6b400@github.com>
Message-ID: <AAnH0jBa4Ynb626jwyhjDGqa-7V4ziuzpZ79w_ejDJY=.f7dd2a50-9755-49b5-93ba-99faaa9778db@github.com>

On Tue, 22 Nov 2022 17:05:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 329:
> 
>> 327:      * subject is {@code null} before the first call of {@code callAs()}.
>> 328:      * <p>
>> 329:      * When a new thread is created, its current subject is the same as
> 
> what about change from"when" to "if", in case some implementation still create a new thread?

This is not about the implementation of this method, which might or might not allow the current subject to be inherited in a new thread. The spec change is telling the users of this method that such inheritance is no longer guaranteed. We are still not sure if the future implementation of this method can guarantee that, but given it's already broken now, we'd better remove this requirement. We can add if later if we can do that.

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

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

From duke at openjdk.org  Tue Nov 22 17:20:56 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 22 Nov 2022 17:20:56 GMT
Subject: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512
 instructions [v22]
In-Reply-To: <encTlnf9qtjfjtVa-jDoWJMcUc6AwRtSDj7tk_OyBM0=.9728a3c6-6009-4873-9cb3-28ac8c262282@github.com>
References: <wDtmoM8mMKTxF31fFaHywCrQgFOV1wrL5wCV4ytlrEg=.9ae8ecbf-9386-4aee-9764-2ebafb541e07@github.com>
 <encTlnf9qtjfjtVa-jDoWJMcUc6AwRtSDj7tk_OyBM0=.9728a3c6-6009-4873-9cb3-28ac8c262282@github.com>
Message-ID: <pyx9hvqbMbB8kvwH1WaWugTgbOjOqSmWCIooIeST7CY=.add869f5-b444-4ef9-8513-53902c7b040c@github.com>

On Thu, 17 Nov 2022 20:42:27 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:
> 
>   remove early return

@robcasloz Update to [JDK-8297417](https://bugs.openjdk.org/browse/JDK-8297417) (since I don't have an account on the bugtracker yet to update there) 

Not able to reproduce it on Linux yet. The seed should make it deterministic.. but nothing. Resurrecting's my windows sandbox to see if I can reproduce on windows (only difference on windows is the intrinsic function register linkage. However problem there would make the problem _very_ deterministic.. I think)

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

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

From mpowers at openjdk.org  Tue Nov 22 17:36:33 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 22 Nov 2022 17:36:33 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v7]
In-Reply-To: <1rIpzFbi0gN5LPayC0Irj2Y7PRGvdh5ymgYMBnGIPJE=.682d9af3-28b3-4ce6-9a34-252da8b22cc8@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <1rIpzFbi0gN5LPayC0Irj2Y7PRGvdh5ymgYMBnGIPJE=.682d9af3-28b3-4ce6-9a34-252da8b22cc8@github.com>
Message-ID: <wa7G19UE3qS7AlC5T6gL9UdKwruq-TazpB0mCdKiDII=.0e4534a5-4bad-41ae-90b3-d8b8fc98b773@github.com>

On Tue, 22 Nov 2022 16:44:56 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reason code must be positive

src/java.base/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java line 87:

> 85:             throws IOException {
> 86:         if (names == null || names.isEmpty()) {
> 87:             throw new IllegalArgumentException("names should not be empty");

"names cannot be null or empty"

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

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

From weijun at openjdk.org  Tue Nov 22 17:42:06 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 17:42:06 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  IssuerAlternativeNameExtension names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/ff49dffe..6c44155e

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 mpowers at openjdk.org  Tue Nov 22 17:42:06 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 22 Nov 2022 17:42:06 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
Message-ID: <PkxO5a_0Mg_fdTK3L7ouhvaxluUhA6Fdc2evqqCkZaQ=.0ab8a3d2-ee89-4af9-b8a8-72b0067e57f7@github.com>

On Tue, 22 Nov 2022 17:36:30 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IssuerAlternativeNameExtension names

LGTM

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

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

From xuelei at openjdk.org  Tue Nov 22 18:09:12 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 22 Nov 2022 18:09:12 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
Message-ID: <XG6xnLyijt5jBcINnpUDUxY6bQE1Wjpa3Uf85I41tvk=.b45096bf-39f2-4e79-9f7a-90b5415348df@github.com>

On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.

Marked as reviewed by xuelei (Reviewer).

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

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

From xuelei at openjdk.org  Tue Nov 22 18:09:14 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 22 Nov 2022 18:09:14 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <AAnH0jBa4Ynb626jwyhjDGqa-7V4ziuzpZ79w_ejDJY=.f7dd2a50-9755-49b5-93ba-99faaa9778db@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
 <wNpHYPOISp_ceiHc4uqreMuilcDm-8VjcdVScwMTJzo=.2c30784a-520a-40cf-ba3c-049c2ae6b400@github.com>
 <AAnH0jBa4Ynb626jwyhjDGqa-7V4ziuzpZ79w_ejDJY=.f7dd2a50-9755-49b5-93ba-99faaa9778db@github.com>
Message-ID: <QqDn9gra6762w9tvaPD-qmCTcTUnnS7PEy5q7KBDpo4=.99f2fb3c-717d-455e-97c0-6768894836e6@github.com>

On Tue, 22 Nov 2022 17:11:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/security/auth/Subject.java line 329:
>> 
>>> 327:      * subject is {@code null} before the first call of {@code callAs()}.
>>> 328:      * <p>
>>> 329:      * When a new thread is created, its current subject is the same as
>> 
>> what about change from"when" to "if", in case some implementation still create a new thread?
>
> This is not about the implementation of this method, which might or might not allow the current subject to be inherited in a new thread. The spec change is telling the users of this method that such inheritance is no longer guaranteed. We are still not sure if the future implementation of this method can guarantee that, but given it's already broken now, we'd better remove this requirement. We can add if later if we can do that.

Hm, it may still apply if the current subject to be inherited in a new thread.  I fine to remove this section.  A release note and known issue may be filed to notify the behavior change and issue.

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

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

From xuelei at openjdk.org  Tue Nov 22 18:24:41 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 22 Nov 2022 18:24:41 GMT
Subject: Integrated: 8295011: EC point multiplication improvement for secp256r1
In-Reply-To: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
References: <XVADRVaL1do8TVTn0Naxsyu022bk0nyuGFARmqlWmDg=.ecce8f7c-4a0e-4fc8-b0e9-ad732882d493@github.com>
Message-ID: <wwgNN2IgdJ-ShU2wSHeuK_N9iYkdA0FOlNnU6D_LCh8=.f6c620a4-1f48-4024-ae39-dd55121c8610@github.com>

On Thu, 27 Oct 2022 22:10:15 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The EC point multiplication for secp256r1 could be improved for better performance, by using more efficient algorithm and pre-computation.  Improvement for other curves are similar, but will be addressed in separated PRs.
> 
> The basic idea is using pre-computed tables and safe table select in order to speed up the point multiplication and keep is safe.  Before this patch applied, a secp256r1 point multiplication operation needs 256 double operations and 78 addition operations.  With this patch, it is reduced to 16 double operations and 64 addition operations.  **If assuming the performance for double and addition operations is about the same (double operation is a little bit faster actually), the new point multiplication implementation performance is about 4 times ((256+78)/(16+64)) of the current implementation.**
> 
> ## SSLHandshake.java benchmark
> ### Use secp256r1 as the named group
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using secp256r1 (Set the System property, "jdk.tls.namedGroups" to "secp256r1") as the key exchange algorithm in TLS connections:
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7976.334 ? 96.877  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   315.783 ?  1.208  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   235.646 ?  1.356  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   230.759 ?  1.789  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7830.289 ? 58.584  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   253.827 ?  0.690  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   171.944 ?  0.667  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   169.383 ?  0.593  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same.  It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption.  TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about 35% for named group secp256r1 based TLS connections..**
> 
> ### Use default TLS named groups
> The following are TLS benchmarking (test/micro/org/openjdk/bench/java/security/SSLHandshake.java) results by using key exchange algorithms in TLS connections.  In the current JDK implementation, the EC keys are generated for both secp256r1 and x25519 curves, and x25519 is the preferred curves. 
> 
> Benchmark with this patch:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7620.615 ? 62.459  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   746.924 ?  6.549  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   456.066 ?  1.440  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   396.189 ?  2.275  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt     Score    Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  7605.177 ? 55.961  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   544.333 ? 23.431  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   335.259 ?  1.926  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   269.422 ?  1.531  ops/s
> 
> 
> Per the result, the session resumption performance for TLS 1.2 is about the same. It is the expected result as there is no EC point multiplication involved for TLS 1.2 session resumption. TLS 1.3 is different as EC key generation is involved in either initial handshake and session resumption.
> 
> **When EC key generation get involved (TLS 1.3 connections and TLS 1.2 initial handshake), the performance improvement is about  36%~47% for default configuration based TLS connections.**
> 
> ## KeyPairGenerators.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/KeyPairGenerators.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  4638.623 ? 93.320  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   710.643 ?  6.404  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.417 ?  1.302  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2355.491 ? 69.584  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   682.144 ?  6.671  ops/s
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark                     (curveName)   Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen    secp256r1  thrpt   15  1642.312 ? 52.155  ops/s
> KeyPairGenerators.keyPairGen    secp384r1  thrpt   15   687.669 ? 30.576  ops/s
> KeyPairGenerators.keyPairGen    secp521r1  thrpt   15   371.854 ?  1.736  ops/s
> KeyPairGenerators.keyPairGen      Ed25519  thrpt   15  2448.139 ?  7.788  ops/s
> KeyPairGenerators.keyPairGen        Ed448  thrpt   15   685.195 ?  4.994  ops/s
> 
> 
> **Per the result, the performance improvement is about 180% for key pair generation performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.
> 
> ## Signatures.java benchmark
> The following are EC key pair generation benchmark (test/micro/org/openjdk/bench/java/security/Signatures.java) results.
> 
> Benchmark with this patch:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  3646.764 ? 28.633  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  3595.674 ? 69.761  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  3633.184 ? 22.236  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  3481.104 ? 21.043  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   631.036 ?  6.154  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.485 ? 18.700  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   615.955 ?  4.598  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   627.193 ?  6.551  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   303.849 ? 19.569  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   308.676 ?  7.002  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   317.306 ?  0.327  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   312.579 ?  1.753  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1192.428 ? 10.424  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1185.397 ?  1.993  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1181.980 ?  2.963  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1105.737 ?  4.339  ops/s
> Signatures.sign        Ed448               64  thrpt   15   332.501 ?  1.471  ops/s
> Signatures.sign        Ed448              512  thrpt   15   324.770 ?  9.631  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   325.833 ?  1.602  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   313.231 ?  1.440  ops/s
> 
> 
> 
> Benchmark before this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1515.924 ?  8.489  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1521.586 ?  7.726  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1499.704 ?  9.704  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1499.392 ?  8.832  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   634.406 ?  8.328  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   633.766 ? 11.965  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   634.608 ?  5.526  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   628.815 ?  3.756  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   313.390 ?  9.728  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   316.420 ?  2.817  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   307.386 ?  3.966  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   315.384 ?  2.243  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1187.227 ?  5.758  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1189.044 ?  5.370  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1182.833 ? 13.186  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1099.599 ?  3.932  ops/s
> Signatures.sign        Ed448               64  thrpt   15   331.810 ?  3.786  ops/s
> Signatures.sign        Ed448              512  thrpt   15   332.885 ?  4.926  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   332.941 ?  4.292  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   318.226 ?  4.141  ops/s
> 
> 
> **Per the result, the performance improvement is about 140% for signature performance for secp256r1.**  Other curves should not be impacted as the point multiplication implementation for them is not updated yet.

This pull request has now been integrated.

Changeset: 260e4dcb
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/260e4dcbfd8bdccdf332c2b6a07990cd14f6bcfb
Stats:     411 lines in 5 files changed: 307 ins; 96 del; 8 mod

8295011: EC point multiplication improvement for secp256r1

Reviewed-by: djelinski, jjiang

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

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

From duke at openjdk.org  Tue Nov 22 19:28:27 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 22 Nov 2022 19:28:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
 <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>
Message-ID: <-3UxCy1TSFrc9DMZZMdsiUpX7i3wOmiTRTHpyRKEjYs=.54eef999-bad4-49ce-9c66-d45fd16fe9b5@github.com>

On Tue, 22 Nov 2022 13:49:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:
>> 
>>> 912:          * If so, make a copy to put the dst data in.
>>> 913:          */
>>> 914:         @SuppressWarnings("try")
>> 
>> After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).
>
> Well spotted. I will remove the guarding here.

This?`@SuppressWarnings` annotation is?no?longer?needed:
Suggestion:

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

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

From rriggs at openjdk.org  Tue Nov 22 19:36:24 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Nov 2022 19:36:24 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
Message-ID: <Cv6EKAsv6w5BElzX0mrCjSup4CE_wVr0NtM968t7AYs=.e4e6fc87-5ddc-4d3a-8120-821223ea6dc2@github.com>

On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.

LGTM, dropping the inaccurate text.  A release note is a good idea.

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

Marked as reviewed by rriggs (Reviewer).

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

From mullan at openjdk.org  Tue Nov 22 19:59:31 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 19:59:31 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
Message-ID: <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>

On Tue, 22 Nov 2022 17:42:06 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IssuerAlternativeNameExtension names

More comments.

src/java.base/share/classes/sun/security/x509/CertificatePoliciesExtension.java line 113:

> 111:     public CertificatePoliciesExtension(Boolean critical,
> 112:             List<PolicyInformation> certPolicies) throws IOException {
> 113:         if (certPolicies == null || certPolicies.isEmpty()) {

You should probably also change `PolicyInformation(CertificatePolicyId policyIdentifier,            Set<PolicyQualifierInfo> policyQualifiers)` to check for a null policyIdentifier and an empty policyQualifiers set.

src/java.base/share/classes/sun/security/x509/Extension.java line 178:

> 176: 
> 177:         Objects.requireNonNull(extensionId,
> 178:                 "Null OID to encode for the extension!");

I would probably drop the exclamation points. And change "Null OID" to "No OID".

src/java.base/share/classes/sun/security/x509/NameConstraintsExtension.java line 142:

> 140:         if (permitted == null && excluded == null) {
> 141:             throw new IllegalArgumentException(
> 142:                     "permitted and exclude cannot both be null");

s/exclude/excluded/

src/java.base/share/classes/sun/security/x509/PolicyMappingsExtension.java line 78:

> 76:      * Create a PolicyMappings with the List of CertificatePolicyMap.
> 77:      *
> 78:      * @param maps the List of CertificatePolicyMap, cannot be null or empty.

Do you want to add similar null checks to the `CertificatePolicyMap` ctor?

src/java.base/share/classes/sun/security/x509/SubjectAlternativeNameExtension.java line 91:

> 89:      */
> 90:     public SubjectAlternativeNameExtension(Boolean critical, GeneralNames names)
> 91:             throws IOException {

`GeneralNames` should probably also be modified so that it cannot contain an empty or null List.

src/java.base/share/classes/sun/security/x509/SubjectInfoAccessExtension.java line 89:

> 87:         if (accessDescriptions == null || accessDescriptions.isEmpty()) {
> 88:             throw new IllegalArgumentException(
> 89:                     "AccessDescription cannot be null or empty");

s/AccessDescription/accessDescriptions/

src/java.base/share/classes/sun/security/x509/SubjectKeyIdentifierExtension.java line 76:

> 74:      */
> 75:     public SubjectKeyIdentifierExtension(byte[] octetString)
> 76:             throws IOException {

Do you want to change the `KeyIdentifer` ctor to check for null instead of letting it throw NPE?

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

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

From mullan at openjdk.org  Tue Nov 22 19:59:33 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 19:59:33 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
Message-ID: <xiHa6jcpYvZbHh4vpJHYmPEYtpYKk3BvxpwvCr2Sikk=.60d49c45-5409-42d7-bb75-473d5efb5945@github.com>

On Tue, 22 Nov 2022 19:46:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   IssuerAlternativeNameExtension names
>
> src/java.base/share/classes/sun/security/x509/NameConstraintsExtension.java line 142:
> 
>> 140:         if (permitted == null && excluded == null) {
>> 141:             throw new IllegalArgumentException(
>> 142:                     "permitted and exclude cannot both be null");
> 
> s/exclude/excluded/

Do you want to add similar checks to the `GeneralSubtree` and `GeneralSubtrees` ctors?

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

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

From mullan at openjdk.org  Tue Nov 22 20:15:42 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 20:15:42 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
Message-ID: <wscRypYRHmTR4z7N9hKe-B9VAeeQLmYvNqN0pACZwSg=.194cf35c-7365-490b-9078-9b25b2178c7d@github.com>

On Tue, 22 Nov 2022 17:42:06 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IssuerAlternativeNameExtension names

A general comment is that since we are adding checks for illegal values to the `*Extension` classes, we should probably go one step further and do the same for all the classes in `sun.security.x509` package. I'm ok if you want to handle this as a separate issue though.

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

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

From weijun at openjdk.org  Tue Nov 22 20:15:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 20:15:42 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
Message-ID: <NzuMeYbAOnJ4VK9_IlW8YDNRQvGZhbfvykkjY9NwYuE=.d17e9fa8-c6cb-48b5-9adf-f42bb0e4e759@github.com>

On Tue, 22 Nov 2022 19:34:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   IssuerAlternativeNameExtension names
>
> src/java.base/share/classes/sun/security/x509/CertificatePoliciesExtension.java line 113:
> 
>> 111:     public CertificatePoliciesExtension(Boolean critical,
>> 112:             List<PolicyInformation> certPolicies) throws IOException {
>> 113:         if (certPolicies == null || certPolicies.isEmpty()) {
> 
> You should probably also change `PolicyInformation(CertificatePolicyId policyIdentifier,            Set<PolicyQualifierInfo> policyQualifiers)` to check for a null policyIdentifier and an empty policyQualifiers set.

I'll check about null `policyIdentifier`. According to https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.4, `policyQualifiers` is OPTIONAL so it can be empty.

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

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

From weijun at openjdk.org  Tue Nov 22 20:28:25 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 20:28:25 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <xiHa6jcpYvZbHh4vpJHYmPEYtpYKk3BvxpwvCr2Sikk=.60d49c45-5409-42d7-bb75-473d5efb5945@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
 <xiHa6jcpYvZbHh4vpJHYmPEYtpYKk3BvxpwvCr2Sikk=.60d49c45-5409-42d7-bb75-473d5efb5945@github.com>
Message-ID: <BDiT_nhV1vuFfoxg255xLxrYaMpDZ9CaoGpXEn96h78=.761a767d-3858-4d30-a6c5-13f1cd2b4911@github.com>

On Tue, 22 Nov 2022 19:49:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/NameConstraintsExtension.java line 142:
>> 
>>> 140:         if (permitted == null && excluded == null) {
>>> 141:             throw new IllegalArgumentException(
>>> 142:                     "permitted and exclude cannot both be null");
>> 
>> s/exclude/excluded/
>
> Do you want to add similar checks to the `GeneralSubtree` and `GeneralSubtrees` ctors?

There are still `add` in `GeneralSubtrees` so technically it can be started with an empty collection. Using `null` already throws an NPE now. I'll add a check in `GeneralSubtree` to reject a null name.

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

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

From weijun at openjdk.org  Tue Nov 22 20:43:23 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 20:43:23 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
Message-ID: <PTmLkXBuosTKPz1qv8hvSn_7NsmCWHf2Iv9kry1U8MQ=.dcddfcae-85da-4176-9918-d89179009874@github.com>

On Tue, 22 Nov 2022 19:53:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   IssuerAlternativeNameExtension names
>
> src/java.base/share/classes/sun/security/x509/SubjectAlternativeNameExtension.java line 91:
> 
>> 89:      */
>> 90:     public SubjectAlternativeNameExtension(Boolean critical, GeneralNames names)
>> 91:             throws IOException {
> 
> `GeneralNames` should probably also be modified so that it cannot contain an empty or null List.

It still has `add` which is used in multiple places. I'll see if I can remove this method and make it immutable.

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

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

From weijun at openjdk.org  Tue Nov 22 20:45:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 20:45:37 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
Message-ID: <fbdPIMR4JCPlvuxFRTQpeZSu4uZay51fgq0Jv9_jbvU=.49a5a85b-b0bf-4b4a-a535-80d340209cac@github.com>

On Tue, 22 Nov 2022 19:56:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   IssuerAlternativeNameExtension names
>
> src/java.base/share/classes/sun/security/x509/SubjectKeyIdentifierExtension.java line 76:
> 
>> 74:      */
>> 75:     public SubjectKeyIdentifierExtension(byte[] octetString)
>> 76:             throws IOException {
> 
> Do you want to change the `KeyIdentifer` ctor to check for null instead of letting it throw NPE?

I'll let it throw NPE. As long as there's no way to create a `KeyIdentifer` with a null array inside, I'm not eager to change the exception type.

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

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

From weijun at openjdk.org  Tue Nov 22 20:53:25 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 20:53:25 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <wscRypYRHmTR4z7N9hKe-B9VAeeQLmYvNqN0pACZwSg=.194cf35c-7365-490b-9078-9b25b2178c7d@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <wscRypYRHmTR4z7N9hKe-B9VAeeQLmYvNqN0pACZwSg=.194cf35c-7365-490b-9078-9b25b2178c7d@github.com>
Message-ID: <a-WTEtAU-5ZsLny1zfmQnA7xvRbs9Dzd_r37e1wmm2Q=.f8a70f5e-2e5c-4296-b791-286fd514a42e@github.com>

On Tue, 22 Nov 2022 20:09:02 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> A general comment is that since we are adding checks for illegal values to the `*Extension` classes, we should probably go one step further and do the same for all the classes in `sun.security.x509` package. I'm ok if you want to handle this as a separate issue though.

I see. I'll work on making `GeneralNames` immutable within this issue. The `NameConstraintsExtension` and `GeneralSubtrees` case is complicated where mutability is still needed by the merge action.

> src/java.base/share/classes/sun/security/x509/Extension.java line 178:
> 
>> 176: 
>> 177:         Objects.requireNonNull(extensionId,
>> 178:                 "Null OID to encode for the extension!");
> 
> I would probably drop the exclamation points. And change "Null OID" to "No OID".

OK.

> src/java.base/share/classes/sun/security/x509/PolicyMappingsExtension.java line 78:
> 
>> 76:      * Create a PolicyMappings with the List of CertificatePolicyMap.
>> 77:      *
>> 78:      * @param maps the List of CertificatePolicyMap, cannot be null or empty.
> 
> Do you want to add similar null checks to the `CertificatePolicyMap` ctor?

Yes.

> src/java.base/share/classes/sun/security/x509/SubjectInfoAccessExtension.java line 89:
> 
>> 87:         if (accessDescriptions == null || accessDescriptions.isEmpty()) {
>> 88:             throw new IllegalArgumentException(
>> 89:                     "AccessDescription cannot be null or empty");
> 
> s/AccessDescription/accessDescriptions/

OK.

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

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

From weijun at openjdk.org  Tue Nov 22 21:04:25 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 21:04:25 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
Message-ID: <FQaqfmyev5r8174-NH7jYPLOEMWkDccV1jveWCU7-2g=.1f027061-0ce1-4d2d-ba83-2106ecacb588@github.com>

On Tue, 22 Nov 2022 17:42:06 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IssuerAlternativeNameExtension names

Oh, when parsing a `SubjectAlternativeNameExtension` or an `IssuerAlternativeNameExtension`, an empty `GeneralNames` is returned when the content is empty. I would like to study more about it in another bug.

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

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

From mullan at openjdk.org  Tue Nov 22 21:35:25 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 21:35:25 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
Message-ID: <87GKfq-aRrlwj0Hn3u4a_tMI88e_m8YkbrUwmGeECYc=.b14c3e7c-6c45-4d8b-9f7d-f75e3a64dd14@github.com>

On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.

Marked as reviewed by mullan (Reviewer).

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

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

From weijun at openjdk.org  Tue Nov 22 21:43:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 21:43:42 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v9]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <AJg-Qb1xKc6KlcvFNNiztfstzGTgL0xJQurt2IT6ROU=.f0e42bb3-3c53-4400-9a07-26acf04ed9c3@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  more null checks and comments update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/6c44155e..b76ce017

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

  Stats: 14 lines in 7 files changed: 5 ins; 0 del; 9 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  Tue Nov 22 21:43:42 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 21:43:42 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
Message-ID: <AXNqZ4jpzWTO3nQhLubL5ExYpDGHnEZEYqbHe54lFko=.a1a59d7e-e447-471d-a032-740629d0b91a@github.com>

On Tue, 22 Nov 2022 17:42:06 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IssuerAlternativeNameExtension names

New commit pushed. Haven't touched `GeneralSubtrees` and `GeneralNames`.

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

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

From mullan at openjdk.org  Tue Nov 22 21:55:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 21:55:29 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <tE-XCaAOq7dpJa0np6pcDQJyTD9hSPPWQ7JEYDY9gPw=.14f640d7-aa20-4ee4-bb5e-e17c3aa582a0@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>
 <tE-XCaAOq7dpJa0np6pcDQJyTD9hSPPWQ7JEYDY9gPw=.14f640d7-aa20-4ee4-bb5e-e17c3aa582a0@github.com>
Message-ID: <epAQxLZ0QUsOPhbOWTAL5lvt0pkG3F7E36xBnzxvXFs=.c4085c5e-0a5e-48a5-add2-2b2f61fa8893@github.com>

On Wed, 16 Nov 2022 17:39:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
>>> 
>>> > The wording in this PR specifically refers to the protocol version that
>>> 
>>> was specified. It isn't covering other optional protocols that may be supported.
>>> 
>>> Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version. 
>> 
>> Where in the javadoc APIs does it say that? I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.
>
>> > _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
>> > > The wording in this PR specifically refers to the protocol version that
>> > 
>> > 
>> > was specified. It isn't covering other optional protocols that may be supported.
>> > Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version.
>> 
>> Where in the javadoc APIs does it say that?
> 
> The Javadoc APIs specification does not say it is referring to TLS protocol version.  In the standard algorithm documentation, the word "SSLContext Algorithms" is used and here is an example:
> 
> 
> Algorithm Name | Description
> -- | --
> TLSv1.2 | Supports?RFC 5246: TLS version 1.2; may support other SSL/TLS versions
> 
> 
>> I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.
> 
> Yes.  So we cannot assume that the literal SSLContext algorithm is the only supported TLS version for an JSSE provider, including the SunJSSE provider.

I plan to withdraw this PR for now. @XueleiFan you make some good points that the implementation note is too specific (there are other failure scenarios) and also that a connection may still be successfully established using other protocols if the implementation supports other protocols than what was requested.

I really think that what is needed is a better class description in the javadoc of the `SSLContext` class about what the protocol passed to `getInstance` means. Something similar to what is documented in the JSSE Developer's Guide: https://docs.oracle.com/en/java/javase/19/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-9BAC1902-A203-4422-8163-61D64ADD2FF7
I will open an RFE for that.

After that we can add more information on specific implementation specific scenarios, such as what is being proposed here.

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

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

From mullan at openjdk.org  Tue Nov 22 21:55:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 21:55:29 GMT
Subject: Withdrawn: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <Y2CwFxsCj0raGJqogEPpqUVzXKApSaetELstP9oc8aU=.a0e48979-ca20-4b3b-9ce7-f704a89940bd@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.org  Tue Nov 22 22:04:57 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 22 Nov 2022 22:04:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
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: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@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.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Prefix RFC titles with `RFC NNNN:`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/30ce235f..c29092d8

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

  Stats: 325 lines in 165 files changed: 4 ins; 4 del; 317 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 mpowers at openjdk.org  Tue Nov 22 22:14:07 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 22 Nov 2022 22:14:07 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
 [v3]
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <gfEB05XGx6kKKorFns9AzR71Cdc1osa6GH_m8FVhQV0=.424447a3-abfa-48d8-abaf-19d97653b1b4@github.com>

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

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  javadoc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10716/files
  - new: https://git.openjdk.org/jdk/pull/10716/files/2dc18e5c..80be7e6b

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

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

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

From mullan at openjdk.org  Tue Nov 22 22:17:03 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 22:17:03 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v9]
In-Reply-To: <AJg-Qb1xKc6KlcvFNNiztfstzGTgL0xJQurt2IT6ROU=.f0e42bb3-3c53-4400-9a07-26acf04ed9c3@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <AJg-Qb1xKc6KlcvFNNiztfstzGTgL0xJQurt2IT6ROU=.f0e42bb3-3c53-4400-9a07-26acf04ed9c3@github.com>
Message-ID: <FOFU9krqhZx5tBZ7UnL4q145UkhwzY69PpJ3q2V3eT8=.ca5c8ae7-ee23-42e2-be8a-3b98f3feb852@github.com>

On Tue, 22 Nov 2022 21:43:42 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more null checks and comments update

Other than the comments about the test bugids, LGTM, if these are the last changes you are making. So I'm approving.

test/jdk/sun/security/x509/Extensions/DefaultCriticality.java line 28:

> 26:  * @summary Change default criticality of policy mappings and policy constraints
> 27:             certificate extensions
> 28:  * @bug 8059916 8296742

I don't think the bugid needs to be listed here. This has nothing to do with what is being tested, it is just a side-effect of the internal API behavior changing, and details can be seen in the commit log, if needed.

test/jdk/sun/security/x509/X509CertImpl/V3Certificate.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8049237 8242151 8296742

I also don't think the bugid needs to be listed here, for same reason.

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

Marked as reviewed by mullan (Reviewer).

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

From mullan at openjdk.org  Tue Nov 22 22:17:05 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 22:17:05 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <FQaqfmyev5r8174-NH7jYPLOEMWkDccV1jveWCU7-2g=.1f027061-0ce1-4d2d-ba83-2106ecacb588@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <FQaqfmyev5r8174-NH7jYPLOEMWkDccV1jveWCU7-2g=.1f027061-0ce1-4d2d-ba83-2106ecacb588@github.com>
Message-ID: <RrKj2-3T62Vrp__QD52pFAgMPIN1sE_XJ0HQ89Dv5yU=.5d0a6656-ccbc-45c8-8f5a-f3d781b9f79d@github.com>

On Tue, 22 Nov 2022 21:02:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Oh, when parsing a `SubjectAlternativeNameExtension` or an `IssuerAlternativeNameExtension`, an empty `GeneralNames` is returned when the content is empty. I would like to study more about it in another bug.

Ok.

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

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

From mullan at openjdk.org  Tue Nov 22 22:17:07 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 22:17:07 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <BDiT_nhV1vuFfoxg255xLxrYaMpDZ9CaoGpXEn96h78=.761a767d-3858-4d30-a6c5-13f1cd2b4911@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
 <xiHa6jcpYvZbHh4vpJHYmPEYtpYKk3BvxpwvCr2Sikk=.60d49c45-5409-42d7-bb75-473d5efb5945@github.com>
 <BDiT_nhV1vuFfoxg255xLxrYaMpDZ9CaoGpXEn96h78=.761a767d-3858-4d30-a6c5-13f1cd2b4911@github.com>
Message-ID: <kRmDMDiCFStjvV2oIFMCBhSl2yrRnV9jq1gMXI3lLmo=.33e1de50-1eeb-4094-8461-7d8cbf04e88b@github.com>

On Tue, 22 Nov 2022 20:24:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Do you want to add similar checks to the `GeneralSubtree` and `GeneralSubtrees` ctors?
>
> I'll add a check in `GeneralSubtree` to reject a null name. `GeneralSubtrees` is complicated. The intersect and reduce methods make it mutable, so I have to retain all the add and remove methods. Fortunately, its `encode` method still allows an empty tree. If we want to be RFC 5128-compliant and reject the empty tree, I suggest we fix it in a new bug.

Ok.

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

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

From mullan at openjdk.org  Tue Nov 22 22:17:11 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 22:17:11 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v8]
In-Reply-To: <fbdPIMR4JCPlvuxFRTQpeZSu4uZay51fgq0Jv9_jbvU=.49a5a85b-b0bf-4b4a-a535-80d340209cac@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
 <avj_zalCh7evbZKudFL17rtFQmz_DRQR6UZwTb0zsGE=.7ea43716-3bfa-45fd-84bd-f283d2872dc1@github.com>
 <1gGpg_CdPPB-LKiweuzA8kWaGsX3sXhi1tS7l5yjE58=.c62b34ff-2aef-43b9-ab0a-b410dc323b06@github.com>
 <fbdPIMR4JCPlvuxFRTQpeZSu4uZay51fgq0Jv9_jbvU=.49a5a85b-b0bf-4b4a-a535-80d340209cac@github.com>
Message-ID: <-CPiruwk-dqPx_fPmX1FMjaaJTAdNXiF6PBk1GCrn6s=.b270c9fe-733e-4f1b-a62c-7db928e2ca68@github.com>

On Tue, 22 Nov 2022 20:43:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/SubjectKeyIdentifierExtension.java line 76:
>> 
>>> 74:      */
>>> 75:     public SubjectKeyIdentifierExtension(byte[] octetString)
>>> 76:             throws IOException {
>> 
>> Do you want to change the `KeyIdentifer` ctor to check for null instead of letting it throw NPE?
>
> I'll let it throw NPE. As long as there's no way to create a `KeyIdentifer` with a null array inside, I'm not eager to change the exception type.

Ok.

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

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

From weijun at openjdk.org  Tue Nov 22 22:22:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 22:22:53 GMT
Subject: RFR: 8296742: Illegal X509 Extension should not be created [v10]
In-Reply-To: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
References: <2J2jOz3DQ95rm1nqcol-Tqn2Zkt5r1L6cpXmTa98Tf4=.c43e0170-fd63-4c8e-a59b-06fe6ae01f4b@github.com>
Message-ID: <Xv1AF4he504EkrRNiTLoseNkzEEbGOOW-y_rD4nu42k=.b1028dae-9239-432f-b3de-31fe132a1b00@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 able to find a non-null extension value to write out.
> 
> More fine comments in the code change.

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

  remove bug id from tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11137/files
  - new: https://git.openjdk.org/jdk/pull/11137/files/b76ce017..66ad905c

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 mpowers at openjdk.org  Tue Nov 22 22:24:47 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 22 Nov 2022 22:24:47 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
 [v3]
In-Reply-To: <gfEB05XGx6kKKorFns9AzR71Cdc1osa6GH_m8FVhQV0=.424447a3-abfa-48d8-abaf-19d97653b1b4@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
 <gfEB05XGx6kKKorFns9AzR71Cdc1osa6GH_m8FVhQV0=.424447a3-abfa-48d8-abaf-19d97653b1b4@github.com>
Message-ID: <y65SIaZqF57XcDaFZCJy3JNJ-f9EVVMMZAjqpqNKx4U=.24f06da9-1912-44f1-94eb-f84e20c97da1@github.com>

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

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

Verified with testing that /dev/urandom is used when overrides are removed from Compatibility.java and SecurityTools.java.

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

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

From weijun at openjdk.org  Tue Nov 22 22:24:56 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 22:24:56 GMT
Subject: Integrated: 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: <soEZFn6aG1Y99VWgavMDU5UPRu-ua5g8ljVrKwFtPUQ=.c69c6752-c2cd-4400-97e6-a6cc31369183@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.

This pull request has now been integrated.

Changeset: e174558c
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e174558cad836e56ac31725813abf7d8540c9919
Stats:     342 lines in 28 files changed: 250 ins; 39 del; 53 mod

8296742: Illegal X509 Extension should not be created

Reviewed-by: mullan

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

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

From weijun at openjdk.org  Tue Nov 22 22:37:32 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 22 Nov 2022 22:37:32 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw IOExceptions
Message-ID: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>

This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:

- Remove unnecessary `throws IOException` in code and spec
- Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
- More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
- Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
- Some unused methods removed

The only actual changes (still trivial) are:
- Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
- In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/11302/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297065
  Stats: 1139 lines in 109 files changed: 58 ins; 426 del; 655 mod
  Patch: https://git.openjdk.org/jdk/pull/11302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11302/head:pull/11302

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

From mstjohns at comcast.net  Tue Nov 22 23:29:24 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 22 Nov 2022 18:29:24 -0500
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <wg2w74XFXgR8uqgc9k-Khx0TyDatrTePl7lT-HDADDo=.5974d00c-95bc-4b42-a8e8-42631ce37026@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <MhOjIIg9TntJoNUHWK54oNmv6Eslhn1mz5nSOusdh80=.828ae267-6650-411e-b77f-8585026a84bf@github.com>
 <wg2w74XFXgR8uqgc9k-Khx0TyDatrTePl7lT-HDADDo=.5974d00c-95bc-4b42-a8e8-42631ce37026@github.com>
Message-ID: <cedc1d65-8309-f994-0ae0-555ab8567742@comcast.net>

On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
> On Thu, 17 Nov 2022 23:07:46 GMT, Johannes Waigel <duke at openjdk.org> wrote:
>
>> Checking the instance is fundamental to find out the real cause.
> Please don't do that in a serious application.  The exception stack is belong to implementation details, and may change any time.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11012

Hi - Sorry - just getting back to the list after a few days away.

Given that this is a plugin provider for the PCSC access classes, and 
that CardException doesn't always pass through the details in a 
comprehensible way from the underlying cause, having access to 
PCSCException makes a lot of sense, and as far as I can tell is not a 
violation of the general plugin contract.

To make it even more useful, adding a "public long getErrorCode()" 
method to PCSCException would help with the cases where a code that 
isn't actually an? SCard* related code causing the PCSC exception.

But -

Wouldn't this also require a change to the module definition file?

Mike



From valeriep at openjdk.org  Wed Nov 23 01:33:02 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 23 Nov 2022 01:33:02 GMT
Subject: RFR: 7181214: Need specify SKF translateKey(SecurityKey) method
 requires instance of PBEKey for PBKDF2 algorithms
Message-ID: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>

Anyone can help reviewing this trivial RFE? Mostly just making clarifications on exception messages as submitter requested. Enhanced existing test case to check on this particular scenario.

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

Commit messages:
 - 7181214: Need specify SKF translateKey(SecurityKey) method requires instance of PBEKey for PBKDF2 algorithms

Changes: https://git.openjdk.org/jdk/pull/11306/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11306&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7181214
  Stats: 64 lines in 2 files changed: 47 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11306.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11306/head:pull/11306

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

From xuelei at openjdk.org  Wed Nov 23 03:24:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 23 Nov 2022 03:24:58 GMT
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <cedc1d65-8309-f994-0ae0-555ab8567742@comcast.net>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <cedc1d65-8309-f994-0ae0-555ab8567742@comcast.net>
Message-ID: <oRDJJt_pp6JXSGofsVQb_hwdD08VeflQM0bbjnBo9Iw=.33f378f4-cc21-4799-af25-505f8052e2c0@github.com>

On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns <mstjohns at comcast.net> wrote:

> ? CardException doesn't always pass through the details in a comprehensible way from the underlying cause, ?

Does it sound like a cause that the public APIs are not sufficient? Alternatively, if it is possible to update the public APIs instead?

Best,
Xuelei


> On Nov 22, 2022, at 6:59 PM, mlbridge[bot] ***@***.***> wrote:
> 
> 
> Mailing list message from Michael StJohns ***@***.***> on security-dev ***@***.***>:
> 
> On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
> 
> Hi - Sorry - just getting back to the list after a few days away.
> 
> Given that this is a plugin provider for the PCSC access classes, and
> that CardException doesn't always pass through the details in a
> comprehensible way from the underlying cause, having access to
> PCSCException makes a lot of sense, and as far as I can tell is not a
> violation of the general plugin contract.
> 
> To make it even more useful, adding a "public long getErrorCode()"
> method to PCSCException would help with the cases where a code that
> isn't actually an? SCard* related code causing the PCSC exception.
> 
> But -
> 
> Wouldn't this also require a change to the module definition file?
> 
> Mike
> 
> ?
> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/11012#issuecomment-1324485877>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSB3EAII4OJ5UKKSZQAJHDWJWCC5ANCNFSM6AAAAAARY2PXGY>.
> You are receiving this because you commented.
>

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

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

From xuelei at openjdk.org  Wed Nov 23 03:28:20 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 23 Nov 2022 03:28:20 GMT
Subject: RFR: 7181214: Need specify SKF translateKey(SecurityKey) method
 requires instance of PBEKey for PBKDF2 algorithms
In-Reply-To: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
References: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
Message-ID: <aJGyTvPpghMNzbDr-l97PWdFPZiZjkNSR5N-22rKAcQ=.d66f381c-5f92-4741-a5a0-824d945bed5e@github.com>

On Wed, 23 Nov 2022 01:25:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Anyone can help reviewing this trivial RFE? Mostly just making clarifications on exception messages as submitter requested. Enhanced existing test case to check on this particular scenario.

It looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From mpowers at openjdk.org  Wed Nov 23 04:13:21 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 23 Nov 2022 04:13:21 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions
In-Reply-To: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
Message-ID: <71jEKQZBlLMGccZy47PDYRH0n3bP3LaxpC-brT59Dsw=.581af41b-cf71-467f-bee6-e0fde4698a4f@github.com>

On Tue, 22 Nov 2022 22:29:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
> 
> - Remove unnecessary `throws IOException` in code and spec
> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
> - Some unused methods removed
> - `DerOutputStream` is final
> 
> The only actual changes (still trivial) are:
> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.

src/java.base/share/classes/sun/security/x509/CRLExtensions.java line 151:

> 149: 
> 150:         DerOutputStream tmp = new DerOutputStream();
> 151:         if (isExplicit)

Use curley braces.

src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java line 121:

> 119:         boolean hasOnlyUserCerts, boolean hasOnlyCACerts,
> 120:         boolean hasOnlyAttributeCerts, boolean isIndirectCRL)
> 121:             throws IOException {

Don't you need `throws IllegalArgumentException`?

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

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

From mpowers at openjdk.org  Wed Nov 23 04:22:58 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 23 Nov 2022 04:22:58 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions
In-Reply-To: <71jEKQZBlLMGccZy47PDYRH0n3bP3LaxpC-brT59Dsw=.581af41b-cf71-467f-bee6-e0fde4698a4f@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <71jEKQZBlLMGccZy47PDYRH0n3bP3LaxpC-brT59Dsw=.581af41b-cf71-467f-bee6-e0fde4698a4f@github.com>
Message-ID: <nxbHr374NqINpGlLJlY_bQTAgxpivIWTYlDz3QPyXS0=.e88758ed-8bf0-48ab-952b-be4117013701@github.com>

On Wed, 23 Nov 2022 03:55:11 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java line 121:
> 
>> 119:         boolean hasOnlyUserCerts, boolean hasOnlyCACerts,
>> 120:         boolean hasOnlyAttributeCerts, boolean isIndirectCRL)
>> 121:             throws IOException {
> 
> Don't you need `throws IllegalArgumentException`?

Maybe not  - it's a runtime exception and those are special.

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

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

From kbarrett at openjdk.org  Wed Nov 23 05:02:09 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 05:02:09 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
 <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
 <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>
Message-ID: <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com>

On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? [...]

A PR to address JDK-8252584 would be welcomed by me. Just do the process for
Style Guide changes (see the Style Guide or previous PRs for such). I don't
expect it would be very controversial. I think the only reason it hasn't
already happened is because nobody has gotten around to it, or felt the need
for it.

JDK-8250269 touches a bit more code (mostly in stubGenerator_x86_64 and
macroAssembler_x86_32), but also seems like it should be straightforward.

> > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.
> 
> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)

You are right that the Windows-conditionalized uses are in non-HotSpot code.
I missed that context when skimming through the changes.  Since Visual Studio
is always C++ (even though the shared files are written as C), using alignas
with appropriate conditionalization in those files should be fine.

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

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

From kbarrett at openjdk.org  Wed Nov 23 05:24:24 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 05:24:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@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>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
Message-ID: <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>

On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

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

I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted.

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

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

From xuelei at openjdk.org  Wed Nov 23 06:21:05 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 23 Nov 2022 06:21:05 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v6]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <Y5zjBJTCln4Ww8UvnpuSxwqbJydNKmyylhqB5AP5nhI=.8d5ab765-a439-4f93-aa5e-d52a98362b4d@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be reduced if required in EC limbs operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs if required for EC limbs operations.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1417.507 ?  5.809  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1412.620 ?  7.040  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1417.364 ?  6.643  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1364.720 ? 44.354  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   609.924 ?  9.858  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   610.873 ?  5.519  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   608.573 ? 13.324  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   597.802 ?  7.074  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   301.954 ?  6.449  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   300.774 ?  5.849  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   295.831 ?  8.423  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   276.258 ? 43.146  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1171.878 ?  4.187  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1175.175 ?  4.611  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1168.459 ?  5.750  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1086.906 ?  6.514  ops/s
> Signatures.sign        Ed448               64  thrpt   15   326.475 ?  3.274  ops/s
> Signatures.sign        Ed448              512  thrpt   15   328.709 ?  3.867  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   315.480 ? 15.377  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   312.388 ?  1.067  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1377.447 ? 38.889  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1403.149 ?  5.151  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1401.101 ?  6.937  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1381.855 ? 10.606  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   595.979 ?  1.967  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   592.419 ?  6.087  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   581.800 ? 18.815  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   583.224 ?  9.856  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   264.772 ? 36.883  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   302.084 ?  1.074  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   296.619 ?  3.272  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   290.112 ?  5.085  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1163.293 ?  4.266  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1157.093 ?  8.145  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1140.900 ?  8.660  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1053.233 ? 40.591  ops/s
> Signatures.sign        Ed448               64  thrpt   15   317.509 ?  6.870  ops/s
> Signatures.sign        Ed448              512  thrpt   15   320.975 ?  1.534  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   322.157 ?  1.914  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   303.532 ?  6.419  ops/s
> 
> 
> From the numbers, it looks like the performance impact is limited.  Based on this update, the performance could get rewarded by using less limbs.  For examples if using less limbs for secp256r1/secp384r1/secp521r1/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 eight commits:

 - Merge
 - remove duplicated bench test
 - Merge master
 - missed reduce
 - reduce if needed
 - add the key pair generation bench code
 - remove tabs
 - 8295010: EC limbs addition and subtraction limit

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

Changes: https://git.openjdk.org/jdk/pull/10624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=05
  Stats: 141 lines in 8 files changed: 84 ins; 34 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

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

From xuelei at openjdk.org  Wed Nov 23 08:07:22 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 23 Nov 2022 08:07:22 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <DFEGuptXrvJdjk7tvjnfYrGowpo5Ht0Ld6vTrVgB4PE=.b15b75e0-5269-42b4-abab-3370cc82c397@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <IeNqLbReNSKudHHptSXHrs3GHU6C3ZUaMgdhPOVw-RQ=.6877fdb5-f4e3-4cca-ac62-700c79eaf75b@github.com>
 <DFEGuptXrvJdjk7tvjnfYrGowpo5Ht0Ld6vTrVgB4PE=.b15b75e0-5269-42b4-abab-3370cc82c397@github.com>
Message-ID: <COA71eIf1yTfDX05C2FQC9myEfkArXleQJoT5QHgBxs=.5c54a0ff-60f9-4fac-b258-2bfab186a4cb@github.com>

On Mon, 21 Nov 2022 08:15:53 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> I may run it again after the integration of multiplicative inversion and point multiplication improvement.

After the integration of the improvement above, here is the benchmark numbers with this patch:

Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1084.556 ? 135.637  ops/s
Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1168.663 ?  25.072  ops/s
Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1186.863 ?  16.224  ops/s
Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1095.034 ?   6.462  ops/s
Signatures.EdDSA.sign              Ed448               64  thrpt   15   323.771 ?   2.156  ops/s
Signatures.EdDSA.sign              Ed448              512  thrpt   15   326.995 ?   2.101  ops/s
Signatures.EdDSA.sign              Ed448             2048  thrpt   15   320.799 ?   5.452  ops/s
Signatures.EdDSA.sign              Ed448            16384  thrpt   15   317.715 ?   2.554  ops/s
Signatures.sign                secp256r1               64  thrpt   15  4072.636 ?  22.441  ops/s
Signatures.sign                secp256r1              512  thrpt   15  4048.822 ?  40.769  ops/s
Signatures.sign                secp256r1             2048  thrpt   15  4042.884 ?  20.147  ops/s
Signatures.sign                secp256r1            16384  thrpt   15  3911.856 ?  12.039  ops/s
Signatures.sign                secp384r1               64  thrpt   15   634.203 ?   4.532  ops/s
Signatures.sign                secp384r1              512  thrpt   15   637.623 ?   1.592  ops/s
Signatures.sign                secp384r1             2048  thrpt   15   620.283 ?  10.014  ops/s
Signatures.sign                secp384r1            16384  thrpt   15   622.617 ?   5.695  ops/s
Signatures.sign                secp521r1               64  thrpt   15   311.957 ?   5.420  ops/s
Signatures.sign                secp521r1              512  thrpt   15   316.605 ?   2.204  ops/s
Signatures.sign                secp521r1             2048  thrpt   15   316.700 ?   1.654  ops/s
Signatures.sign                secp521r1            16384  thrpt   15   309.599 ?   7.167  ops/s


and the numbers without this patch:

Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1138.578 ?  57.908  ops/s
Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1172.242 ?  17.180  ops/s
Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1163.793 ?  21.095  ops/s
Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1093.856 ?   5.964  ops/s
Signatures.EdDSA.sign              Ed448               64  thrpt   15   324.089 ?   2.894  ops/s
Signatures.EdDSA.sign              Ed448              512  thrpt   15   323.580 ?   1.437  ops/s
Signatures.EdDSA.sign              Ed448             2048  thrpt   15   323.680 ?   2.555  ops/s
Signatures.EdDSA.sign              Ed448            16384  thrpt   15   310.641 ?   2.256  ops/s
Signatures.sign                secp256r1               64  thrpt   15  4070.733 ?  27.059  ops/s
Signatures.sign                secp256r1              512  thrpt   15  4061.835 ?  18.776  ops/s
Signatures.sign                secp256r1             2048  thrpt   15  4041.226 ?  19.082  ops/s
Signatures.sign                secp256r1            16384  thrpt   15  3893.323 ?  11.869  ops/s
Signatures.sign                secp384r1               64  thrpt   15   632.924 ?   8.273  ops/s
Signatures.sign                secp384r1              512  thrpt   15   628.807 ?   7.604  ops/s
Signatures.sign                secp384r1             2048  thrpt   15   631.052 ?   1.782  ops/s
Signatures.sign                secp384r1            16384  thrpt   15   530.402 ? 122.967  ops/s
Signatures.sign                secp521r1               64  thrpt   15   316.634 ?   1.724  ops/s
Signatures.sign                secp521r1              512  thrpt   15   315.830 ?   2.333  ops/s
Signatures.sign                secp521r1             2048  thrpt   15   315.855 ?   1.093  ops/s
Signatures.sign                secp521r1            16384  thrpt   15   315.019 ?   1.124  ops/s

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

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

From djelinski at openjdk.org  Wed Nov 23 11:29:24 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 23 Nov 2022 11:29:24 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v6]
In-Reply-To: <Y5zjBJTCln4Ww8UvnpuSxwqbJydNKmyylhqB5AP5nhI=.8d5ab765-a439-4f93-aa5e-d52a98362b4d@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <Y5zjBJTCln4Ww8UvnpuSxwqbJydNKmyylhqB5AP5nhI=.8d5ab765-a439-4f93-aa5e-d52a98362b4d@github.com>
Message-ID: <Ub0hiyXfiCQ_pmekLUQ5Rwp55-H7WHfK29z_qEbTVqQ=.0e06af0b-2abe-4b9c-9a04-49a1e8917bca@github.com>

On Wed, 23 Nov 2022 06:21:05 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 eight commits:
> 
>  - Merge
>  - remove duplicated bench test
>  - Merge master
>  - missed reduce
>  - reduce if needed
>  - add the key pair generation bench code
>  - remove tabs
>  - 8295010: EC limbs addition and subtraction limit

Well my concern was that when we call `setSum(ProjectivePoint, ProjectivePoint)`, the number of `reduce` calls depends on the `numAdds` values on all coordinates of both input parameters.
If you take a look at the default multiplier's `pointMultiples`, you'll notice that `numAdds` is `0` on all coordinates of the first two `pointMultiples` and `1` on all coordinates of the remaining `pointMultiples`. 

Fortunately `lookup` (specifically `IntegerPolynomial.conditionalSet`) [always overwrites](https://github.com/openjdk/jdk/blob/a244bf4dbfd769f9602633c4473288f66ce7d06c/src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java#L686) `numAdds`, so the returned point's `numAdds` are always copied from the last point in the lookup table. As long as the second parameter of `setSum` always comes from `lookup` (and in your patch it does), we should be fine.

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

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

From djelinski at openjdk.org  Wed Nov 23 11:32:27 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 23 Nov 2022 11:32:27 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v6]
In-Reply-To: <Y5zjBJTCln4Ww8UvnpuSxwqbJydNKmyylhqB5AP5nhI=.8d5ab765-a439-4f93-aa5e-d52a98362b4d@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <Y5zjBJTCln4Ww8UvnpuSxwqbJydNKmyylhqB5AP5nhI=.8d5ab765-a439-4f93-aa5e-d52a98362b4d@github.com>
Message-ID: <BSPXmSvM5g0u2PDuIJas54qjMlfBGFF9ixoPOwr2unk=.f365e22d-f4b4-49cb-9c54-1528b0c0f68f@github.com>

On Wed, 23 Nov 2022 06:21:05 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 eight commits:
> 
>  - Merge
>  - remove duplicated bench test
>  - Merge master
>  - missed reduce
>  - reduce if needed
>  - add the key pair generation bench code
>  - remove tabs
>  - 8295010: EC limbs addition and subtraction limit

Marked as reviewed by djelinski (Committer).

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

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

From pminborg at openjdk.org  Wed Nov 23 12:21:07 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 12:21:07 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v11]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <Kjp4PS4MZ9xnK5J6RH0LkSqmiG4REMfF2HT62Ca67Mc=.f433fbb7-5a98-494f-a91e-6796d96e6edf@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Refactor to try-finally handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/06c764ca..88ae68b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=09-10

  Stats: 677 lines in 20 files changed: 286 ins; 152 del; 239 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From alanb at openjdk.org  Wed Nov 23 12:37:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Nov 2022 12:37:18 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
Message-ID: <4ppDHNKRhU5Pnca8jBUfIE760zR7eYyKzmqBDgn8ufs=.b10ba3d0-23a3-42ad-a5fc-fd732cc5c623@github.com>

On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.

Just re-reading the javadoc for Subject.callAs. It doesn't say anything about inheritance so there shouldn't be any expectation that Subject is inherited, so I think the change proposed here is okay. For another PR but I think the callAs javadoc could say a bit more about the Subject being set for the bounded execution of the given task. When the task completes, the current Subject is null or reverts to its previous value in the current thread.

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

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

From pminborg at openjdk.org  Wed Nov 23 12:39:40 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 12:39:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/88ae68b8..682b6f5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=10-11

  Stats: 23 lines in 9 files changed: 1 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From weijun at openjdk.org  Wed Nov 23 12:44:36 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Nov 2022 12:44:36 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions
In-Reply-To: <71jEKQZBlLMGccZy47PDYRH0n3bP3LaxpC-brT59Dsw=.581af41b-cf71-467f-bee6-e0fde4698a4f@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <71jEKQZBlLMGccZy47PDYRH0n3bP3LaxpC-brT59Dsw=.581af41b-cf71-467f-bee6-e0fde4698a4f@github.com>
Message-ID: <mfXyWfu6x0Eee5E0CDUGVozmygSIz6dvSG0GgkGdDLY=.27be9a1a-0b09-41e7-a669-d0d5d46e749a@github.com>

On Wed, 23 Nov 2022 02:28:44 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> src/java.base/share/classes/sun/security/x509/CRLExtensions.java line 151:
> 
>> 149: 
>> 150:         DerOutputStream tmp = new DerOutputStream();
>> 151:         if (isExplicit)
> 
> Use curley braces.

I'll do. This is new code.

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

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

From weijun at openjdk.org  Wed Nov 23 12:44:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Nov 2022 12:44:37 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions
In-Reply-To: <nxbHr374NqINpGlLJlY_bQTAgxpivIWTYlDz3QPyXS0=.e88758ed-8bf0-48ab-952b-be4117013701@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <71jEKQZBlLMGccZy47PDYRH0n3bP3LaxpC-brT59Dsw=.581af41b-cf71-467f-bee6-e0fde4698a4f@github.com>
 <nxbHr374NqINpGlLJlY_bQTAgxpivIWTYlDz3QPyXS0=.e88758ed-8bf0-48ab-952b-be4117013701@github.com>
Message-ID: <ih5DYolL9R0QpI8ZZTLRN3qNDCzl6pvFYi90LQbsvhQ=.2844cebc-f5ff-422c-814c-bc967ff27524@github.com>

On Wed, 23 Nov 2022 04:19:42 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java line 121:
>> 
>>> 119:         boolean hasOnlyUserCerts, boolean hasOnlyCACerts,
>>> 120:         boolean hasOnlyAttributeCerts, boolean isIndirectCRL)
>>> 121:             throws IOException {
>> 
>> Don't you need `throws IllegalArgumentException`?
>
> Maybe not  - it's a runtime exception and those are special.

Yes, that's the reason. BTW, I did update the javadoc to list the new reason.

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From dfuchs at openjdk.org  Wed Nov 23 12:47:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:47:43 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
Message-ID: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>

On Tue, 22 Nov 2022 22:04:57 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.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix RFC titles with `RFC NNNN:`

Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From weijun at openjdk.org  Wed Nov 23 14:08:33 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Nov 2022 14:08:33 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions
In-Reply-To: <mfXyWfu6x0Eee5E0CDUGVozmygSIz6dvSG0GgkGdDLY=.27be9a1a-0b09-41e7-a669-d0d5d46e749a@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <71jEKQZBlLMGccZy47PDYRH0n3bP3LaxpC-brT59Dsw=.581af41b-cf71-467f-bee6-e0fde4698a4f@github.com>
 <mfXyWfu6x0Eee5E0CDUGVozmygSIz6dvSG0GgkGdDLY=.27be9a1a-0b09-41e7-a669-d0d5d46e749a@github.com>
Message-ID: <1GVSX-5RTVH6yC1MonRGtkWfcX3MuTRaE8Aujpb1BMg=.1b4cba01-a742-4e47-86ea-11570c067995@github.com>

On Wed, 23 Nov 2022 12:40:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/CRLExtensions.java line 151:
>> 
>>> 149: 
>>> 150:         DerOutputStream tmp = new DerOutputStream();
>>> 151:         if (isExplicit)
>> 
>> Use curley braces.
>
> I'll do. This is new code.

I just went through 17 such cases. Each of them is actually old code that was inside a try-catch block. I feel hesitated to update them. Keep them untouched is actually easier for code review.

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From weijun at openjdk.org  Wed Nov 23 14:09:26 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Nov 2022 14:09:26 GMT
Subject: RFR: 7181214: Need specify SKF translateKey(SecurityKey) method
 requires instance of PBEKey for PBKDF2 algorithms
In-Reply-To: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
References: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
Message-ID: <fO3kUp_zmGxxg85FhxPL1SI6v-5GYKavAXdHQkBcKhU=.4facd56b-0c56-43ca-843a-cb7cecee0bb2@github.com>

On Wed, 23 Nov 2022 01:25:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Anyone can help reviewing this trivial RFE? Mostly just making clarifications on exception messages as submitter requested. Enhanced existing test case to check on this particular scenario.

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11306

From weijun at openjdk.org  Wed Nov 23 14:17:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Nov 2022 14:17:27 GMT
Subject: RFR: 8297276: Remove thread text from Subject.current
In-Reply-To: <4ppDHNKRhU5Pnca8jBUfIE760zR7eYyKzmqBDgn8ufs=.b10ba3d0-23a3-42ad-a5fc-fd732cc5c623@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
 <4ppDHNKRhU5Pnca8jBUfIE760zR7eYyKzmqBDgn8ufs=.b10ba3d0-23a3-42ad-a5fc-fd732cc5c623@github.com>
Message-ID: <fn1CBqzEF_Y1znqtcn5LqAmVN4cLvWNbwSbBhxCQCBM=.f80eb437-fc58-44e9-b868-e1c675622434@github.com>

On Wed, 23 Nov 2022 12:35:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.
>
> Just re-reading the javadoc for Subject.callAs. It doesn't say anything about inheritance so there shouldn't be any expectation that Subject is inherited, so I think the change proposed here is okay. For another PR but I think the callAs javadoc could say a bit more about the Subject being set for the bounded execution of the given task. When the task completes, the current Subject is null or reverts to its previous value in the current thread.

@AlanBateman You are right. The `callAs` method is very short and only mentions "the current subject". My original idea is to describe everything about what "the current subject" means inside the `current()` method, which now talks about how it's set and reset. Do you think it's clearer to duplicate some of these words in `callAs` as well? Both the two methods currently have a `@see` pointing to the other.

-------------

PR: https://git.openjdk.org/jdk/pull/11292

From mcimadamore at openjdk.org  Wed Nov 23 16:17:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 23 Nov 2022 16:17:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
Message-ID: <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>

On Wed, 23 Nov 2022 12:39:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125:

> 123:      * @see #releaseScope(Buffer, MemorySessionImpl)
> 124:      */
> 125:     MemorySessionImpl acquireScopeOrNull(Buffer buffer);

I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null.

I suggest to rename:

* `acquireSession` -> `acquireSessionAsRunnable`
* `acquireScopeOrNull` -> `acquireSession`
* `releaseScope` -> `releaseSession`

Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release.

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164:

> 162:     int pageSize();
> 163: 
> 164:     sealed interface ScopeAcquisition extends AutoCloseable {

Is this still needed?

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From jjg at openjdk.org  Wed Nov 23 16:47:22 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 16:47:22 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
 <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
Message-ID: <1chEBBDbhD7PiPdKybnhe3Bq2DyO-GTGaxTU5qtw7C4=.8191c086-d70c-4bc1-b03e-d781b1268f07@github.com>

On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

That was not intentional, and is a result of the scripted edit. I will look to revert those changes and/or change the tooling to ignore those packages.

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From mstjohns at comcast.net  Wed Nov 23 17:21:22 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Wed, 23 Nov 2022 12:21:22 -0500
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <oRDJJt_pp6JXSGofsVQb_hwdD08VeflQM0bbjnBo9Iw=.33f378f4-cc21-4799-af25-505f8052e2c0@github.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <cedc1d65-8309-f994-0ae0-555ab8567742@comcast.net>
 <oRDJJt_pp6JXSGofsVQb_hwdD08VeflQM0bbjnBo9Iw=.33f378f4-cc21-4799-af25-505f8052e2c0@github.com>
Message-ID: <95161595-069f-59f3-4892-db256af4ead9@comcast.net>

On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote:
> On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns <mstjohns at comcast.net> wrote:
>
>> ? CardException doesn't always pass through the details in a comprehensible way from the underlying cause, ?
> Does it sound like a cause that the public APIs are not sufficient? Alternatively, if it is possible to update the public APIs instead?

I once actually wondered why PCSCException existed, rather than using or 
extending CardException (e.g. besides simply to have a place to put all 
of the SCARD related error messages).

So you'd suggest extending CardException with a "getErrorCode()" method, 
a constructor that takes an error code in addition to a message, and a 
protected errorCode field.?? Have PCSCException extend CardException and 
provide the current single argument constructor to create a 
CardException with an error message based on the error code?

One of the main reasons I would like a change like this is to deal with 
Window's semi-weird behavior when listing terminals and no terminals are 
found.? Right now I have to parse the returned message looking for 
"SCARD_E_SERVICE_STOPPED" and if that occurs, I return an empty list of 
terminals rather than continuing the throw.? There are a few of those 
codes where it makes sense to translate them into different behavior.

Mike




>
> Best,
> Xuelei
>
>
>> On Nov 22, 2022, at 6:59 PM, mlbridge[bot] ***@***.***> wrote:
>>
>>
>> Mailing list message from Michael StJohns ***@***.***> on security-dev ***@***.***>:
>>
>> On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
>>
>> Hi - Sorry - just getting back to the list after a few days away.
>>
>> Given that this is a plugin provider for the PCSC access classes, and
>> that CardException doesn't always pass through the details in a
>> comprehensible way from the underlying cause, having access to
>> PCSCException makes a lot of sense, and as far as I can tell is not a
>> violation of the general plugin contract.
>>
>> To make it even more useful, adding a "public long getErrorCode()"
>> method to PCSCException would help with the cases where a code that
>> isn't actually an? SCard* related code causing the PCSC exception.
>>
>> But -
>>
>> Wouldn't this also require a change to the module definition file?
>>
>> Mike
>>
>> ?
>> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/11012#issuecomment-1324485877>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSB3EAII4OJ5UKKSZQAJHDWJWCC5ANCNFSM6AAAAAARY2PXGY>.
>> You are receiving this because you commented.
>>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11012



From pminborg at openjdk.org  Wed Nov 23 17:40:24 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 17:40:24 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
 <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>
Message-ID: <R-M2NOUc9X1tA-Pe-Jm81A06WpAJ-NizI8IliAGDMR4=.e8c0957c-f78b-4573-8e68-90e90df6c101@github.com>

On Wed, 23 Nov 2022 16:14:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup
>
> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125:
> 
>> 123:      * @see #releaseScope(Buffer, MemorySessionImpl)
>> 124:      */
>> 125:     MemorySessionImpl acquireScopeOrNull(Buffer buffer);
> 
> I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null.
> 
> I suggest to rename:
> 
> * `acquireSession` -> `acquireSessionAsRunnable`
> * `acquireScopeOrNull` -> `acquireSession`
> * `releaseScope` -> `releaseSession`
> 
> Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release.

The name "scope" was used in anticipation of the new proposed Java 20 naming. But I can change it back to session again. We could always rename later.

> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164:
> 
>> 162:     int pageSize();
>> 163: 
>> 164:     sealed interface ScopeAcquisition extends AutoCloseable {
> 
> Is this still needed?

Well spotted.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From xuelei.f at gmail.com  Wed Nov 23 18:07:09 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 23 Nov 2022 10:07:09 -0800
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <95161595-069f-59f3-4892-db256af4ead9@comcast.net>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <cedc1d65-8309-f994-0ae0-555ab8567742@comcast.net>
 <oRDJJt_pp6JXSGofsVQb_hwdD08VeflQM0bbjnBo9Iw=.33f378f4-cc21-4799-af25-505f8052e2c0@github.com>
 <95161595-069f-59f3-4892-db256af4ead9@comcast.net>
Message-ID: <0E91CC67-A84B-4F6D-9701-DBA4BB79C2D8@gmail.com>

I?m not very sure what the update public APIs may look like.  If we are able to collect the possible card exception reasons, the design of CertPathValidatorException and CertPathValidatorException.BasicReason could be a reference.

Xuelei

> On Nov 23, 2022, at 9:21 AM, Michael StJohns <mstjohns at comcast.net> wrote:
> 
> On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote:
>> On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns <mstjohns at comcast.net> wrote:
>> 
>>> ? CardException doesn't always pass through the details in a comprehensible way from the underlying cause, ?
>> Does it sound like a cause that the public APIs are not sufficient? Alternatively, if it is possible to update the public APIs instead?
> 
> I once actually wondered why PCSCException existed, rather than using or extending CardException (e.g. besides simply to have a place to put all of the SCARD related error messages).
> 
> So you'd suggest extending CardException with a "getErrorCode()" method, a constructor that takes an error code in addition to a message, and a protected errorCode field.   Have PCSCException extend CardException and provide the current single argument constructor to create a CardException with an error message based on the error code?
> 
> One of the main reasons I would like a change like this is to deal with Window's semi-weird behavior when listing terminals and no terminals are found.  Right now I have to parse the returned message looking for "SCARD_E_SERVICE_STOPPED" and if that occurs, I return an empty list of terminals rather than continuing the throw.  There are a few of those codes where it makes sense to translate them into different behavior.
> 
> Mike
> 
> 
> 
> 
>> 
>> Best,
>> Xuelei
>> 
>> 
>>> On Nov 22, 2022, at 6:59 PM, mlbridge[bot] ***@***.***> wrote:
>>> 
>>> 
>>> Mailing list message from Michael StJohns ***@***.***> on security-dev ***@***.***>:
>>> 
>>> On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
>>> 
>>> Hi - Sorry - just getting back to the list after a few days away.
>>> 
>>> Given that this is a plugin provider for the PCSC access classes, and
>>> that CardException doesn't always pass through the details in a
>>> comprehensible way from the underlying cause, having access to
>>> PCSCException makes a lot of sense, and as far as I can tell is not a
>>> violation of the general plugin contract.
>>> 
>>> To make it even more useful, adding a "public long getErrorCode()"
>>> method to PCSCException would help with the cases where a code that
>>> isn't actually an? SCard* related code causing the PCSC exception.
>>> 
>>> But -
>>> 
>>> Wouldn't this also require a change to the module definition file?
>>> 
>>> Mike
>>> 
>>> ?
>>> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/11012#issuecomment-1324485877>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSB3EAII4OJ5UKKSZQAJHDWJWCC5ANCNFSM6AAAAAARY2PXGY>.
>>> You are receiving this because you commented.
>>> 
>> -------------
>> 
>> PR: https://git.openjdk.org/jdk/pull/11012
> 
> 


From valeriep at openjdk.org  Wed Nov 23 18:50:30 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 23 Nov 2022 18:50:30 GMT
Subject: RFR: 7181214: Need specify SKF translateKey(SecurityKey) method
 requires instance of PBEKey for PBKDF2 algorithms
In-Reply-To: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
References: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
Message-ID: <HmvTi-Ef2OAEhZV81_oVdIHPm38Fy8cdxWFPKoj4X7g=.e0a1e7ce-3c64-4c18-967b-a333c360bc60@github.com>

On Wed, 23 Nov 2022 01:25:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Anyone can help reviewing this trivial RFE? Mostly just making clarifications on exception messages as submitter requested. Enhanced existing test case to check on this particular scenario.

Thanks for the review~

-------------

PR: https://git.openjdk.org/jdk/pull/11306

From valeriep at openjdk.org  Wed Nov 23 18:52:36 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 23 Nov 2022 18:52:36 GMT
Subject: Integrated: 7181214: Need specify SKF translateKey(SecurityKey) method
 requires instance of PBEKey for PBKDF2 algorithms
In-Reply-To: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
References: <JYye5cpb0-5cDQNQtUoakxXD_fTwJgNPt9-giEwBdRg=.42dac7fe-f142-4ece-af6a-75dc372c2dee@github.com>
Message-ID: <3Q9kxoI5DQyMfyaSmLL0mv6qJ0suTiBOw9FWBzmO8ro=.4b47628c-85ba-46eb-a0ac-4fb636e693ee@github.com>

On Wed, 23 Nov 2022 01:25:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Anyone can help reviewing this trivial RFE? Mostly just making clarifications on exception messages as submitter requested. Enhanced existing test case to check on this particular scenario.

This pull request has now been integrated.

Changeset: 6dc4d891
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6dc4d891c3ad043405c65e0e0eeef28e9e5a2156
Stats:     64 lines in 2 files changed: 47 ins; 7 del; 10 mod

7181214: Need specify SKF translateKey(SecurityKey) method requires instance of PBEKey for PBKDF2 algorithms

Reviewed-by: xuelei, weijun

-------------

PR: https://git.openjdk.org/jdk/pull/11306

From jjg at openjdk.org  Wed Nov 23 18:57:03 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 18:57:03 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
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: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@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.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Remove updates from unexported files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/c29092d8..3905ac83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=01-02

  Stats: 34 lines in 25 files changed: 0 ins; 34 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 dfuchs at openjdk.org  Wed Nov 23 19:23:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 19:23:53 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>

On Wed, 23 Nov 2022 18:57:03 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.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From weijun at openjdk.org  Wed Nov 23 19:48:48 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Nov 2022 19:48:48 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
Message-ID: <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>

> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
> 
> - Remove unnecessary `throws IOException` in code and spec
> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
> - Some unused methods removed
> - `DerOutputStream` is final
> 
> The only actual changes (still trivial) are:
> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11302/files
  - new: https://git.openjdk.org/jdk/pull/11302/files/d4d6ba8f..7597405a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11302/head:pull/11302

PR: https://git.openjdk.org/jdk/pull/11302

From kbarrett at openjdk.org  Wed Nov 23 21:47:09 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 21:47:09 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@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>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
 <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>
Message-ID: <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com>

On Wed, 23 Nov 2022 05:22:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 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).
>
> I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted.

Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`.

One obvious and cheap solution to that would be to make that enum public.  I think that would be an improvement vs the current friend declaration.  But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used.  Here's a patch that I think cleans this up.


diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
index 0651f0868f3..bf9e759b1d6 100644
--- a/src/hotspot/os/windows/os_windows.cpp
+++ b/src/hotspot/os/windows/os_windows.cpp
@@ -511,7 +511,9 @@ JNIEXPORT
 LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo);
 
 // Thread start routine for all newly created threads
-static unsigned __stdcall thread_native_entry(Thread* thread) {
+// Called with the associated Thread* as the argument.
+unsigned __stdcall os::win32::thread_native_entry(void* t) {
+  Thread* thread = static_cast<Thread*>(t);
 
   thread->record_stack_base_and_size();
   thread->initialize_thread_current();
@@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type,
     thread_handle =
       (HANDLE)_beginthreadex(NULL,
                              (unsigned)stack_size,
-                             (unsigned (__stdcall *)(void*)) thread_native_entry,
+                             &os::win32::thread_native_entry,
                              thread,
                              initflag,
                              &thread_id);
diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp
index 94d7c3c5e2d..197797078d7 100644
--- a/src/hotspot/os/windows/os_windows.hpp
+++ b/src/hotspot/os/windows/os_windows.hpp
@@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int);
 
 class os::win32 {
   friend class os;
-  friend unsigned __stdcall thread_native_entry(Thread*);
 
  protected:
   static int    _processor_type;
@@ -70,6 +69,10 @@ class os::win32 {
   static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen);
 
  private:
+  // The handler passed to _beginthreadex().
+  // Called with the associated Thread* as the argument.
+  static unsigned __stdcall thread_native_entry(void*);
+
   enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE };
   // Wrapper around _endthreadex(), exit() and _exit()
   static int exit_process_or_thread(Ept what, int exit_code);

-------------

PR: https://git.openjdk.org/jdk/pull/11081

From jjg at openjdk.org  Wed Nov 23 22:09:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 22:09:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
Message-ID: <CN_yhlxSOuJ_vrZwgtwLXWapiBa9Df2Cab1ySShZvu4=.b3e2212d-2f5d-4cea-a28b-8a02e3b18159@github.com>

On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

Believe me, I tried *very* hard to design and use an inline `{@spec}` tag but such a tag effectively needs a normative external file to indicate the root of a multi-page spec, and the definitive title, since inline tags either do not or are unlikely to contain such information.

The general history of this work is:
* version 1: bimodal tag with no external file -- the content of the summary page was effectively rubbish
* version 2: bimodal tag with an external file -- in discussion with @jddarcy and CSR, we decided that was too much of a non-standard maintenance load
* version 3: new tag, with no external file needed -- as you see here

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From joehw at openjdk.org  Wed Nov 23 23:08:05 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:08:05 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>

On Wed, 23 Nov 2022 18:57:03 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.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:

> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition

Hi Jon,

I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
points to the fifth edition while @see second.

A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.

[1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From joehw at openjdk.org  Wed Nov 23 23:43:57 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:43:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <3O_lqMPzsBuGyrQ_snbw0Qv-XY-OaGUly6OBtoRz8hw=.041bf0b3-9dd4-4616-a003-617d28030139@github.com>

On Wed, 23 Nov 2022 18:57:03 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.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

Specs for XSLT and XPath (many occurrences) need to point to specific version (e.g. 1.0) rather than the "cover page" (this is an issue in the original javadoc).

src/java.xml/share/classes/javax/xml/transform/OutputKeys.java line 35:

> 33:  *
> 34:  * @spec https://www.w3.org/TR/xslt xslt cover page - W3C
> 35:  * @see <a href="http://www.w3.org/TR/xslt#output">

The pages for XSLT and XPath at W3C are organized differently from the days when this javadoc was created. The "latest version" now points to the "cover page". Could you change the spec to the following? 
      https://www.w3.org/TR/1999/REC-xslt-19991116 XSL Transformations (XSLT) Version 1.0
      
The @spec points to the general spec while @see also a specific section (similar situation as other classes in the package), if we want to keep @see ref here, it would be: 
    https://www.w3.org/TR/1999/REC-xslt-19991116#output

src/java.xml/share/classes/javax/xml/xpath/XPath.java line 104:

> 102:  * @author  Norman Walsh
> 103:  * @author  Jeff Suttor
> 104:  * @see <a href="http://www.w3.org/TR/xpath">XML Path Language (XPath) Version 1.0</a>

Similar situation as XSLT above, the latest version now points to "cover page". For this javadoc then, it needs to be:
    https://www.w3.org/TR/1999/REC-xpath-19991116/ XML Path Language (XPath) Version 1.0
    
Unlike XSLT, the original @see ref also points to the spec generally (not a specific section), we could then drop it to keep just the @spec ref.

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From duke at openjdk.org  Wed Nov 23 23:45:42 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 23 Nov 2022 23:45:42 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
Message-ID: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>

Regarding mainline:
- I decided not to 'unroll' the top while loop (i.e. `engineUpdate(byte[] input, int offset, int len)` is unrolled)
   - It is debatable which version is easier to understand. If this version is 'too complex', I can unroll the top while loop. 
- I do think this version is incremental (i.e. easier to review?):
   - Move `remaining -= bytesToWrite;` into each `if` branch
   - Change first `if` case to process multiple blocks instead of one

This `while` loop has a lot of cases to remember; Very roughly:

1. process from previous call
2. process current data
3. store overflow

Interesting situations:
- `blockOffset` might be non-`0`
- `remaining+blockOffset` might not be enough to fill a single block. Or just enough for one block and to leave an overflow again..
- etc.

Regarding testing
- Correctness of intrinsic was already tested in https://github.com/openjdk/jdk/pull/10582 so not adding any tests there (i.e. no KAT)
- In principle, fuzz test should also be sufficient to test bytebuffer (did increase repetitions)

-------------

Commit messages:
 - whitespace
 - ByteBuffer support and tests

Changes: https://git.openjdk.org/jdk/pull/11338/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11338&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297379
  Stats: 44 lines in 2 files changed: 33 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11338.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11338/head:pull/11338

PR: https://git.openjdk.org/jdk/pull/11338

From valeriep at openjdk.org  Thu Nov 24 00:12:53 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 24 Nov 2022 00:12:53 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the PBKDF2
 and PBES2 impls in SunJCE provider
Message-ID: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>

This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.

-------------

Commit messages:
 - remove trailing whitespace
 - 8288050: Add support of SHA-512/224 and SHA-512/256 to the PBKDF2 and PBES2 impls in SunJCE provider

Changes: https://git.openjdk.org/jdk/pull/11339/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11339&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288050
  Stats: 373 lines in 26 files changed: 249 ins; 20 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/11339.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11339/head:pull/11339

PR: https://git.openjdk.org/jdk/pull/11339

From pminborg at openjdk.org  Thu Nov 24 08:20:36 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 08:20:36 GMT
Subject: RFR: 8297505: Declare fields in some sun.security.pkcs11 classes as
 final
Message-ID: <IKwYlwSCdO1z4rj16DSI5H-sWPvv37CLVu3tYdPgAII=.a982c8e6-cffb-4b91-9385-ac2a9fd24181@github.com>

This PR proposes declaring some fields as `final` to potentially unlock performance optimisations and improve thread visibility (e.g. for GC threads). The PR also fixes a "synchronising on a non-final field" anti-pattern.

-------------

Commit messages:
 - Declare fields and classes final

Changes: https://git.openjdk.org/jdk/pull/11346/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11346&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297505
  Stats: 25 lines in 10 files changed: 0 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/11346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11346/head:pull/11346

PR: https://git.openjdk.org/jdk/pull/11346

From pminborg at openjdk.org  Thu Nov 24 08:27:14 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 08:27:14 GMT
Subject: RFR: 8297515: serialVersionUID fields are not annotated with @Serial
Message-ID: <MqqET7v-K_FuquXBNxVsLgqZwsufulAQEOI0e6u8W7U=.7411e7f5-eb70-41da-9599-1c6fbc10141c@github.com>

This PR proposes adding `@Serial` annotations to certain fields participating in serialisation.

-------------

Commit messages:
 - Annotate serailzation fields with @Serial

Changes: https://git.openjdk.org/jdk/pull/11347/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11347&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297515
  Stats: 27 lines in 7 files changed: 27 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11347.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11347/head:pull/11347

PR: https://git.openjdk.org/jdk/pull/11347

From pminborg at openjdk.org  Thu Nov 24 08:32:32 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 08:32:32 GMT
Subject: RFR: 8297519: Improve expressions and modernise code
Message-ID: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>

During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 


This branch has been tested and passed tier1-4 tests.

-------------

Commit messages:
 - Modernise classes

Changes: https://git.openjdk.org/jdk/pull/11348/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11348&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297519
  Stats: 1138 lines in 31 files changed: 163 ins; 363 del; 612 mod
  Patch: https://git.openjdk.org/jdk/pull/11348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11348/head:pull/11348

PR: https://git.openjdk.org/jdk/pull/11348

From pminborg at openjdk.org  Thu Nov 24 08:32:33 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 08:32:33 GMT
Subject: RFR: 8297519: Improve expressions and modernise code
In-Reply-To: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
Message-ID: <lMxqndlnDEnJz0qWsuT4DhSU09jnxKsRtRIRjrnU00Y=.88871765-7959-4b9f-9291-c5918c5d692b@github.com>

On Thu, 24 Nov 2022 08:24:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
> 
> 
> This branch has been tested and passed tier1-4 tests.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 313:

> 311:             AlgorithmParameterSpec paramSpec = null;
> 312:             if (params != null) {
> 313:                 paramSpec = switch (type) {

This switch is exhaustive.

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From pminborg at openjdk.org  Thu Nov 24 08:36:16 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 08:36:16 GMT
Subject: RFR: 8297519: Improve expressions and modernise code
In-Reply-To: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
Message-ID: <9WZ45UBU5Dk8LZ-CZaIO2lqcn3kXqYQS8j2HbRKodKM=.b765534f-6a90-49bb-994c-6b7569470271@github.com>

On Thu, 24 Nov 2022 08:24:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
> 
> 
> This branch has been tested and passed tier1-4 tests.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 450:

> 448: 
> 449:         private void initConfiguration() {
> 450:             config = switch (type) {

Exhaustive

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From duke at openjdk.org  Thu Nov 24 09:02:51 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Thu, 24 Nov 2022 09:02:51 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v3]
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: <iHG9_BFeUGTf4-ZgKgM7fGf32MgsEL9A4ijXNaef0zI=.488c3511-9e43-4963-8e81-00ff70b1329e@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 14 additional commits since the last revision:

 - Merge branch 'master' into 8294526
 - Merge branch 'master' into 8294526
 - 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 'master' into 8294526
 - Merge branch 'master' into 8294526
 - Merge branch 'master' into 8294526
 - ... and 4 more: https://git.openjdk.org/jdk/compare/f6c2b33a...64972419

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10550/files
  - new: https://git.openjdk.org/jdk/pull/10550/files/feb38b83..64972419

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10550&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10550&range=01-02

  Stats: 61260 lines in 1147 files changed: 24158 ins; 22989 del; 14113 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 duke at openjdk.org  Thu Nov 24 09:02:52 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Thu, 24 Nov 2022 09:02:52 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v2]
In-Reply-To: <cKc1kbQujBAsGtrdpZFqDRm9zDgTvG4Q7txUJeZFUPE=.48e6c3c6-5259-450e-80fa-3fb0f2851137@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <q1y9WmPN03R0H2TjybJ7DlNwXTIG2BfpwB-DEOZgWkg=.4d1062f0-2dd1-4d21-b9ae-5d732912e680@github.com>
 <FfVUYgwI3-HDqr0WnmxhStKIJvoVZ70fp7FcnoE-bkM=.ed69e593-623d-4ad3-aaa8-b7a732cffe41@github.com>
 <v__R-7DqHYZExc-3k6wKS0dXDyDNP_eL6SLV4AabyNQ=.da7d17bf-46b4-4c03-9ee4-e002ec508efb@github.com>
 <cKc1kbQujBAsGtrdpZFqDRm9zDgTvG4Q7txUJeZFUPE=.48e6c3c6-5259-450e-80fa-3fb0f2851137@github.com>
Message-ID: <YyR9IxChUMQQ5FKmw_-Qn5Gb0tddUX2oVuZvNKC7qCk=.7cbe3f65-ee57-4d5f-9a0b-ef7c38d2ed9f@github.com>

On Fri, 18 Nov 2022 17:49:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> @XueleiFan I have removed the Test and related policy files
>> (Comparator.Combined.Policy/ Comparator.Comparator.Policy/Comparator.Principal.Policy), is this what you were expecting? I can confirm I am still getting a successful test run.
>
> I meant to remove the Comparator.java.   As SubjectCodeSource has been removed, the note you added may be confusing for future readers.  If you want to have a record, you could use bug comment in JDK-8294526.

Thanks, I have removed the Comparator.java and related files and will add a comment on the bug

-------------

PR: https://git.openjdk.org/jdk/pull/10550

From alanb at openjdk.org  Thu Nov 24 10:56:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 10:56:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <W_PDXjCTWZO6xXPHhF-LLKnDxtRgwgI9zdv9Se52Rqo=.0ae98a38-5f76-4839-b579-ab19faf1945b@github.com>

On Wed, 23 Nov 2022 18:57:03 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.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.se/share/classes/module-info.java line 39:

> 37:  *
> 38:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 39:  * @spec jni/index.html Java Native Interface Specification

One thing that that bothers me a bit here is that the JNI and JDWP specs will be listed as "External Specifications" in the generated javadoc. This heading is appropriate for RFCs and other standards that we reference but seems misleading for specifications that are part of Java SE. Has this come up already?

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From pminborg at openjdk.org  Thu Nov 24 11:42:52 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 11:42:52 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/682b6f5a..0546b23b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=11-12

  Stats: 213 lines in 20 files changed: 12 ins; 105 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From mcimadamore at openjdk.org  Thu Nov 24 11:53:28 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 11:53:28 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <U9NPKtU24wSF4q7X1EkgR2dbIW5k3Oe1mLs8iqAs1Ks=.c12f9a79-db57-46d0-8ccd-b26c0a077816@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

Looks good - I'm glad that the changes to IOUtil turned out simpler than expected!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11260

From mcimadamore at openjdk.org  Thu Nov 24 11:57:09 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 11:57:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:

> 517:     }
> 518: 
> 519:     record LinkedRunnable(Runnable node, Runnable next)

Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From mcimadamore at openjdk.org  Thu Nov 24 12:00:21 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 12:00:21 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
Message-ID: <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>

On Thu, 24 Nov 2022 11:54:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant method
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:
> 
>> 517:     }
>> 518: 
>> 519:     record LinkedRunnable(Runnable node, Runnable next)
> 
> Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.

Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).

Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From mcimadamore at openjdk.org  Thu Nov 24 12:00:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 12:00:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
 <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
Message-ID: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>

On Thu, 24 Nov 2022 11:57:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:
>> 
>>> 517:     }
>>> 518: 
>>> 519:     record LinkedRunnable(Runnable node, Runnable next)
>> 
>> Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.
>
> Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).
> 
> Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.

(to be clear, some of the above comments refer to the code that was already there before your changes)

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From alanb at openjdk.org  Thu Nov 24 12:17:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 12:17:06 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 790:

> 788:         try {
> 789:             int n = receive0(fd,
> 790:                     ((DirectBuffer)bb).address() + pos, rem,

Would it be possible to restore the original alignment, just to make it easier to read.

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 39:

> 37:     // silent unrelated memory mutation and JVM crashes.
> 38:     //
> 39:     // Guards are available in the JavaNioAccess class.

Did you mean to leave the word "Guards" in the comment? I guess I would say something "See JavaNioAccess for methods to acquire/release" or something like that.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:

> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
> 480:             throw new IllegalStateException("Confined session not supported");

No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 543:

> 541:         @Override public void run() { releaseScope(bb, session); }
> 542:         static Runnable of(ByteBuffer bb, MemorySessionImpl session) { return new Releaser(bb, session); }
> 543:         static Runnable ofNullable(ByteBuffer bb, MemorySessionImpl session) {

Would it be possible to re-format this to make it more readable? There's just a bit more going on compared to the original and it's harder to read.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Thu Nov 24 14:52:15 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 14:52:15 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
 <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
 <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>
Message-ID: <dy4zEuWXA_iymssRu8PCeqXXnU77AA-ncC3veSg6xOA=.7d822c4a-9c34-4e1b-9dcf-6d6956601e4b@github.com>

On Thu, 24 Nov 2022 11:58:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).
>> 
>> Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.
>
> (to be clear, some of the above comments refer to the code that was already there before your changes)

I also found the above as a bit odd but tried to stick with the existing implementation and style as much as possible.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Thu Nov 24 14:58:19 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 14:58:19 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
Message-ID: <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>

On Thu, 24 Nov 2022 12:06:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant method
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:
> 
>> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
>> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
>> 480:             throw new IllegalStateException("Confined session not supported");
> 
> No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.

This was the old behaviour which was retained in this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Thu Nov 24 16:21:42 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 16:21:42 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reformat and fix comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/0546b23b..30aff118

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12-13

  Stats: 26 lines in 3 files changed: 13 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From jbhateja at openjdk.org  Thu Nov 24 18:59:11 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Nov 2022 18:59:11 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
In-Reply-To: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
Message-ID: <EieNIEXEMM5bEPzYTrUh2qpN7ntMXKsTZiEqcfCe9rE=.497404e9-6ed9-439d-abdc-d5d4fb9790f3@github.com>

On Wed, 23 Nov 2022 23:33:32 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Regarding mainline:
> - I decided not to 'unroll' the top while loop (i.e. `engineUpdate(byte[] input, int offset, int len)` is unrolled)
>    - It is debatable which version is easier to understand. If this version is 'too complex', I can unroll the top while loop. 
> - I do think this version is incremental (i.e. easier to review?):
>    - Move `remaining -= bytesToWrite;` into each `if` branch
>    - Change first `if` case to process multiple blocks instead of one
> 
> This `while` loop has a lot of cases to remember; Very roughly:
> 
> 1. process from previous call
> 2. process current data
> 3. store overflow
> 
> Interesting situations:
> - `blockOffset` might be non-`0`
> - `remaining+blockOffset` might not be enough to fill a single block. Or just enough for one block and to leave an overflow again..
> - etc.
> 
> Regarding testing
> - Correctness of intrinsic was already tested in https://github.com/openjdk/jdk/pull/10582 so not adding any tests there (i.e. no KAT)
> - In principle, fuzz test should also be sufficient to test bytebuffer (did increase repetitions)

Please add a JMH micro showcasing gains, with heap allocated and native byte buffer (once you support it).

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 268:

> 266:         } else {
> 267:             while (blockMultipleLength > 0) {
> 268:                 processBlock(buf, BLOCK_LENGTH);

For native byte buffers, you can pass the buffer address and base.

-------------

PR: https://git.openjdk.org/jdk/pull/11338

From aturbanov at openjdk.org  Thu Nov 24 20:15:24 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 24 Nov 2022 20:15:24 GMT
Subject: RFR: 8297519: Improve expressions and modernise code
In-Reply-To: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
Message-ID: <AqoMMi-DK6EPs49Lqxf73P32ioghkyuU9zfba6kMNok=.0590c209-03dd-4df9-a888-ed37fed97006@github.com>

On Thu, 24 Nov 2022 08:24:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
> 
> 
> This branch has been tested and passed tier1-4 tests.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 356:

> 354:     }
> 355: 
> 356:     static final String TEMPLATE_EXTERNAL =  """

Suggestion:

    static final String TEMPLATE_EXTERNAL = """

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From aturbanov at openjdk.org  Thu Nov 24 20:15:24 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 24 Nov 2022 20:15:24 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider
In-Reply-To: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
Message-ID: <po_Nbmc2Nts4cO89VDaYT7wja83aFpmOQePml9XdEag=.2327a4b0-1660-40a1-b66b-85025d9f17fe@github.com>

On Wed, 23 Nov 2022 23:39:03 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.

src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line 180:

> 178:     public static final class PBEWithHmacSHA512_256AndAES_128
> 179:             extends PBEKeyFactory {
> 180:         public PBEWithHmacSHA512_256AndAES_128()  {

Nit:
Suggestion:

        public PBEWithHmacSHA512_256AndAES_128() {

-------------

PR: https://git.openjdk.org/jdk/pull/11339

From xuelei at openjdk.org  Fri Nov 25 06:12:02 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 25 Nov 2022 06:12:02 GMT
Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no
 longer referenced [v3]
In-Reply-To: <iHG9_BFeUGTf4-ZgKgM7fGf32MgsEL9A4ijXNaef0zI=.488c3511-9e43-4963-8e81-00ff70b1329e@github.com>
References: <HJ2p1lahCBTzUr3DFa6-m-WLX6UztdxtgJEhEpkWiak=.15fad302-3dac-4f5d-8cbc-0561b7e0fe06@github.com>
 <iHG9_BFeUGTf4-ZgKgM7fGf32MgsEL9A4ijXNaef0zI=.488c3511-9e43-4963-8e81-00ff70b1329e@github.com>
Message-ID: <TNk_-Sga8jFBCUyIpnMnRlVjEqjnk-C8Fa_yKGg7qDA=.21c3efe4-c969-488b-bd9d-e7f2074a8bf9@github.com>

On Thu, 24 Nov 2022 09:02:51 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 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8294526
>  - Merge branch 'master' into 8294526
>  - 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 'master' into 8294526
>  - Merge branch 'master' into 8294526
>  - Merge branch 'master' into 8294526
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/b8243383...64972419

Looks good to me.  Thanks!

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10550

From duke at openjdk.org  Fri Nov 25 06:49:27 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 25 Nov 2022 06:49:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
 <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
Message-ID: <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>

On Thu, 24 Nov 2022 14:56:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:
>> 
>>> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
>>> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
>>> 480:             throw new IllegalStateException("Confined session not supported");
>> 
>> No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.
>
> This was the old behaviour which was retained in this PR.

I?believe `UnsupportedOperationException` would?be?better for?this.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From alanb at openjdk.org  Fri Nov 25 07:17:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Nov 2022 07:17:08 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
 <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
 <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>
Message-ID: <AaszrcsHg-zt8e_GlzGdKqfyrJ-mbkKIgVmUDxjzJWc=.cfca580b-34e7-458b-b3d1-daedc73e1ba9@github.com>

On Fri, 25 Nov 2022 06:46:52 GMT, ExE Boss <duke at openjdk.org> wrote:

> I?believe `UnsupportedOperationException` would?be?better for?this.

It would but Per is right that this it is throwing ISE today, it's just that the PR adds an explicit check and that highlights that the wrong exception is thrown. Buffers that are views over memory that is thread confined can't be used with the AsynchronousXXXX APIs and this will needed to be specified. There is further work required in this area too because IOUtil was intended for synchronous I/O. The "async" support was added on a temporary basis and will need to be re-visited at some point.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From valeriep at openjdk.org  Sun Nov 27 07:23:15 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 07:23:15 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
Message-ID: <w4hyH2nHNsTMYvrKZlS6VC1y-LIg7_dNJ5Ld1sVITyU=.ad656301-9c2d-4498-bb75-50b01cac64e4@github.com>

On Wed, 23 Nov 2022 19:48:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/java.base/share/classes/sun/security/x509/CertificateExtensions.java line 152:

> 150:      * @param isCertReq if true then no context specific tag is added.
> 151:      * @exception CertificateException on encoding errors.
> 152:      * @exception IOException on errors.

should remove these two lines above also?

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From valeriep at openjdk.org  Sun Nov 27 07:44:11 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 07:44:11 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
Message-ID: <Cx_H5CkiPKnj9boP3vPO6k5h3FZIyGuxThxlDzmgLSQ=.4df9b979-f06d-49c5-a526-87cbc441c486@github.com>

On Wed, 23 Nov 2022 19:48:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/java.base/share/classes/sun/security/x509/GeneralNames.java line 112:

> 110:      *
> 111:      * @param out the DerOutputStream to write the extension to.
> 112:      * @exception IOException on error.

Should remove above line?

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From valeriep at openjdk.org  Sun Nov 27 08:03:03 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 08:03:03 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
Message-ID: <6zTJxQ6Y0BGTvJVSCt8pkDYE2RlrFrVpegXOxpHSXzs=.6d3e8142-3f1b-4bfd-ba41-854f5f9b372d@github.com>

On Wed, 23 Nov 2022 19:48:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/java.base/share/classes/sun/security/x509/RDN.java line 336:

> 334:      *
> 335:      * @param out DerOutputStream to which RDN is to be written
> 336:      * @throws IOException on error

should remove this line?

src/java.base/share/classes/sun/security/x509/SerialNumber.java line 111:

> 109:      *
> 110:      * @param out the DerOutputStream to marshal the contents to.
> 111:      * @exception IOException on errors.

should remove this line?

src/java.base/share/classes/sun/security/x509/UniqueIdentity.java line 95:

> 93:      * @param out the DerOutputStream to marshal the contents to.
> 94:      * @param tag encode it under the following tag.
> 95:      * @exception IOException on errors.

should remove this line?

src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 298:

> 296:          * Encodes the "to-be-signed" TBSCertList to the OutputStream.
> 297:          *
> 298:          * @exception CRLException on encoding errors.

should remove this line?

src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 300:

> 298:          * @exception CRLException on encoding errors.
> 299:          */
> 300:         public byte[] encodeInfo() throws CRLException {

"throws CRLException" can be removed?

src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 601:

> 599:      */
> 600:     public static X509CRLImpl newSigned(TBSCertList info, PrivateKey key, String algorithm, String provider)
> 601:             throws CRLException, NoSuchAlgorithmException, InvalidKeyException,

Does this method still has calls which throw CRLException?

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From valeriep at openjdk.org  Sun Nov 27 08:09:18 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 08:09:18 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
Message-ID: <l89SsPytb4kRSs4K2ase6DlY7dcUFs3HToAKDVAvqYY=.c38eff32-f567-46e7-b196-b389a4e5ddb5@github.com>

On Wed, 23 Nov 2022 19:48:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 467:

> 465:      */
> 466:     public static X509CertImpl newSigned(X509CertInfo info, PrivateKey key, String algorithm, String provider)
> 467:             throws CertificateException, NoSuchAlgorithmException,

The javadoc above states that CertificateException is thrown on encoding errors. Will there still be encoding errors? The updated code seems not.

src/java.base/share/classes/sun/security/x509/X509CertInfo.java line 148:

> 146:      * @param out an output stream to which the certificate is appended.
> 147:      * @exception CertificateException on encoding errors.
> 148:      * @exception IOException on other errors.

should remove this line?

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From valeriep at openjdk.org  Sun Nov 27 08:16:52 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 08:16:52 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
Message-ID: <6LJQG-JneUXUWZjqVQmQTwsqcFNbLkfn2P7a-k4GIwA=.39067893-5aea-4fa6-959f-6c1900fdee7e@github.com>

On Wed, 23 Nov 2022 19:48:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/java.base/share/classes/sun/security/x509/X509Key.java line 321:

> 319:      * Returns the DER-encoded form of the key as a byte array.
> 320:      *
> 321:      * @exception InvalidKeyException on encoding errors.

should remove this line?

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From valeriep at openjdk.org  Sun Nov 27 08:27:12 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 08:27:12 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
Message-ID: <gD_4-d_7xj1hkBXMMNjqAkwge84_KYDjsLN-AjDBuRM=.292ce3d7-80db-467d-b933-cb9740dc2b75@github.com>

On Wed, 23 Nov 2022 19:48:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java line 77:

> 75:     }
> 76: 
> 77:     final byte[] encode() throws GSSException {

Probably no need for GSSException?

src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 99:

> 97:     }
> 98: 
> 99:     private void makeEncoding(byte[] s) throws InvalidKeyException {

No need for the InvalidKeyException?

src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 113:

> 111:     }
> 112: 
> 113:     private void makeEncoding(BigInteger s) throws InvalidKeyException {

No need for the InvalidKeyException?

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From valeriep at openjdk.org  Sun Nov 27 08:43:51 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 08:43:51 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider
In-Reply-To: <po_Nbmc2Nts4cO89VDaYT7wja83aFpmOQePml9XdEag=.2327a4b0-1660-40a1-b66b-85025d9f17fe@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <po_Nbmc2Nts4cO89VDaYT7wja83aFpmOQePml9XdEag=.2327a4b0-1660-40a1-b66b-85025d9f17fe@github.com>
Message-ID: <EiFfoPrcrTqa8ydQdxQUOqPfNPCD1khOVPpRoz4u7iY=.bd7a6b54-5e52-4264-8f96-60c58639df01@github.com>

On Thu, 24 Nov 2022 20:13:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
>> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.
>
> src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line 180:
> 
>> 178:     public static final class PBEWithHmacSHA512_256AndAES_128
>> 179:             extends PBEKeyFactory {
>> 180:         public PBEWithHmacSHA512_256AndAES_128()  {
> 
> Nit:
> Suggestion:
> 
>         public PBEWithHmacSHA512_256AndAES_128() {

Sure, will fix.

-------------

PR: https://git.openjdk.org/jdk/pull/11339

From valeriep at openjdk.org  Sun Nov 27 09:09:23 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sun, 27 Nov 2022 09:09:23 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v2]
In-Reply-To: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
Message-ID: <0YWxXMEUahIvl2temsbPBkP913bSUZy97_ICojoFTzY=.cccce54b-b1fb-4b13-b338-cf594207406a@github.com>

> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  remove extra whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11339/files
  - new: https://git.openjdk.org/jdk/pull/11339/files/5ca95f82..3bb914b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11339&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11339&range=00-01

  Stats: 39 lines in 1 file changed: 0 ins; 9 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/11339.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11339/head:pull/11339

PR: https://git.openjdk.org/jdk/pull/11339

From aturbanov at openjdk.org  Sun Nov 27 13:28:17 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 27 Nov 2022 13:28:17 GMT
Subject: RFR: 8297683: Use enhanced-for cycle instead of Enumeration in
 java.security.jgss
Message-ID: <pyQf2FNDpgDmd9iLBWkhsWu3eN3t8Nf8WJl9Ny-yHsw=.8cbc9c2b-f155-4068-bd29-3eaf24122302@github.com>

java.util.Enumeration is a legacy interface from java 1.0.
There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

sun.security.jgss.ProviderList#addAllMechsFromProvider
sun.security.jgss.GSSCredentialImpl#dispose
sun.security.jgss.GSSCredentialImpl#getRemainingLifetime
sun.security.jgss.GSSCredentialImpl#getUsage()
sun.security.jgss.GSSCredentialImpl#getElements

-------------

Commit messages:
 - 8297683: Use enhanced-for cycle instead of Enumeration in java.security.jgss

Changes: https://git.openjdk.org/jdk/pull/11377/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11377&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297683
  Stats: 31 lines in 2 files changed: 0 ins; 23 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11377.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11377/head:pull/11377

PR: https://git.openjdk.org/jdk/pull/11377

From aturbanov at openjdk.org  Sun Nov 27 13:43:22 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 27 Nov 2022 13:43:22 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: <kzDNaEjv4JB1fCp18abNS-8gH5nGCNQPmrXRtHVIMKQ=.d61080b7-cedc-4701-bf7e-fb331998607a@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`.

src/java.base/share/classes/sun/security/x509/NetscapeCertTypeExtension.java line 281:

> 279:      */
> 280:     public Enumeration<String> getElements() {
> 281:         return mAttributeNames.elements();

Looks like we can drop `mAttributeNames` now. It was used only here.

-------------

PR: https://git.openjdk.org/jdk/pull/10934

From duke at openjdk.org  Sun Nov 27 14:40:58 2022
From: duke at openjdk.org (ExE Boss)
Date: Sun, 27 Nov 2022 14:40:58 GMT
Subject: RFR: 8297519: Improve expressions and modernise code
In-Reply-To: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
Message-ID: <G_U8VoV3kkay0JjC3tb7wlXKfSejbc4BI6oxliv0IXA=.b1784e6a-7721-4dd1-ade5-f0b79c06f5cf@github.com>

On Thu, 24 Nov 2022 08:24:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
> 
> 
> This branch has been tested and passed tier1-4 tests.

These?can?all be?`switch`?expressions:

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 487:

> 485:                     case "noDb" -> nssDbMode = Secmod.DbMode.NO_DB;
> 486:                     default -> throw excToken("nssDbMode must be one of readWrite, readOnly, and noDb:");
> 487:                 }

Suggestion:

                nssDbMode = switch (mode) {
                    case "readWrite" -> Secmod.DbMode.READ_WRITE;
                    case "readOnly" -> Secmod.DbMode.READ_ONLY;
                    case "noDb" -> Secmod.DbMode.NO_DB;
                    default -> throw excToken("nssDbMode must be one of readWrite, readOnly, and noDb:");
                };

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 1042:

> 1040:             case "halt" -> handleStartupErrors = ERR_HALT;
> 1041:             default -> throw excToken("Invalid value for handleStartupErrors:");
> 1042:         }

Suggestion:

        handleStartupErrors = switch (val) {
            case "ignoreAll" -> ERR_IGNORE_ALL;
            case "ignoreMissingLibrary" -> ERR_IGNORE_LIB;
            case "halt" -> ERR_HALT;
            default -> throw excToken("Invalid value for handleStartupErrors:");
        };

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 241:

> 239:             default -> throw new NoSuchAlgorithmException("Unsupported mode " + mode);
> 240:         }
> 241:         return result;

Suggestion:

        return switch (mode) {
            case "ECB" -> MODE_ECB;
            case "CBC" -> {
                if (blockSize == 0) {
                    throw new NoSuchAlgorithmException
                            ("CBC mode not supported with stream ciphers");
                }
                yield MODE_CBC;
            }
            case "CTR" -> MODE_CTR;
            default -> throw new NoSuchAlgorithmException("Unsupported mode " + mode);
        };

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 373:

> 371:                 // should never happen; checked by Cipher.init()
> 372:                     throw new AssertionError("Unknown mode: " + opmode);
> 373:         }

Suggestion:

        encrypt = switch (opmode) {
            case Cipher.ENCRYPT_MODE -> true;
            case Cipher.DECRYPT_MODE -> false;
            case Cipher.WRAP_MODE, Cipher.UNWRAP_MODE -> throw new UnsupportedOperationException
                    ("Unsupported mode: " + opmode);
            default ->
                // should never happen; checked by Cipher.init()
                    throw new AssertionError("Unknown mode: " + opmode);
        };

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyWrapCipher.java line 756:

> 754:                     throw new AssertionError();
> 755:         }
> 756:         ;

Empty?statement:
Suggestion:

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSACipher.java line 392:

> 390:                 default -> throw new ProviderException("internal error");
> 391:             }
> 392:             return n;

Suggestion:

            return switch (mode) {
                case MODE_ENCRYPT -> p11.C_Encrypt
                        (session.id(), 0, buffer, 0, bufOfs, 0, out, outOfs, outLen);
                case MODE_DECRYPT -> p11.C_Decrypt
                        (session.id(), 0, buffer, 0, bufOfs, 0, out, outOfs, outLen);
                case MODE_SIGN -> {
                    byte[] tmpBuffer = new byte[bufOfs];
                    System.arraycopy(buffer, 0, tmpBuffer, 0, bufOfs);
                    tmpBuffer = p11.C_Sign(session.id(), tmpBuffer);
                    if (tmpBuffer.length > outLen) {
                        throw new BadPaddingException(
                                "Output buffer (" + outLen + ") is too small to " +
                                        "hold the produced data (" + tmpBuffer.length + ")");
                    }
                    System.arraycopy(tmpBuffer, 0, out, outOfs, tmpBuffer.length);
                    yield tmpBuffer.length;
                }
                case MODE_VERIFY -> p11.C_VerifyRecover
                        (session.id(), buffer, 0, bufOfs, out, outOfs, outLen);
                default -> throw new ProviderException("internal error");
            };

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From weijun at openjdk.org  Sun Nov 27 16:36:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 27 Nov 2022 16:36:10 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <6zTJxQ6Y0BGTvJVSCt8pkDYE2RlrFrVpegXOxpHSXzs=.6d3e8142-3f1b-4bfd-ba41-854f5f9b372d@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
 <6zTJxQ6Y0BGTvJVSCt8pkDYE2RlrFrVpegXOxpHSXzs=.6d3e8142-3f1b-4bfd-ba41-854f5f9b372d@github.com>
Message-ID: <3JLuPRQa_laPXwih3H5mOgMg6QvsQOGG5Gqn616PAG4=.3a7c8e19-4a32-4fd5-bde7-3339c46dd268@github.com>

On Sun, 27 Nov 2022 07:57:35 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   one more
>
> src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 300:
> 
>> 298:          * @exception CRLException on encoding errors.
>> 299:          */
>> 300:         public byte[] encodeInfo() throws CRLException {
> 
> "throws CRLException" can be removed?

Inside the method there is

if ((version == 0) && (issuer.toString() == null))
                throw new CRLException("Null Issuer DN not allowed in v1 CRL");

> src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 601:
> 
>> 599:      */
>> 600:     public static X509CRLImpl newSigned(TBSCertList info, PrivateKey key, String algorithm, String provider)
>> 601:             throws CRLException, NoSuchAlgorithmException, InvalidKeyException,
> 
> Does this method still has calls which throw CRLException?

Because it calls `TBSCertList::encodeInfo`.

> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 467:
> 
>> 465:      */
>> 466:     public static X509CertImpl newSigned(X509CertInfo info, PrivateKey key, String algorithm, String provider)
>> 467:             throws CertificateException, NoSuchAlgorithmException,
> 
> The javadoc above states that CertificateException is thrown on encoding errors. Will there still be encoding errors? The updated code seems not.

Inside `X509CertInfo::emit`, there is

        if ((version.compare(CertificateVersion.V1) == 0) &&
            (issuer.toString() == null))
            throw new CertificateParsingException(
                      "Null issuer DN not allowed in v1 certificate");

and more places where the exception might be thrown.

> src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java line 77:
> 
>> 75:     }
>> 76: 
>> 77:     final byte[] encode() throws GSSException {
> 
> Probably no need for GSSException?

This is because `Oid::getDER` still throws it. Of course it shouldn't (I've added a comment on it). I'll see if I can catch it inside this method and ignore it.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 99:
> 
>> 97:     }
>> 98: 
>> 99:     private void makeEncoding(byte[] s) throws InvalidKeyException {
> 
> No need for the InvalidKeyException?

`ECParameters::getAlgorithmParameters` throws it.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 113:
> 
>> 111:     }
>> 112: 
>> 113:     private void makeEncoding(BigInteger s) throws InvalidKeyException {
> 
> No need for the InvalidKeyException?

Same as above.

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From alanb at openjdk.org  Sun Nov 27 16:59:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 16:59:51 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <Z2mQfsenB-2TKri8E4p_2REW20k6KEl4yy4TQnGBVvA=.e8d51dc4-afcf-4ef5-9e5a-d575db38bb49@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

The latest version (30aff118) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP  434 integrated or soon afterwards?

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From alanb at openjdk.org  Sun Nov 27 17:09:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 17:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <Pc74reEYC1KV1FK_32D_pMa_9tlnJhMaBtZbLupg59w=.c7c124e1-01e1-4579-942b-f7698aee0eb6@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

src/java.base/share/classes/java/util/zip/Deflater.java line 594:

> 592:                     try {
> 593:                         result = deflateBufferBytes(zsRef.address(),
> 594:                                 ((DirectBuffer) input).address() + inputPos, inputRem,

Somewhat subjective but the original code, with inputAddress, was a easier to read and avoided having too much going on in the parameters to deflateBufferBytes. In any case, you probably should fix the formatting to avoid have different parameters with different indentations.

src/java.base/share/classes/java/util/zip/Deflater.java line 717:

> 715:                         result = deflateBytesBuffer(zsRef.address(),
> 716:                             inputArray, inputPos, inputLim - inputPos,
> 717:                                 ((DirectBuffer) output).address() + outputPos, outputRem,

Same here, I think I would keep outputAddress to keep the call to deflateByteBuffer simple.

src/java.base/share/classes/java/util/zip/Deflater.java line 740:

> 738:                             try {
> 739:                                 result = deflateBufferBuffer(zsRef.address(),
> 740:                                     ((DirectBuffer) input).address() + inputPos, inputRem,

Another one where inputAddress and outputAddress have been removed so the call to deflatBufferBuffer is much hard to digest.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From mernst at openjdk.org  Sun Nov 27 17:53:30 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 27 Nov 2022 17:53:30 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From jjiang at openjdk.org  Mon Nov 28 01:57:19 2022
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 28 Nov 2022 01:57:19 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v6]
In-Reply-To: <Y5zjBJTCln4Ww8UvnpuSxwqbJydNKmyylhqB5AP5nhI=.8d5ab765-a439-4f93-aa5e-d52a98362b4d@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <Y5zjBJTCln4Ww8UvnpuSxwqbJydNKmyylhqB5AP5nhI=.8d5ab765-a439-4f93-aa5e-d52a98362b4d@github.com>
Message-ID: <2DhxbUpijpC12S5-UbFZbzToJWq8E7sPq9zASbGDrJg=.45611814-8c7f-4ce8-b31b-dc8776ec99b4@github.com>

On Wed, 23 Nov 2022 06:21:05 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 eight commits:
> 
>  - Merge
>  - remove duplicated bench test
>  - Merge master
>  - missed reduce
>  - reduce if needed
>  - add the key pair generation bench code
>  - remove tabs
>  - 8295010: EC limbs addition and subtraction limit

Marked as reviewed by jjiang (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From pminborg at openjdk.org  Mon Nov 28 08:38:55 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 08:38:55 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <lbi3L0o3TxVCaymOyYjKQ5BgYf3qrYkgwaYn0FcDX3Q=.1120c1d3-0375-48bd-af6f-4d6495ff6d86@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

> The latest version ([30aff11](https://github.com/openjdk/jdk/commit/30aff1187d4978c59d1e6feebafc2d45aba3e5f2)) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP 434 integrated or soon afterwards?

The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (*Session* -> *Scope*) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion?

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From jpai at openjdk.org  Mon Nov 28 09:02:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:02:13 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
Message-ID: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>

On Sun, 27 Nov 2022 17:49:57 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.

I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From jpai at openjdk.org  Mon Nov 28 09:07:24 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:07:24 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk,
 test/jdk/jni
Message-ID: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>

Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.

I'll raise separate PRs in the other remaining areas from that other PR.

-------------

Commit messages:
 - 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Changes: https://git.openjdk.org/jdk/pull/11385/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11385&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294321
  Stats: 21 lines in 20 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11385.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11385/head:pull/11385

PR: https://git.openjdk.org/jdk/pull/11385

From alanb at openjdk.org  Mon Nov 28 09:13:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 09:13:34 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <wvex0wjU2GnSsQ0xKXEHiZTVjMSeNGcGIG0BOHUJJtw=.93cd0d8d-cbea-4948-b439-d9049ad6e2e2@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From alanb at openjdk.org  Mon Nov 28 09:56:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 09:56:14 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67:

> 65:    * to generate elements type your Subscriber is able to consume.
> 66:    * <p>
> 67:    * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber

The comment on the original PR is that this is a 3rd party code and not clear if it should be changed.

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From jpai at openjdk.org  Mon Nov 28 10:02:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:02:47 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment - don't change WithHelperPublisher.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11385/files
  - new: https://git.openjdk.org/jdk/pull/11385/files/85669caf..37a51582

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11385&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11385&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11385.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11385/head:pull/11385

PR: https://git.openjdk.org/jdk/pull/11385

From jpai at openjdk.org  Mon Nov 28 10:02:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:02:50 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>
Message-ID: <GjK3gjMVUR8FxMELtrWBgSirJ-SDQR1mxc-UbzQ6GNs=.5bf874ca-47e8-4609-acab-bceae129bb49@github.com>

On Mon, 28 Nov 2022 09:54:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment - don't change WithHelperPublisher.java
>
> test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67:
> 
>> 65:    * to generate elements type your Subscriber is able to consume.
>> 66:    * <p>
>> 67:    * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber
> 
> The comment on the original PR is that this is a 3rd party code and not clear if it should be changed.

Hello Alan, I have now updated this PR to remove changes to this file.

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From pminborg at openjdk.org  Mon Nov 28 10:36:40 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 10:36:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v15]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Re-introduce address variables

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/30aff118..95c40581

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13-14

  Stats: 24 lines in 2 files changed: 11 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From alanb at openjdk.org  Mon Nov 28 10:40:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 10:40:11 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v15]
In-Reply-To: <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>
Message-ID: <PhLwZqHpoyEWcne_UFcklZ4_Jz-gMRjYM4DId_9_YJ8=.602fe5db-c3d0-4513-843d-1c51c5574ac7@github.com>

On Mon, 28 Nov 2022 10:36:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce address variables

> The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (_Session_ -> _Scope_) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion?

Whatever is easiest. Given the fork for JDK 20 is coming up soon then it would be good to get the rename done soon after JEP 434 integrates, just to avoid JDK 20 having the mix of names.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Mon Nov 28 10:47:47 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 10:47:47 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Re-introduce yet another address vairable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/95c40581..eedf41ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14-15

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From lancea at openjdk.org  Mon Nov 28 11:29:09 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Nov 2022 11:29:09 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <Llh9tEhkVodoFQQR2a5Y3RS11724tea047BLBNjKXBo=.9c80845e-9d21-47bf-afce-49ed2e43c855@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From pminborg at openjdk.org  Mon Nov 28 11:59:56 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 11:59:56 GMT
Subject: RFR: 8297519: Improve expressions and modernise code [v2]
In-Reply-To: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
Message-ID: <0mZVaka7WvA8eV4b8yZYZ33Abv_zstEr9tN47dWpcbQ=.e6cfa946-a98b-48bb-a880-959d5e98bb41@github.com>

> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
> 
> 
> This branch has been tested and passed tier1-4 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update from the first round of comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11348/files
  - new: https://git.openjdk.org/jdk/pull/11348/files/9922ece1..8bfb4ad8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11348&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11348&range=00-01

  Stats: 31 lines in 5 files changed: 0 ins; 5 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/11348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11348/head:pull/11348

PR: https://git.openjdk.org/jdk/pull/11348

From weijun at openjdk.org  Mon Nov 28 13:40:15 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Nov 2022 13:40:15 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v3]
In-Reply-To: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
Message-ID: <8HRK-5SsJskwj-kwBUZcqkDDDy_ks_WOYIMeyfNSc_0=.a8c4bb3f-3b7a-4424-ad53-32436c3270cb@github.com>

> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
> 
> - Remove unnecessary `throws IOException` in code and spec
> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
> - Some unused methods removed
> - `DerOutputStream` is final
> 
> The only actual changes (still trivial) are:
> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more javadoc cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11302/files
  - new: https://git.openjdk.org/jdk/pull/11302/files/7597405a..3c70371b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=01-02

  Stats: 9 lines in 7 files changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11302/head:pull/11302

PR: https://git.openjdk.org/jdk/pull/11302

From weijun at openjdk.org  Mon Nov 28 13:49:17 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Nov 2022 13:49:17 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v3]
In-Reply-To: <8HRK-5SsJskwj-kwBUZcqkDDDy_ks_WOYIMeyfNSc_0=.a8c4bb3f-3b7a-4424-ad53-32436c3270cb@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <8HRK-5SsJskwj-kwBUZcqkDDDy_ks_WOYIMeyfNSc_0=.a8c4bb3f-3b7a-4424-ad53-32436c3270cb@github.com>
Message-ID: <KxnxqouhvIO26AS7Snoo_5UADOZrc7HvJnJnG92uA20=.8efd3054-c1d7-4d18-b4b0-555918dd801d@github.com>

On Mon, 28 Nov 2022 13:40:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more javadoc cleanup

New commit pushed. I cannot touched `Old::getDER` without a public API change. I did notice there are also a lot of `asn1Encode` methods in JGSS but it does not have the same signature as `DerEncoder::encode`. I've filed https://bugs.openjdk.org/browse/JDK-8297723.

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From alanb at openjdk.org  Mon Nov 28 14:12:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 14:12:55 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
Message-ID: <8-MFynuwsRGfpV5mqTvonYTwphy5h1Jzs0CO31Og-wQ=.1ec9c4d4-d7dd-4dd6-96de-d6aa60d89930@github.com>

On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce yet another address vairable

Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11260

From dfuchs at openjdk.org  Mon Nov 28 14:27:32 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 14:27:32 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <6IgwmfUT8rOETK23hGf9t27oV1vdSLUUNr7QOvsmjII=.aa65f8e7-8c7a-4d3f-aa69-ef899725bcb4@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From mcimadamore at openjdk.org  Mon Nov 28 15:00:32 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Nov 2022 15:00:32 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
 <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
 <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>
Message-ID: <DPv9DAmeB5tuC5ax2uEHDxtJbGvuNsn_9ZywyI6Q9Cg=.f8b48d3b-4c1b-4d0d-b5e6-e4240e67c5c8@github.com>

On Mon, 21 Nov 2022 12:05:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.
>
> I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing.

> Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated.


IMHO the renaming is not super important - the underlying abstraction managing the segment lifetime is still called MemorySession, even after https://git.openjdk.org/jdk/pull/10872. And, acquire/release are methods on MemorySession - so I think the current name might be more precise even after we integrate the latest API changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From rriggs at openjdk.org  Mon Nov 28 17:06:47 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Nov 2022 17:06:47 GMT
Subject: RFR: 8297515: serialVersionUID fields are not annotated with
 @Serial
In-Reply-To: <MqqET7v-K_FuquXBNxVsLgqZwsufulAQEOI0e6u8W7U=.7411e7f5-eb70-41da-9599-1c6fbc10141c@github.com>
References: <MqqET7v-K_FuquXBNxVsLgqZwsufulAQEOI0e6u8W7U=.7411e7f5-eb70-41da-9599-1c6fbc10141c@github.com>
Message-ID: <MctW2Ns76MaE9E6EVu_OCqRwE9RsrbU_X64CAv-zaWU=.98f6fee8-34c2-43bf-8e5a-488654ff6316@github.com>

On Thu, 24 Nov 2022 08:19:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Serial` annotations to certain fields participating in serialisation.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11347

From lancea at openjdk.org  Mon Nov 28 17:14:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Nov 2022 17:14:41 GMT
Subject: RFR: 8297515: serialVersionUID fields are not annotated with
 @Serial
In-Reply-To: <MqqET7v-K_FuquXBNxVsLgqZwsufulAQEOI0e6u8W7U=.7411e7f5-eb70-41da-9599-1c6fbc10141c@github.com>
References: <MqqET7v-K_FuquXBNxVsLgqZwsufulAQEOI0e6u8W7U=.7411e7f5-eb70-41da-9599-1c6fbc10141c@github.com>
Message-ID: <kv2t02KisPIjSA5LdQUyQ-5Vs6Y6xrX25pLIqNPaJ6s=.18f387e4-79a6-4f13-a21b-713ae33df321@github.com>

On Thu, 24 Nov 2022 08:19:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Serial` annotations to certain fields participating in serialisation.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11347

From duke at openjdk.org  Mon Nov 28 17:30:42 2022
From: duke at openjdk.org (yansendao)
Date: Mon, 28 Nov 2022 17:30:42 GMT
Subject: RFR: 8296384: [TESTBUG]
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently
 timeout
Message-ID: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>

8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

-------------

Commit messages:
 - 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

Changes: https://git.openjdk.org/jdk/pull/11014/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11014&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296384
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11014.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11014/head:pull/11014

PR: https://git.openjdk.org/jdk/pull/11014

From sean.mullan at oracle.com  Mon Nov 28 18:10:48 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 28 Nov 2022 13:10:48 -0500
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <95161595-069f-59f3-4892-db256af4ead9@comcast.net>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <cedc1d65-8309-f994-0ae0-555ab8567742@comcast.net>
 <oRDJJt_pp6JXSGofsVQb_hwdD08VeflQM0bbjnBo9Iw=.33f378f4-cc21-4799-af25-505f8052e2c0@github.com>
 <95161595-069f-59f3-4892-db256af4ead9@comcast.net>
Message-ID: <efb4484c-906a-f907-85e8-15ba01d4f462@oracle.com>

PCSCException is an internal API and is strongly encapsulated by default 
as of JDK 17 [1]. Applications should not be accessing it. Making an 
internal API public is not the solution.

Your suggestion to extend CardException with methods to provide/access 
the underlying error code seems more reasonable. Making the error code 
an enum, as Xuelei suggests also seems like it might be a cleaner approach.

--Sean

[1] https://openjdk.org/jeps/403


On 11/23/22 12:21 PM, Michael StJohns wrote:
> On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote:
>> On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns <mstjohns at comcast.net> wrote:
>>
>>> ? CardException doesn't always pass through the details in a comprehensible way from the underlying cause, ?
>> Does it sound like a cause that the public APIs are not sufficient? Alternatively, if it is possible to update the public APIs instead?
> 
> I once actually wondered why PCSCException existed, rather than using or
> extending CardException (e.g. besides simply to have a place to put all
> of the SCARD related error messages).
> 
> So you'd suggest extending CardException with a "getErrorCode()" method,
> a constructor that takes an error code in addition to a message, and a
> protected errorCode field.?? Have PCSCException extend CardException and
> provide the current single argument constructor to create a
> CardException with an error message based on the error code?
> 
> One of the main reasons I would like a change like this is to deal with
> Window's semi-weird behavior when listing terminals and no terminals are
> found.? Right now I have to parse the returned message looking for
> "SCARD_E_SERVICE_STOPPED" and if that occurs, I return an empty list of
> terminals rather than continuing the throw.? There are a few of those
> codes where it makes sense to translate them into different behavior.
> 
> Mike
> 
> 
> 
> 
>>
>> Best,
>> Xuelei
>>
>>
>>> On Nov 22, 2022, at 6:59 PM, mlbridge[bot] ***@***.***> wrote:
>>>
>>>
>>> Mailing list message from Michael StJohns ***@***.***> on security-dev ***@***.***>:
>>>
>>> On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
>>>
>>> Hi - Sorry - just getting back to the list after a few days away.
>>>
>>> Given that this is a plugin provider for the PCSC access classes, and
>>> that CardException doesn't always pass through the details in a
>>> comprehensible way from the underlying cause, having access to
>>> PCSCException makes a lot of sense, and as far as I can tell is not a
>>> violation of the general plugin contract.
>>>
>>> To make it even more useful, adding a "public long getErrorCode()"
>>> method to PCSCException would help with the cases where a code that
>>> isn't actually an? SCard* related code causing the PCSC exception.
>>>
>>> But -
>>>
>>> Wouldn't this also require a change to the module definition file?
>>>
>>> Mike
>>>
>>> ?
>>> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/11012#issuecomment-1324485877>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSB3EAII4OJ5UKKSZQAJHDWJWCC5ANCNFSM6AAAAAARY2PXGY>.
>>> You are receiving this because you commented.
>>>
>> -------------
>>
>> PR: https://git.openjdk.org/jdk/pull/11012
> 
> 

From mullan at openjdk.org  Mon Nov 28 19:18:21 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Nov 2022 19:18:21 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v3]
In-Reply-To: <8HRK-5SsJskwj-kwBUZcqkDDDy_ks_WOYIMeyfNSc_0=.a8c4bb3f-3b7a-4424-ad53-32436c3270cb@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <8HRK-5SsJskwj-kwBUZcqkDDDy_ks_WOYIMeyfNSc_0=.a8c4bb3f-3b7a-4424-ad53-32436c3270cb@github.com>
Message-ID: <P7NrkogE1uWta-cTM-tpsrXlDMMUtHL3iCq9dOtMe3M=.6b2b7600-5547-44aa-bbd9-526a9d0665b1@github.com>

On Mon, 28 Nov 2022 13:40:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more javadoc cleanup

All changes look reasonable to me.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11302

From psandoz at openjdk.org  Mon Nov 28 19:39:58 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 28 Nov 2022 19:39:58 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
Message-ID: <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>

On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce yet another address vairable

The approach looks good, and almost the least intrusive (see comment).

src/java.base/share/classes/java/nio/Buffer.java line 838:

> 836: 
> 837:                 @Override
> 838:                 public void releaseSession(Buffer buffer, MemorySessionImpl scope) {

I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11260

From weijun at openjdk.org  Mon Nov 28 20:11:58 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Nov 2022 20:11:58 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v2]
In-Reply-To: <0YWxXMEUahIvl2temsbPBkP913bSUZy97_ICojoFTzY=.cccce54b-b1fb-4b13-b338-cf594207406a@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <0YWxXMEUahIvl2temsbPBkP913bSUZy97_ICojoFTzY=.cccce54b-b1fb-4b13-b338-cf594207406a@github.com>
Message-ID: <HitlCYT_gi_ETSUdU62Lh2QYCLD7OEmVx1BvB03u98A=.01face4b-154d-4b93-b32b-44a6f15b758b@github.com>

On Sun, 27 Nov 2022 09:09:23 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
>> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra whitespace

src/java.base/share/classes/javax/crypto/Cipher.java line 325:

> 323:          * index 2: padding component (e.g., PKCS5Padding)
> 324:          */
> 325:         String[] parts = { "", "", "" };

1. Do you want to add a test for the `PBEWithHmacSHA512/256AndAES_128/CBC/PKCS5Padding` cipher transformation?
2. Is `transformation` case-sensitive?

-------------

PR: https://git.openjdk.org/jdk/pull/11339

From weijun at openjdk.org  Mon Nov 28 22:05:59 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Nov 2022 22:05:59 GMT
Subject: Integrated: 8297276: Remove thread text from Subject.current
In-Reply-To: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
References: <gHXDaio4VaZIUptIjl7ExTsHAwOR8YfcUjWOpfYbQBU=.6134675f-bcce-49c5-85ef-e9d926a0a4f4@github.com>
Message-ID: <sjL-BjhiMUX2k2b9mPErvprZPJzGrGCHLVm3wvRXg8Q=.5c2ac019-500f-4172-891e-14af2ef80855@github.com>

On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> With the introduction of Virtual Threads, the current subject is no longer guaranteed to be inherited in a new thread. Remove this requirement until we find another way to implement `Subject::current`.

This pull request has now been integrated.

Changeset: d450314b
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d450314bd35ae431de6131cd01db4fa992ce10a4
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8297276: Remove thread text from Subject.current

Reviewed-by: xuelei, rriggs, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/11292

From weijun at openjdk.org  Mon Nov 28 22:09:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Nov 2022 22:09:49 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v4]
In-Reply-To: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
Message-ID: <IYC2LdwDlHKTqQN19x8v0tAg9rA_-yLeUvOxINMcalY=.555307b4-2200-464f-9604-6cc7b6a2193d@github.com>

> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
> 
> - Remove unnecessary `throws IOException` in code and spec
> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
> - Some unused methods removed
> - `DerOutputStream` is final
> 
> The only actual changes (still trivial) are:
> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one extra removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11302/files
  - new: https://git.openjdk.org/jdk/pull/11302/files/3c70371b..f18a6786

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11302&range=02-03

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11302/head:pull/11302

PR: https://git.openjdk.org/jdk/pull/11302

From weijun at openjdk.org  Mon Nov 28 22:09:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Nov 2022 22:09:51 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v3]
In-Reply-To: <8HRK-5SsJskwj-kwBUZcqkDDDy_ks_WOYIMeyfNSc_0=.a8c4bb3f-3b7a-4424-ad53-32436c3270cb@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <8HRK-5SsJskwj-kwBUZcqkDDDy_ks_WOYIMeyfNSc_0=.a8c4bb3f-3b7a-4424-ad53-32436c3270cb@github.com>
Message-ID: <92OMXyE7Az74f5Di1dmxXGNoCFXhA96hlem0dwcQRdM=.832a8ee5-8152-4577-a1ff-f7191796d1f0@github.com>

On Mon, 28 Nov 2022 13:40:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more javadoc cleanup

A new commit pushed. A small somewhat related cleanup.

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From weijun at openjdk.org  Mon Nov 28 22:10:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Nov 2022 22:10:47 GMT
Subject: RFR: 8296142: CertAttrSet::(getName|getElements|delete) are mostly
 useless
In-Reply-To: <kzDNaEjv4JB1fCp18abNS-8gH5nGCNQPmrXRtHVIMKQ=.d61080b7-cedc-4701-bf7e-fb331998607a@github.com>
References: <gCjGZ3L1xf4n4x9KXpskZ3EZhQdSBCTGN7TeunB1tbo=.764f7164-b96d-4822-a0ef-6333eab308e5@github.com>
 <kzDNaEjv4JB1fCp18abNS-8gH5nGCNQPmrXRtHVIMKQ=.d61080b7-cedc-4701-bf7e-fb331998607a@github.com>
Message-ID: <o3mg8o54OYaUGv0E2CWiCj8hoMmiy3a23DZ8PdhHdP4=.bfd0f483-3246-4c75-85c7-77bf9c313502@github.com>

On Sun, 27 Nov 2022 13:39:20 GMT, Andrey Turbanov <aturbanov 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`.
>
> src/java.base/share/classes/sun/security/x509/NetscapeCertTypeExtension.java line 281:
> 
>> 279:      */
>> 280:     public Enumeration<String> getElements() {
>> 281:         return mAttributeNames.elements();
> 
> Looks like we can drop `mAttributeNames` now. It was used only here.

Good catch. I've fixed it in a commit for https://github.com/openjdk/jdk/pull/11302, somewhat related.

-------------

PR: https://git.openjdk.org/jdk/pull/10934

From rriggs at openjdk.org  Mon Nov 28 23:05:54 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Nov 2022 23:05:54 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
Message-ID: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>

The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field assume the access flags are from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.

The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:

-------------

Commit messages:
 - 8297271: AccessFlags should be specific to class file version

Changes: https://git.openjdk.org/jdk/pull/11399/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11399&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297271
  Stats: 206 lines in 9 files changed: 198 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11399.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11399/head:pull/11399

PR: https://git.openjdk.org/jdk/pull/11399

From prr at openjdk.org  Mon Nov 28 23:27:55 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Nov 2022 23:27:55 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>

On Wed, 23 Nov 2022 18:57:03 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.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.desktop/share/classes/java/awt/package-info.java line 58:

> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
> 58:  *                  The Java AWT Native Interface (JAWT)</a>

Why only 1 of these 3 ?

src/java.desktop/share/classes/java/awt/package-info.java line 62:

> 60:  *
> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
> 62:  * @since 1.0

I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
But I also wonder why only the native_interface spec was added and not the other two ?

src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:

> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
> 225:      * @see #TAG_COMPRESSION
> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>

Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From mstjohns at comcast.net  Mon Nov 28 23:37:15 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 28 Nov 2022 18:37:15 -0500
Subject: RFR: 8296408: Make the PCSCException public accessible
In-Reply-To: <efb4484c-906a-f907-85e8-15ba01d4f462@oracle.com>
References: <4m2KP_3T6JqPbZgUV-YcX4yYXc7NqNK59Q_Jm-boAgs=.495df2e9-79c8-40df-a56b-110a26250b57@github.com>
 <cedc1d65-8309-f994-0ae0-555ab8567742@comcast.net>
 <oRDJJt_pp6JXSGofsVQb_hwdD08VeflQM0bbjnBo9Iw=.33f378f4-cc21-4799-af25-505f8052e2c0@github.com>
 <95161595-069f-59f3-4892-db256af4ead9@comcast.net>
 <efb4484c-906a-f907-85e8-15ba01d4f462@oracle.com>
Message-ID: <826d2141-6a19-9f08-8555-19bb63c8064f@comcast.net>

On 11/28/2022 1:10 PM, Sean Mullan wrote:
> PCSCException is an internal API and is strongly encapsulated by 
> default as of JDK 17 [1]. Applications should not be accessing it. 
> Making an internal API public is not the solution.
>
> Your suggestion to extend CardException with methods to provide/access 
> the underlying error code seems more reasonable. Making the error code 
> an enum, as Xuelei suggests also seems like it might be a cleaner 
> approach.

Enums won't work here for all possible return codes from SCard*.?? At 
least a few times I've gotten codes that indicate issues with the 
underlying driver or hardware than getting a well constrained set of 
error codes from SCard* calls that are all in winscard.h.

Ideally, a solution here should also be applicable to PKCS11 drivers.? 
And I'm sure there are a few other abstracted services where getting 
access to the underlying C return code makes sense.

If I were doing this in a more general way, I'd probably define 
something like

package java.lang;

public interface ErrorCodeInterface {

 ??? public long (int?) getErrorCode();

}

And have PKCS11Exception, PCSCException and any other exception that has 
gets thrown with the underlying code? (e.g. SQLException) implement that 
interface.

If we can't do that, then morphing CardException to use an error code 
and to be used in place of PCSCException for most of the internal code 
would seem to make the most sense.

Mike


>
> --Sean
>
> [1] https://openjdk.org/jeps/403
>
>
> On 11/23/22 12:21 PM, Michael StJohns wrote:
>> On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote:
>>> On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns 
>>> <mstjohns at comcast.net> wrote:
>>>
>>>> ? CardException doesn't always pass through the details in a 
>>>> comprehensible way from the underlying cause, ?
>>> Does it sound like a cause that the public APIs are not sufficient? 
>>> Alternatively, if it is possible to update the public APIs instead?
>>
>> I once actually wondered why PCSCException existed, rather than using or
>> extending CardException (e.g. besides simply to have a place to put all
>> of the SCARD related error messages).
>>
>> So you'd suggest extending CardException with a "getErrorCode()" method,
>> a constructor that takes an error code in addition to a message, and a
>> protected errorCode field.?? Have PCSCException extend CardException and
>> provide the current single argument constructor to create a
>> CardException with an error message based on the error code?
>>
>> One of the main reasons I would like a change like this is to deal with
>> Window's semi-weird behavior when listing terminals and no terminals are
>> found.? Right now I have to parse the returned message looking for
>> "SCARD_E_SERVICE_STOPPED" and if that occurs, I return an empty list of
>> terminals rather than continuing the throw.? There are a few of those
>> codes where it makes sense to translate them into different behavior.
>>
>> Mike
>>
>>
>>
>>
>>>
>>> Best,
>>> Xuelei
>>>
>>>
>>>> On Nov 22, 2022, at 6:59 PM, mlbridge[bot] ***@***.***> wrote:
>>>>
>>>>
>>>> Mailing list message from Michael StJohns ***@***.***> on 
>>>> security-dev ***@***.***>:
>>>>
>>>> On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
>>>>
>>>> Hi - Sorry - just getting back to the list after a few days away.
>>>>
>>>> Given that this is a plugin provider for the PCSC access classes, and
>>>> that CardException doesn't always pass through the details in a
>>>> comprehensible way from the underlying cause, having access to
>>>> PCSCException makes a lot of sense, and as far as I can tell is not a
>>>> violation of the general plugin contract.
>>>>
>>>> To make it even more useful, adding a "public long getErrorCode()"
>>>> method to PCSCException would help with the cases where a code that
>>>> isn't actually an? SCard* related code causing the PCSC exception.
>>>>
>>>> But -
>>>>
>>>> Wouldn't this also require a change to the module definition file?
>>>>
>>>> Mike
>>>>
>>>> ?
>>>> Reply to this email directly, view it on GitHub 
>>>> <https://github.com/openjdk/jdk/pull/11012#issuecomment-1324485877>, 
>>>> or unsubscribe 
>>>> <https://github.com/notifications/unsubscribe-auth/AQSB3EAII4OJ5UKKSZQAJHDWJWCC5ANCNFSM6AAAAAARY2PXGY>.
>>>> You are receiving this because you commented.
>>>>
>>> -------------
>>>
>>> PR: https://git.openjdk.org/jdk/pull/11012
>>
>>


From ascarpino at openjdk.org  Tue Nov 29 00:32:36 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 29 Nov 2022 00:32:36 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v5]
In-Reply-To: <7-omMJqslZjYB-nYcKyasj5bkNSDyCTXyj53yg7hpPI=.d9b796da-cf58-4591-8767-72beb67faf1e@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <7-omMJqslZjYB-nYcKyasj5bkNSDyCTXyj53yg7hpPI=.d9b796da-cf58-4591-8767-72beb67faf1e@github.com>
Message-ID: <Z66Np6KrK2x4QYpLcF8ytj1_jRHZgV3P01xxPiGctOY=.7d89ea7f-77ad-4aaf-8ea4-e5bba0bf183b@github.com>

On Tue, 22 Nov 2022 05:28:05 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 with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Merge with main
>  - Add AVX assertion guard
>  - Pull out common macro code into function parameter pack
>  - replace hi/lo word shuffles and left-right shift/or operations for vpshufd on byte-aligned rotations
>  - 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
>  - ... and 40 more: https://git.openjdk.org/jdk/compare/392ac705...bb3f4264

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 92:

> 90:     private long counter;
> 91: 
> 92:     // The 16-int state array and output keystream array:

I think it would help readability if these comments were separated for each declaration

-------------

PR: https://git.openjdk.org/jdk/pull/7702

From sviswanathan at openjdk.org  Tue Nov 29 01:20:19 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 29 Nov 2022 01:20:19 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
In-Reply-To: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
Message-ID: <e0ydkQxEpSfM0lVVgUjPrYI6LK1zpRqtam4thCSd7qA=.75c4b408-ff9a-42e1-9713-a7a7b331d48d@github.com>

On Wed, 23 Nov 2022 23:33:32 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Regarding mainline:
> - I decided not to 'unroll' the top while loop (i.e. `engineUpdate(byte[] input, int offset, int len)` is unrolled)
>    - It is debatable which version is easier to understand. If this version is 'too complex', I can unroll the top while loop. 
> - I do think this version is incremental (i.e. easier to review?):
>    - Move `remaining -= bytesToWrite;` into each `if` branch
>    - Change first `if` case to process multiple blocks instead of one
> 
> This `while` loop has a lot of cases to remember; Very roughly:
> 
> 1. process from previous call
> 2. process current data
> 3. store overflow
> 
> Interesting situations:
> - `blockOffset` might be non-`0`
> - `remaining+blockOffset` might not be enough to fill a single block. Or just enough for one block and to leave an overflow again..
> - etc.
> 
> Regarding testing
> - Correctness of intrinsic was already tested in https://github.com/openjdk/jdk/pull/10582 so not adding any tests there (i.e. no KAT)
> - In principle, fuzz test should also be sufficient to test bytebuffer (did increase repetitions)

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 260:

> 258:         if (buf.hasArray()) {
> 259:             byte[] input = buf.array();
> 260:             int offset = buf.arrayOffset();

arrayOffset returns the offset of the first element of the backing buffer. Need to also take into account the position() of the buffer here. We should also add test case for this.

-------------

PR: https://git.openjdk.org/jdk/pull/11338

From jnimeh at openjdk.org  Tue Nov 29 01:54:39 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 29 Nov 2022 01:54:39 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v6]
In-Reply-To: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
Message-ID: <cMgHkwaKCbVJ3j94ZDD18Ibz6Rj66cyO45Inghl4d4Q=.21b78364-60cb-420a-a3a3-2e41b529cf18@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:

  Split comment paragraph up for readability/clarity

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7702/files
  - new: https://git.openjdk.org/jdk/pull/7702/files/bb3f4264..b818411b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7702&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7702&range=04-05

  Stats: 10 lines in 1 file changed: 4 ins; 3 del; 3 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 29 01:54:43 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 29 Nov 2022 01:54:43 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v5]
In-Reply-To: <Z66Np6KrK2x4QYpLcF8ytj1_jRHZgV3P01xxPiGctOY=.7d89ea7f-77ad-4aaf-8ea4-e5bba0bf183b@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <7-omMJqslZjYB-nYcKyasj5bkNSDyCTXyj53yg7hpPI=.d9b796da-cf58-4591-8767-72beb67faf1e@github.com>
 <Z66Np6KrK2x4QYpLcF8ytj1_jRHZgV3P01xxPiGctOY=.7d89ea7f-77ad-4aaf-8ea4-e5bba0bf183b@github.com>
Message-ID: <l96RpLse1fCG0j9YfagS-gNVPNzXL1xQl_fDK8qMaHw=.5e4808e8-7e73-43c5-9e48-dd20e54a518b@github.com>

On Mon, 28 Nov 2022 22:58:26 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
>> 
>>  - Merge with main
>>  - Add AVX assertion guard
>>  - Pull out common macro code into function parameter pack
>>  - replace hi/lo word shuffles and left-right shift/or operations for vpshufd on byte-aligned rotations
>>  - 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
>>  - ... and 40 more: https://git.openjdk.org/jdk/compare/392ac705...bb3f4264
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 92:
> 
>> 90:     private long counter;
>> 91: 
>> 92:     // The 16-int state array and output keystream array:
> 
> I think it would help readability if these comments were separated for each declaration

Agreed.  I've split those up for each declaration as suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/7702

From darcy at openjdk.org  Tue Nov 29 02:42:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 29 Nov 2022 02:42:21 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
In-Reply-To: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
Message-ID: <5ADOFh1C_r2IlV1prDPgx2lcALXokCoIKzJ_IQyb7iI=.d37711d7-45f6-46b8-8037-e8ba04938aed@github.com>

On Mon, 28 Nov 2022 22:56:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field assume the access flags are from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.

Hmm. I don't agree with that characterization of the current situation. The AccessFlag class has a method that takes a ClassFileFormatVersion argument and there are regression tests of the AccessFlag feature that user downrev versions of class file to exercise all the functionality:

https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/reflect/AccessFlag/StrictAccessFlagTest.java

It is more accurate to say that the class file version is an *implicit* argument to all the give-me-the-access-flags functionality.
 
> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:

The current implementation does rely on the JVM "doing the right thing"(TM) in terms of screening out access_flags bits that are not appropriate for the class file version. However, I don't think this needs to be underlined, necessarily. Perhaps a sealed interface, strawman name AccessFlags, stated such a requirement for the core reflection classes?

-------------

PR: https://git.openjdk.org/jdk/pull/11399

From ascarpino at openjdk.org  Tue Nov 29 02:52:19 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 29 Nov 2022 02:52:19 GMT
Subject: RFR: 8247645: ChaCha20 intrinsics [v6]
In-Reply-To: <cMgHkwaKCbVJ3j94ZDD18Ibz6Rj66cyO45Inghl4d4Q=.21b78364-60cb-420a-a3a3-2e41b529cf18@github.com>
References: <oqKKgLvoD1R7Rqt682QnQvSNXYCvZyUwOaEqArSM2vw=.d8fef0af-b463-4ead-97f3-1ef1f456af85@github.com>
 <cMgHkwaKCbVJ3j94ZDD18Ibz6Rj66cyO45Inghl4d4Q=.21b78364-60cb-420a-a3a3-2e41b529cf18@github.com>
Message-ID: <BIin-R-wJCrSpH6IVPuCtgV-uYP10WGHYBpO6v6RcKI=.61d99a59-6a84-4fb4-b5f8-4f5be58d8df0@github.com>

On Tue, 29 Nov 2022 01:54:39 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:
> 
>   Split comment paragraph up for readability/clarity

Marked as reviewed by ascarpino (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/7702

From valeriep at openjdk.org  Tue Nov 29 05:03:08 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 29 Nov 2022 05:03:08 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <3JLuPRQa_laPXwih3H5mOgMg6QvsQOGG5Gqn616PAG4=.3a7c8e19-4a32-4fd5-bde7-3339c46dd268@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
 <6zTJxQ6Y0BGTvJVSCt8pkDYE2RlrFrVpegXOxpHSXzs=.6d3e8142-3f1b-4bfd-ba41-854f5f9b372d@github.com>
 <3JLuPRQa_laPXwih3H5mOgMg6QvsQOGG5Gqn616PAG4=.3a7c8e19-4a32-4fd5-bde7-3339c46dd268@github.com>
Message-ID: <lgbxMbBP454YJI3RFCPHaGdyBGsnBT9hJCsVrOO38X4=.42d35916-77ef-4c92-a43f-e4fbcb4eded5@github.com>

On Sun, 27 Nov 2022 16:25:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 300:
>> 
>>> 298:          * @exception CRLException on encoding errors.
>>> 299:          */
>>> 300:         public byte[] encodeInfo() throws CRLException {
>> 
>> "throws CRLException" can be removed?
>
> Inside the method there is
> 
> if ((version == 0) && (issuer.toString() == null))
>                 throw new CRLException("Null Issuer DN not allowed in v1 CRL");

I see.

>> src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 601:
>> 
>>> 599:      */
>>> 600:     public static X509CRLImpl newSigned(TBSCertList info, PrivateKey key, String algorithm, String provider)
>>> 601:             throws CRLException, NoSuchAlgorithmException, InvalidKeyException,
>> 
>> Does this method still has calls which throw CRLException?
>
> Because it calls `TBSCertList::encodeInfo`.

Ok.

>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 467:
>> 
>>> 465:      */
>>> 466:     public static X509CertImpl newSigned(X509CertInfo info, PrivateKey key, String algorithm, String provider)
>>> 467:             throws CertificateException, NoSuchAlgorithmException,
>> 
>> The javadoc above states that CertificateException is thrown on encoding errors. Will there still be encoding errors? The updated code seems not.
>
> Inside `X509CertInfo::emit`, there is
> 
>         if ((version.compare(CertificateVersion.V1) == 0) &&
>             (issuer.toString() == null))
>             throw new CertificateParsingException(
>                       "Null issuer DN not allowed in v1 certificate");
> 
> and more places where the exception might be thrown.

Ok.

>> src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java line 77:
>> 
>>> 75:     }
>>> 76: 
>>> 77:     final byte[] encode() throws GSSException {
>> 
>> Probably no need for GSSException?
>
> This is because `Oid::getDER` still throws it, and I don't want to modify a public API.

Ok.

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From pminborg at openjdk.org  Tue Nov 29 07:57:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 07:57:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
 <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>
Message-ID: <RiwpEqwEUkQFRs2nQvTR75dUEXQtiyJY9TQ2MJ8jTvA=.b052a5de-fa63-43e2-a7b8-51ff4b87bec1@github.com>

On Mon, 28 Nov 2022 19:35:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration.

I agree. A similar approach was done in a previous incarnation of the PR whereby we exposed a `ScopeAcqusition` that held an internal copy of the buffer and provided means to release. We feared that would cause performance regression. But your comment made me think of another way of doing acquire/release which would not expose the session and that would always be performant. I will explore this idea a bit more.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Tue Nov 29 09:40:58 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 09:40:58 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove session exposure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/eedf41ae..619473ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15-16

  Stats: 125 lines in 20 files changed: 11 ins; 13 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From mcimadamore at openjdk.org  Tue Nov 29 10:19:48 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Nov 2022 10:19:48 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <8HV7vdX-QrKG_OhlGWLwAG2uLsT8sKIbIqAce65bNWU=.68ffecbe-2065-418c-a0a5-1f0d04964717@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

This looks more symmetric, I like it. Since `acquire` was only really returning null if the underlying buffer had no associated session, I believe this rewriting preserves the semantics we had before (e.g. no accidental double releases).

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11260

From valeriep at openjdk.org  Tue Nov 29 12:56:32 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 29 Nov 2022 12:56:32 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v4]
In-Reply-To: <IYC2LdwDlHKTqQN19x8v0tAg9rA_-yLeUvOxINMcalY=.555307b4-2200-464f-9604-6cc7b6a2193d@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <IYC2LdwDlHKTqQN19x8v0tAg9rA_-yLeUvOxINMcalY=.555307b4-2200-464f-9604-6cc7b6a2193d@github.com>
Message-ID: <ClGmMIlAAvYyinVt9TIONgUtcP1brRYA33Da3WiY0yg=.ee3520e0-dec7-4810-8a86-cb8356fd2c70@github.com>

On Mon, 28 Nov 2022 22:09:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
>> 
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
>> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
>> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
>> - Some unused methods removed
>> - `DerOutputStream` is final
>> 
>> The only actual changes (still trivial) are:
>> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
>> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
>> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one extra removal

Marked as reviewed by valeriep (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From valeriep at openjdk.org  Tue Nov 29 12:56:33 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 29 Nov 2022 12:56:33 GMT
Subject: RFR: 8297065: DerOutputStream operations should not throw
 IOExceptions [v2]
In-Reply-To: <3JLuPRQa_laPXwih3H5mOgMg6QvsQOGG5Gqn616PAG4=.3a7c8e19-4a32-4fd5-bde7-3339c46dd268@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
 <K-cyWSNv1vbjPfCvlBIP3O6GTmpuFGo5xgU4XUUs-I8=.e4a8b3bb-9930-44cc-ad39-96334d8b2388@github.com>
 <6zTJxQ6Y0BGTvJVSCt8pkDYE2RlrFrVpegXOxpHSXzs=.6d3e8142-3f1b-4bfd-ba41-854f5f9b372d@github.com>
 <3JLuPRQa_laPXwih3H5mOgMg6QvsQOGG5Gqn616PAG4=.3a7c8e19-4a32-4fd5-bde7-3339c46dd268@github.com>
Message-ID: <MAdNUa7zvruo8xZhkQMPmFlRyvsjMD-WIdYm-nQNcbM=.fcbca92e-526f-4086-aaa4-581a3ecec2df@github.com>

On Sun, 27 Nov 2022 16:31:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 99:
>> 
>>> 97:     }
>>> 98: 
>>> 99:     private void makeEncoding(byte[] s) throws InvalidKeyException {
>> 
>> No need for the InvalidKeyException?
>
> `ECParameters::getAlgorithmParameters` throws it.

Hmm, alright.

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From weijun at openjdk.org  Tue Nov 29 13:00:40 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Nov 2022 13:00:40 GMT
Subject: Integrated: 8297065: DerOutputStream operations should not throw
 IOExceptions
In-Reply-To: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
References: <zEXII9L9aK_xFnho6TzG1AbBAfbOPKkge30ELQV9M6w=.8092bf38-3a36-4022-9bf1-e86d237220df@github.com>
Message-ID: <RO0g7Mn54KCER3xhnYXJqQ6RHTIdKgEeGc-LNNMvqq0=.5d750677-da02-4e93-830b-86eca804a027@github.com>

On Tue, 22 Nov 2022 22:29:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This is mostly cleanup. Everything around `DerOutputStream` no longer throws an `IOException`. This includes:
> 
> - Remove unnecessary `throws IOException` in code and spec
> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove further `throws` in code and spec
> - More classes implementing `DerEncoder` if they have a `encode(DerOutputStream)` method
> - Modify `write(bytes)` to `writeBytes(bytes)` to avoid IOE
> - Some unused methods removed
> - `DerOutputStream` is final
> 
> The only actual changes (still trivial) are:
> - Since `PKCS7::encodeSignedData(OutputStream out)` is removed, its usages in `PKCS7::constructToken` and `TsaSigner::createResponse` (in test) are modified to use another method with a `DerOutputStream` argument.
> - In PKCS8Key, since `getEncodedInternal` never returns non-null, remove null check on result
> - Since `DerOutputStream` is final, no need to clone bytes in `encode` of `X509CertImpl` and `X509CRLImpl`.

This pull request has now been integrated.

Changeset: 2deb318c
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2deb318c9f047ec5a4b160d66a4b52f93688ec42
Stats:     1158 lines in 109 files changed: 58 ins; 445 del; 655 mod

8297065: DerOutputStream operations should not throw IOExceptions

Reviewed-by: mullan, valeriep

-------------

PR: https://git.openjdk.org/jdk/pull/11302

From alanb at openjdk.org  Tue Nov 29 14:25:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 14:25:53 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <imPDtE3v_kdFiu-MpQbYCrhrZ3dUWEL5mFrIQL9jYNQ=.df5a4f44-64eb-4ded-94a8-967140a84ac6@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From jnimeh at openjdk.org  Tue Nov 29 14:45:18 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 29 Nov 2022 14:45:18 GMT
Subject: Integrated: 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: <7TC_Fp-S_S05XrWMZz1_tfLEwiCkAEw5iFERW__0s9Y=.cd1f838e-c893-4cb4-b54c-1a8667247e36@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.

This pull request has now been integrated.

Changeset: cd6bebbf
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd6bebbf34215723fad1d6bfe070a409351920c1
Stats:     1596 lines in 28 files changed: 1558 ins; 6 del; 32 mod

8247645: ChaCha20 intrinsics

Reviewed-by: sviswanathan, ngasson, vlivanov, ascarpino

-------------

PR: https://git.openjdk.org/jdk/pull/7702

From rriggs at openjdk.org  Tue Nov 29 15:36:21 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Nov 2022 15:36:21 GMT
Subject: RFR: 8297271: AccessFlags should be specific to class file version
In-Reply-To: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
Message-ID: <ghNYrJwn4nfLW9dKDG0ujSAWuq-7tCcfTh0JPrqlAg8=.14c5bc46-42bf-4d3d-b708-6f53f8b44333@github.com>

On Mon, 28 Nov 2022 22:56:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field assume the access flags are from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.
> 
> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:

Yes, the location information via `AccessFlags.locations(ClassFileFormatVersion)` provides the needed information.
And the tests verify that information.
My objective was to make the AccessFlags returned for a class reflect the class file format version number of the underlying class.  Currently, it is implicitly the current class file format version supported by the VM, not necessarily the version of the class loaded.
Suggestions welcome for how that is exposed in the APIs and implemented.

-------------

PR: https://git.openjdk.org/jdk/pull/11399

From weijun at openjdk.org  Tue Nov 29 16:09:21 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Nov 2022 16:09:21 GMT
Subject: RFR: 8297683: Use enhanced-for cycle instead of Enumeration in
 java.security.jgss
In-Reply-To: <pyQf2FNDpgDmd9iLBWkhsWu3eN3t8Nf8WJl9Ny-yHsw=.8cbc9c2b-f155-4068-bd29-3eaf24122302@github.com>
References: <pyQf2FNDpgDmd9iLBWkhsWu3eN3t8Nf8WJl9Ny-yHsw=.8cbc9c2b-f155-4068-bd29-3eaf24122302@github.com>
Message-ID: <2J7eah4mty3oFlzr3I-YDusTCMawjffVeM7EkjuKuFc=.8e85d6bc-b46e-421a-ac82-9d51ce1c7e3b@github.com>

On Sun, 27 Nov 2022 13:21:25 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.
> 
> sun.security.jgss.ProviderList#addAllMechsFromProvider
> sun.security.jgss.GSSCredentialImpl#dispose
> sun.security.jgss.GSSCredentialImpl#getRemainingLifetime
> sun.security.jgss.GSSCredentialImpl#getUsage()
> sun.security.jgss.GSSCredentialImpl#getElements

LGTM. Thanks.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11377

From psandoz at openjdk.org  Tue Nov 29 16:21:25 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 29 Nov 2022 16:21:25 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <V3gcPvdGTNp_x6EiidGcs3Lw28BZiT29_JmKI_WKv24=.6570b117-67d4-4890-be6a-7cbcbf58fbe7@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From weijun at openjdk.org  Tue Nov 29 16:44:29 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Nov 2022 16:44:29 GMT
Subject: RFR: 8297519: Improve expressions and modernise code [v2]
In-Reply-To: <0mZVaka7WvA8eV4b8yZYZ33Abv_zstEr9tN47dWpcbQ=.e6cfa946-a98b-48bb-a880-959d5e98bb41@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
 <0mZVaka7WvA8eV4b8yZYZ33Abv_zstEr9tN47dWpcbQ=.e6cfa946-a98b-48bb-a880-959d5e98bb41@github.com>
Message-ID: <Jit7wap-FD6NRUX35yqcJFvCTWKvG9PABGuIJN6QrS0=.82604267-d11d-4b41-9432-0a8778b7a7ee@github.com>

On Mon, 28 Nov 2022 11:59:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
>> 
>> 
>> This branch has been tested and passed tier1-4 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update from the first round of comments

Some small comments. I quickly went through all the changes and they look good. Some lines are a little too long, especially some exception throwing ones after `default ->`.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 375:

> 373:                     tagLen = type.defTagLen;
> 374:                 }
> 375:                 default -> throw new AssertionError("Unsupported type " + type);

`default` is unnecessary.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 210:

> 208:                 if (params instanceof ECParameterSpec) {
> 209:                     ecParams = P11ECKeyFactory.getECParameterSpec(
> 210:                             (ECParameterSpec) params);

Do you want to eliminate this cast (and the one below) using an instanceof variable?

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From pminborg at openjdk.org  Tue Nov 29 16:54:53 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 16:54:53 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
Message-ID: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>

This PR proposes a variety of modernisations to the `jdk.sctp` module.

During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 

* Replacing duplicate code segments 
* Making certain fields final 
* Using enhanced switch 
* Using records 
* Fixing typos 
* Marking fields participating in serialisation with `@Serial` 
* Modernizing toString() implementations 
* Using pattern matching 
* Using diamond operators

-------------

Commit messages:
 - Modernize module jdk.sctp

Changes: https://git.openjdk.org/jdk/pull/11418/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297778
  Stats: 609 lines in 31 files changed: 102 ins; 176 del; 331 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From jwaters at openjdk.org  Tue Nov 29 17:09:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Nov 2022 17:09:28 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@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>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
 <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>
 <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com>
Message-ID: <WgvP0-stpzWV4Z7nlCb2_bBFnP4W-siUmkatZ4I-2l0=.43cbd4c2-3475-4034-93ee-26a370be0016@github.com>

On Wed, 23 Nov 2022 21:36:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted.
>
> Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`.
> 
> One obvious and cheap solution to that would be to make that enum public.  I think that would be an improvement vs the current friend declaration.  But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used.  Here's a patch that I think cleans this up.
> 
> 
> diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
> index 0651f0868f3..bf9e759b1d6 100644
> --- a/src/hotspot/os/windows/os_windows.cpp
> +++ b/src/hotspot/os/windows/os_windows.cpp
> @@ -511,7 +511,9 @@ JNIEXPORT
>  LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo);
>  
>  // Thread start routine for all newly created threads
> -static unsigned __stdcall thread_native_entry(Thread* thread) {
> +// Called with the associated Thread* as the argument.
> +unsigned __stdcall os::win32::thread_native_entry(void* t) {
> +  Thread* thread = static_cast<Thread*>(t);
>  
>    thread->record_stack_base_and_size();
>    thread->initialize_thread_current();
> @@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type,
>      thread_handle =
>        (HANDLE)_beginthreadex(NULL,
>                               (unsigned)stack_size,
> -                             (unsigned (__stdcall *)(void*)) thread_native_entry,
> +                             &os::win32::thread_native_entry,
>                               thread,
>                               initflag,
>                               &thread_id);
> diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp
> index 94d7c3c5e2d..197797078d7 100644
> --- a/src/hotspot/os/windows/os_windows.hpp
> +++ b/src/hotspot/os/windows/os_windows.hpp
> @@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int);
>  
>  class os::win32 {
>    friend class os;
> -  friend unsigned __stdcall thread_native_entry(Thread*);
>  
>   protected:
>    static int    _processor_type;
> @@ -70,6 +69,10 @@ class os::win32 {
>    static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen);
>  
>   private:
> +  // The handler passed to _beginthreadex().
> +  // Called with the associated Thread* as the argument.
> +  static unsigned __stdcall thread_native_entry(void*);
> +
>    enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE };
>    // Wrapper around _endthreadex(), exit() and _exit()
>    static int exit_process_or_thread(Ept what, int exit_code);

The issue with that would be that thread_native_entry is declared as static to the compilation unit on other other Operating Systems as well, and having it as a static member on the win32 class instead would end up breaking this convention, for which I'm not sure if there's a reason why all of them are declared like this

-------------

PR: https://git.openjdk.org/jdk/pull/11081

From xuelei at openjdk.org  Tue Nov 29 17:43:46 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 29 Nov 2022 17:43:46 GMT
Subject: Integrated: 8295010: Reduce if required in EC limbs operations
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <OYmnjds3AlQnzaecH5-hKVWKLYbgWox8sp-NHEslIcY=.340f59c1-b091-46d3-820c-5a775a641682@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be 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

This pull request has now been integrated.

Changeset: b778cd52
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b778cd52b3fae013ecb21d90bcf940a4d947bd68
Stats:     141 lines in 8 files changed: 84 ins; 34 del; 23 mod

8295010: Reduce if required in EC limbs operations

Reviewed-by: djelinski, jjiang

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From dfuchs at openjdk.org  Tue Nov 29 17:46:22 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 17:46:22 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

It is a bit unusual to use a local class as a holder class (the typical manner is to a have a private static final nested class) but we didn't have local classes until recently - so maybe that's OK. I assume there's only one version of that class and it is static?

src/jdk.sctp/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java line 32:

> 30: public record SctpStdSocketOption<T>(String name,
> 31:                                      Class<T> type,
> 32:                                      int constValue)

This changes the implementation of `toString`, `equals` and `hashCode`. Have you verified that it is OK to do so?

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 33:

> 31: import java.io.FileDescriptor;
> 32: import java.io.IOException;
> 33: import java.util.*;

It would be better to avoid wildcards in regular imports.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From bpb at openjdk.org  Tue Nov 29 18:08:26 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Nov 2022 18:08:26 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <cvaemJgKtEOadHrbrClGy4eT618IkjsKXGi2NDyWTos=.2e0dc1d1-609b-4d75-aa90-020193c2896d@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From alanb at openjdk.org  Tue Nov 29 18:24:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 18:24:30 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <WvWhDAfncSEDBf2I-OBPqcBwr8xtUIZQCGNOd60yJRY=.ab709c05-4df4-44a5-a7c4-27f39ad30d6b@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

The SCTP hasn't had much TLC in some time, maybe JDK 6, so not surprising there is a lot of cleanup/modernization.

You'll need to add a copyright header to sun.nio.ch. sctp.Util. It's a pity there are duplicate copies.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From mullan at openjdk.org  Tue Nov 29 18:42:37 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Nov 2022 18:42:37 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <COA71eIf1yTfDX05C2FQC9myEfkArXleQJoT5QHgBxs=.5c54a0ff-60f9-4fac-b258-2bfab186a4cb@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <IeNqLbReNSKudHHptSXHrs3GHU6C3ZUaMgdhPOVw-RQ=.6877fdb5-f4e3-4cca-ac62-700c79eaf75b@github.com>
 <DFEGuptXrvJdjk7tvjnfYrGowpo5Ht0Ld6vTrVgB4PE=.b15b75e0-5269-42b4-abab-3370cc82c397@github.com>
 <COA71eIf1yTfDX05C2FQC9myEfkArXleQJoT5QHgBxs=.5c54a0ff-60f9-4fac-b258-2bfab186a4cb@github.com>
Message-ID: <7z4a9oQWKa2lgN4p9i-IrgZmYeHdlvUB89ntR5w-GT0=.785f27a9-9730-42cf-818f-f21ba44305e9@github.com>

On Wed, 23 Nov 2022 08:05:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> Can you share the updated benchmarks?
>> 
>> The benchmark number in the PR description is the latest run that I have.  I may run it again after the integration of multiplicative inversion and point  multiplication improvement.
>
>> I may run it again after the integration of multiplicative inversion and point multiplication improvement.
> 
> After the integration of the improvement above, here is the benchmark numbers with this patch:
> 
> Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
> Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1084.556 ? 135.637  ops/s
> Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1168.663 ?  25.072  ops/s
> Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1186.863 ?  16.224  ops/s
> Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1095.034 ?   6.462  ops/s
> Signatures.EdDSA.sign              Ed448               64  thrpt   15   323.771 ?   2.156  ops/s
> Signatures.EdDSA.sign              Ed448              512  thrpt   15   326.995 ?   2.101  ops/s
> Signatures.EdDSA.sign              Ed448             2048  thrpt   15   320.799 ?   5.452  ops/s
> Signatures.EdDSA.sign              Ed448            16384  thrpt   15   317.715 ?   2.554  ops/s
> Signatures.sign                secp256r1               64  thrpt   15  4072.636 ?  22.441  ops/s
> Signatures.sign                secp256r1              512  thrpt   15  4048.822 ?  40.769  ops/s
> Signatures.sign                secp256r1             2048  thrpt   15  4042.884 ?  20.147  ops/s
> Signatures.sign                secp256r1            16384  thrpt   15  3911.856 ?  12.039  ops/s
> Signatures.sign                secp384r1               64  thrpt   15   634.203 ?   4.532  ops/s
> Signatures.sign                secp384r1              512  thrpt   15   637.623 ?   1.592  ops/s
> Signatures.sign                secp384r1             2048  thrpt   15   620.283 ?  10.014  ops/s
> Signatures.sign                secp384r1            16384  thrpt   15   622.617 ?   5.695  ops/s
> Signatures.sign                secp521r1               64  thrpt   15   311.957 ?   5.420  ops/s
> Signatures.sign                secp521r1              512  thrpt   15   316.605 ?   2.204  ops/s
> Signatures.sign                secp521r1             2048  thrpt   15   316.700 ?   1.654  ops/s
> Signatures.sign                secp521r1            16384  thrpt   15   309.599 ?   7.167  ops/s
> 
> 
> and the numbers without this patch:
> 
> Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
> Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1138.578 ?  57.908  ops/s
> Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1172.242 ?  17.180  ops/s
> Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1163.793 ?  21.095  ops/s
> Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1093.856 ?   5.964  ops/s
> Signatures.EdDSA.sign              Ed448               64  thrpt   15   324.089 ?   2.894  ops/s
> Signatures.EdDSA.sign              Ed448              512  thrpt   15   323.580 ?   1.437  ops/s
> Signatures.EdDSA.sign              Ed448             2048  thrpt   15   323.680 ?   2.555  ops/s
> Signatures.EdDSA.sign              Ed448            16384  thrpt   15   310.641 ?   2.256  ops/s
> Signatures.sign                secp256r1               64  thrpt   15  4070.733 ?  27.059  ops/s
> Signatures.sign                secp256r1              512  thrpt   15  4061.835 ?  18.776  ops/s
> Signatures.sign                secp256r1             2048  thrpt   15  4041.226 ?  19.082  ops/s
> Signatures.sign                secp256r1            16384  thrpt   15  3893.323 ?  11.869  ops/s
> Signatures.sign                secp384r1               64  thrpt   15   632.924 ?   8.273  ops/s
> Signatures.sign                secp384r1              512  thrpt   15   628.807 ?   7.604  ops/s
> Signatures.sign                secp384r1             2048  thrpt   15   631.052 ?   1.782  ops/s
> Signatures.sign                secp384r1            16384  thrpt   15   530.402 ? 122.967  ops/s
> Signatures.sign                secp521r1               64  thrpt   15   316.634 ?   1.724  ops/s
> Signatures.sign                secp521r1              512  thrpt   15   315.830 ?   2.333  ops/s
> Signatures.sign                secp521r1             2048  thrpt   15   315.855 ?   1.093  ops/s
> Signatures.sign                secp521r1            16384  thrpt   15   315.019 ?   1.124  ops/s

@XueleiFan, I have some questions about this integration. The performance numbers you last posted showed some very small improvements but also some regressions in throughput numbers, so its not clear to me if this is worth integrating yet. Earlier, you said that the performance benefits of this fix would not be realized until the changes for https://github.com/openjdk/jdk/pull/10398 were to be integrated, but that change is still in draft and has comments that have not been resolved. So, is it possible this was integrated too early?

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From xuelei at openjdk.org  Tue Nov 29 18:57:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 29 Nov 2022 18:57:30 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <7z4a9oQWKa2lgN4p9i-IrgZmYeHdlvUB89ntR5w-GT0=.785f27a9-9730-42cf-818f-f21ba44305e9@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <IeNqLbReNSKudHHptSXHrs3GHU6C3ZUaMgdhPOVw-RQ=.6877fdb5-f4e3-4cca-ac62-700c79eaf75b@github.com>
 <DFEGuptXrvJdjk7tvjnfYrGowpo5Ht0Ld6vTrVgB4PE=.b15b75e0-5269-42b4-abab-3370cc82c397@github.com>
 <COA71eIf1yTfDX05C2FQC9myEfkArXleQJoT5QHgBxs=.5c54a0ff-60f9-4fac-b258-2bfab186a4cb@github.com>
 <7z4a9oQWKa2lgN4p9i-IrgZmYeHdlvUB89ntR5w-GT0=.785f27a9-9730-42cf-818f-f21ba44305e9@github.com>
Message-ID: <fzaoHPRsji4ERTWNmntfn0YE1xxQQcOXbBL6KEu2CWk=.ff5e3f7b-720a-4026-9bb1-1861d9aae394@github.com>

On Tue, 29 Nov 2022 18:38:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> I may run it again after the integration of multiplicative inversion and point multiplication improvement.
>> 
>> After the integration of the improvement above, here is the benchmark numbers with this patch:
>> 
>> Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1084.556 ? 135.637  ops/s
>> Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1168.663 ?  25.072  ops/s
>> Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1186.863 ?  16.224  ops/s
>> Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1095.034 ?   6.462  ops/s
>> Signatures.EdDSA.sign              Ed448               64  thrpt   15   323.771 ?   2.156  ops/s
>> Signatures.EdDSA.sign              Ed448              512  thrpt   15   326.995 ?   2.101  ops/s
>> Signatures.EdDSA.sign              Ed448             2048  thrpt   15   320.799 ?   5.452  ops/s
>> Signatures.EdDSA.sign              Ed448            16384  thrpt   15   317.715 ?   2.554  ops/s
>> Signatures.sign                secp256r1               64  thrpt   15  4072.636 ?  22.441  ops/s
>> Signatures.sign                secp256r1              512  thrpt   15  4048.822 ?  40.769  ops/s
>> Signatures.sign                secp256r1             2048  thrpt   15  4042.884 ?  20.147  ops/s
>> Signatures.sign                secp256r1            16384  thrpt   15  3911.856 ?  12.039  ops/s
>> Signatures.sign                secp384r1               64  thrpt   15   634.203 ?   4.532  ops/s
>> Signatures.sign                secp384r1              512  thrpt   15   637.623 ?   1.592  ops/s
>> Signatures.sign                secp384r1             2048  thrpt   15   620.283 ?  10.014  ops/s
>> Signatures.sign                secp384r1            16384  thrpt   15   622.617 ?   5.695  ops/s
>> Signatures.sign                secp521r1               64  thrpt   15   311.957 ?   5.420  ops/s
>> Signatures.sign                secp521r1              512  thrpt   15   316.605 ?   2.204  ops/s
>> Signatures.sign                secp521r1             2048  thrpt   15   316.700 ?   1.654  ops/s
>> Signatures.sign                secp521r1            16384  thrpt   15   309.599 ?   7.167  ops/s
>> 
>> 
>> and the numbers without this patch:
>> 
>> Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1138.578 ?  57.908  ops/s
>> Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1172.242 ?  17.180  ops/s
>> Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1163.793 ?  21.095  ops/s
>> Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1093.856 ?   5.964  ops/s
>> Signatures.EdDSA.sign              Ed448               64  thrpt   15   324.089 ?   2.894  ops/s
>> Signatures.EdDSA.sign              Ed448              512  thrpt   15   323.580 ?   1.437  ops/s
>> Signatures.EdDSA.sign              Ed448             2048  thrpt   15   323.680 ?   2.555  ops/s
>> Signatures.EdDSA.sign              Ed448            16384  thrpt   15   310.641 ?   2.256  ops/s
>> Signatures.sign                secp256r1               64  thrpt   15  4070.733 ?  27.059  ops/s
>> Signatures.sign                secp256r1              512  thrpt   15  4061.835 ?  18.776  ops/s
>> Signatures.sign                secp256r1             2048  thrpt   15  4041.226 ?  19.082  ops/s
>> Signatures.sign                secp256r1            16384  thrpt   15  3893.323 ?  11.869  ops/s
>> Signatures.sign                secp384r1               64  thrpt   15   632.924 ?   8.273  ops/s
>> Signatures.sign                secp384r1              512  thrpt   15   628.807 ?   7.604  ops/s
>> Signatures.sign                secp384r1             2048  thrpt   15   631.052 ?   1.782  ops/s
>> Signatures.sign                secp384r1            16384  thrpt   15   530.402 ? 122.967  ops/s
>> Signatures.sign                secp521r1               64  thrpt   15   316.634 ?   1.724  ops/s
>> Signatures.sign                secp521r1              512  thrpt   15   315.830 ?   2.333  ops/s
>> Signatures.sign                secp521r1             2048  thrpt   15   315.855 ?   1.093  ops/s
>> Signatures.sign                secp521r1            16384  thrpt   15   315.019 ?   1.124  ops/s
>
> @XueleiFan, I have some questions about this integration. The performance numbers you last posted showed some very small improvements but also some regressions in throughput numbers, so its not clear to me if this is worth integrating yet. Earlier, you said that the performance benefits of this fix would not be realized until the changes for https://github.com/openjdk/jdk/pull/10398 were to be integrated, but that change is still in draft and has comments that have not been resolved. So, is it possible this was integrated too early?

@seanjmullan if you check the benchmark numbers, the throughput impact is limited.  For some curves, it is improved; and some others is impacted.  In theory of this update, it is not expected to have performance impact if no improvement.  The throughput impact in the benchmark is more from the noice in the benchmark platform, I think.

The fix for [10398](https://github.com/openjdk/jdk/pull/10398) depends on this update.  Only after integrating this one, I can open  [10398](https://github.com/openjdk/jdk/pull/10398) for review.  The code is ready for  [10398](https://github.com/openjdk/jdk/pull/10398) , I'm running the benchmarking.  Once the benchmark numbers are ready, I will open it for review.  It should be ready to review today.

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From xuelei at openjdk.org  Tue Nov 29 18:57:57 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 29 Nov 2022 18:57:57 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation [v3]
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <FtOnx9rnrxKvdinJTqW1mz0qH4Ht2S7UNGOrKLS_wmw=.977219c7-79d7-4bcc-9252-ff2ea7a80c9d@github.com>

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> 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 four commits:

 - Merge
 - remove duplicated bench tests
 - remove tailing white spaces
 - 8294248: Use less limbs for P256 in EC implementation

-------------

Changes: https://git.openjdk.org/jdk/pull/10398/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10398&range=02
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10398.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10398/head:pull/10398

PR: https://git.openjdk.org/jdk/pull/10398

From xuelei at openjdk.org  Tue Nov 29 19:05:39 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 29 Nov 2022 19:05:39 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation
In-Reply-To: <NyKl5HSgB7TqJny9gAKYAt1VQpNFdd3Iwwv-HdD8pjY=.8c71f7c9-83d7-4a82-a8d0-c084044164c7@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <NyKl5HSgB7TqJny9gAKYAt1VQpNFdd3Iwwv-HdD8pjY=.8c71f7c9-83d7-4a82-a8d0-c084044164c7@github.com>
Message-ID: <WfnFLTHApvvrcb5nqWirC88Wm7vnpsiKmj87wSxfeEo=.4afaa1a0-b08a-4fe3-b6ae-249a3d9843f5@github.com>

On Sun, 25 Sep 2022 05:52:01 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> I may re-open it again when the long overflow issues get addressed.

The issue has been addressed in [PR 10624](https://github.com/openjdk/jdk/pull/10624).  Please review this update. 

I will post the new benchmark numbers soon, for the latest performance after integration of  [PR 10624](https://github.com/openjdk/jdk/pull/10624),  [PR 10544](https://github.com/openjdk/jdk/pull/10544) and [PR 10893](https://github.com/openjdk/jdk/pull/10893).

-------------

PR: https://git.openjdk.org/jdk/pull/10398

From ihse at openjdk.org  Tue Nov 29 19:26:36 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Nov 2022 19:26:36 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: <D-_pSm7C9d1Wdx-g6Tz0PTX_7CgFMitkkGCV907jv_8=.77ff6af8-466b-42ab-a015-73589600dab1@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

Yes bot, I know. I'll need to split this up into multiple steps, but please keep this open for a while more. Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From rriggs at openjdk.org  Tue Nov 29 19:26:38 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Nov 2022 19:26:38 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

src/jdk.sctp/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 39:

> 37: import com.sun.nio.sctp.SctpSocketOption;
> 38: 
> 39: import static sun.nio.ch.sctp.Util.sctpNotSupported;

Not really a fan of static imports like this; it looks like a local method in the code but is not. 
In this case, the code would be more readable as `Util.sctpNotSupported()`.
This style of creating exceptions to throw is unusual in OpenJDK.

src/jdk.sctp/aix/classes/sun/nio/ch/sctp/Util.java line 1:

> 1: package sun.nio.ch.sctp;

Can this be shared in **share**/classes/sun/nio/sctp/Util.java?

src/jdk.sctp/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 44:

> 42:  * Unimplemented.
> 43:  */
> 44: public class SctpChannelImpl extends SctpChannel {

Going a bit beyond just updating syntax; but that's a different PR...
There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception.  There would less duplication for unsupported platforms.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 722:

> 720: 
> 721:     /**
> 722:      * @throws IllegalArgumentException If the given association is not controlled by this channel

There should be a 1st sentence describing the function; its odd to see only an @throws.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From mullan at openjdk.org  Tue Nov 29 19:37:27 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Nov 2022 19:37:27 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v5]
In-Reply-To: <7z4a9oQWKa2lgN4p9i-IrgZmYeHdlvUB89ntR5w-GT0=.785f27a9-9730-42cf-818f-f21ba44305e9@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
 <iZuCJ2e5xxkBtKUl93cUcaqgRG4xQC7jcepqI_WZLO0=.a1785cad-c040-48e1-be2c-2265f19f136f@github.com>
 <IeNqLbReNSKudHHptSXHrs3GHU6C3ZUaMgdhPOVw-RQ=.6877fdb5-f4e3-4cca-ac62-700c79eaf75b@github.com>
 <DFEGuptXrvJdjk7tvjnfYrGowpo5Ht0Ld6vTrVgB4PE=.b15b75e0-5269-42b4-abab-3370cc82c397@github.com>
 <COA71eIf1yTfDX05C2FQC9myEfkArXleQJoT5QHgBxs=.5c54a0ff-60f9-4fac-b258-2bfab186a4cb@github.com>
 <7z4a9oQWKa2lgN4p9i-IrgZmYeHdlvUB89ntR5w-GT0=.785f27a9-9730-42cf-818f-f21ba44305e9@github.com>
Message-ID: <PntuSonNscjz4I6HHlsgw_PuPCEr5qcHvPZKB6gk2PQ=.0f85b68a-8687-475a-b276-0f75e8a99f76@github.com>

On Tue, 29 Nov 2022 18:38:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> I may run it again after the integration of multiplicative inversion and point multiplication improvement.
>> 
>> After the integration of the improvement above, here is the benchmark numbers with this patch:
>> 
>> Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1084.556 ? 135.637  ops/s
>> Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1168.663 ?  25.072  ops/s
>> Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1186.863 ?  16.224  ops/s
>> Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1095.034 ?   6.462  ops/s
>> Signatures.EdDSA.sign              Ed448               64  thrpt   15   323.771 ?   2.156  ops/s
>> Signatures.EdDSA.sign              Ed448              512  thrpt   15   326.995 ?   2.101  ops/s
>> Signatures.EdDSA.sign              Ed448             2048  thrpt   15   320.799 ?   5.452  ops/s
>> Signatures.EdDSA.sign              Ed448            16384  thrpt   15   317.715 ?   2.554  ops/s
>> Signatures.sign                secp256r1               64  thrpt   15  4072.636 ?  22.441  ops/s
>> Signatures.sign                secp256r1              512  thrpt   15  4048.822 ?  40.769  ops/s
>> Signatures.sign                secp256r1             2048  thrpt   15  4042.884 ?  20.147  ops/s
>> Signatures.sign                secp256r1            16384  thrpt   15  3911.856 ?  12.039  ops/s
>> Signatures.sign                secp384r1               64  thrpt   15   634.203 ?   4.532  ops/s
>> Signatures.sign                secp384r1              512  thrpt   15   637.623 ?   1.592  ops/s
>> Signatures.sign                secp384r1             2048  thrpt   15   620.283 ?  10.014  ops/s
>> Signatures.sign                secp384r1            16384  thrpt   15   622.617 ?   5.695  ops/s
>> Signatures.sign                secp521r1               64  thrpt   15   311.957 ?   5.420  ops/s
>> Signatures.sign                secp521r1              512  thrpt   15   316.605 ?   2.204  ops/s
>> Signatures.sign                secp521r1             2048  thrpt   15   316.700 ?   1.654  ops/s
>> Signatures.sign                secp521r1            16384  thrpt   15   309.599 ?   7.167  ops/s
>> 
>> 
>> and the numbers without this patch:
>> 
>> Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score     Error  Units
>> Signatures.EdDSA.sign            Ed25519               64  thrpt   15  1138.578 ?  57.908  ops/s
>> Signatures.EdDSA.sign            Ed25519              512  thrpt   15  1172.242 ?  17.180  ops/s
>> Signatures.EdDSA.sign            Ed25519             2048  thrpt   15  1163.793 ?  21.095  ops/s
>> Signatures.EdDSA.sign            Ed25519            16384  thrpt   15  1093.856 ?   5.964  ops/s
>> Signatures.EdDSA.sign              Ed448               64  thrpt   15   324.089 ?   2.894  ops/s
>> Signatures.EdDSA.sign              Ed448              512  thrpt   15   323.580 ?   1.437  ops/s
>> Signatures.EdDSA.sign              Ed448             2048  thrpt   15   323.680 ?   2.555  ops/s
>> Signatures.EdDSA.sign              Ed448            16384  thrpt   15   310.641 ?   2.256  ops/s
>> Signatures.sign                secp256r1               64  thrpt   15  4070.733 ?  27.059  ops/s
>> Signatures.sign                secp256r1              512  thrpt   15  4061.835 ?  18.776  ops/s
>> Signatures.sign                secp256r1             2048  thrpt   15  4041.226 ?  19.082  ops/s
>> Signatures.sign                secp256r1            16384  thrpt   15  3893.323 ?  11.869  ops/s
>> Signatures.sign                secp384r1               64  thrpt   15   632.924 ?   8.273  ops/s
>> Signatures.sign                secp384r1              512  thrpt   15   628.807 ?   7.604  ops/s
>> Signatures.sign                secp384r1             2048  thrpt   15   631.052 ?   1.782  ops/s
>> Signatures.sign                secp384r1            16384  thrpt   15   530.402 ? 122.967  ops/s
>> Signatures.sign                secp521r1               64  thrpt   15   316.634 ?   1.724  ops/s
>> Signatures.sign                secp521r1              512  thrpt   15   315.830 ?   2.333  ops/s
>> Signatures.sign                secp521r1             2048  thrpt   15   315.855 ?   1.093  ops/s
>> Signatures.sign                secp521r1            16384  thrpt   15   315.019 ?   1.124  ops/s
>
> @XueleiFan, I have some questions about this integration. The performance numbers you last posted showed some very small improvements but also some regressions in throughput numbers, so its not clear to me if this is worth integrating yet. Earlier, you said that the performance benefits of this fix would not be realized until the changes for https://github.com/openjdk/jdk/pull/10398 were to be integrated, but that change is still in draft and has comments that have not been resolved. So, is it possible this was integrated too early?

> @seanjmullan if you check the benchmark numbers, the throughput impact is limited. For some curves, it is improved; and some others is impacted. In theory of this update, it is not expected to have performance impact if no improvement. The throughput impact in the benchmark is more from the noice in the benchmark platform, I think.
> 
> The fix for [10398](https://github.com/openjdk/jdk/pull/10398) depends on this update. Only after integrating this one, I can open [10398](https://github.com/openjdk/jdk/pull/10398) for review. The code is ready for [10398](https://github.com/openjdk/jdk/pull/10398) , I'm running the benchmarking. Once the benchmark numbers are ready, I will open it for review. It should be ready to review today.

Ok, thanks for the update. Will keep an eye out for the updated benchmark numbers.

-------------

PR: https://git.openjdk.org/jdk/pull/10624

From alanb at openjdk.org  Tue Nov 29 20:27:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 20:27:22 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>
Message-ID: <9yk8TUxvPGC2gkULFMyTaprQ5WGiaJnaGBsJ4z1WQwM=.d9b3ba36-0219-40a0-80df-b3ff6c0fdb94@github.com>

On Tue, 29 Nov 2022 19:24:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception. There would less duplication for unsupported platforms.

I think this is accident of history. As I recall, the "unsupported implementation" was Windows only in JDK 6 but it has since been copied. It could be cleaned up.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From xuelei at openjdk.org  Tue Nov 29 20:47:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 29 Nov 2022 20:47:32 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation [v3]
In-Reply-To: <FtOnx9rnrxKvdinJTqW1mz0qH4Ht2S7UNGOrKLS_wmw=.977219c7-79d7-4bcc-9252-ff2ea7a80c9d@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <FtOnx9rnrxKvdinJTqW1mz0qH4Ht2S7UNGOrKLS_wmw=.977219c7-79d7-4bcc-9252-ff2ea7a80c9d@github.com>
Message-ID: <OykDqJcYgojdhklKGi0Awy0sK8s6Ze8PxKUlaC1qycE=.bd3f9a8f-7864-446a-9c64-04d9fa1eda1e@github.com>

On Tue, 29 Nov 2022 18:57:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
>> 
>> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
>> 
>> Here are the benchmark numbers without the patch:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
>> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
>> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
>> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
>> 
>> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
>> 
>> 
>> And here are the numbers with the patch applied:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
>> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
>> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
>> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
>> 
>> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
>> 
>> 
>> 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 four commits:
> 
>  - Merge
>  - remove duplicated bench tests
>  - remove tailing white spaces
>  - 8294248: Use less limbs for P256 in EC implementation

Here is the latest benchmark numbers, after the integration of https://github.com/openjdk/jdk/pull/10624, https://github.com/openjdk/jdk/pull/10544 and https://github.com/openjdk/jdk/pull/10893. 

with this patch:

Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign                secp256r1               64  thrpt   15  4767.902 ? 26.834  ops/s
Signatures.sign                secp256r1              512  thrpt   15  4755.802 ? 41.800  ops/s
Signatures.sign                secp256r1             2048  thrpt   15  4728.560 ? 55.913  ops/s
Signatures.sign                secp256r1            16384  thrpt   15  4488.473 ? 60.325  ops/s


without this patch:

Benchmark                    (algorithm)  (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign                secp256r1               64  thrpt   15  4089.026 ? 22.034  ops/s
Signatures.sign                secp256r1              512  thrpt   15  4081.396 ? 25.416  ops/s
Signatures.sign                secp256r1             2048  thrpt   15  4080.277 ? 24.239  ops/s
Signatures.sign                secp256r1            16384  thrpt   15  3926.398 ? 14.582  ops/s


The performance improvement is about 15%.  

Comparing to the numbers in the PR description, the performance improvement is about 240% with the update for [this PR](https://github.com/openjdk/jdk/pull/10398), https://github.com/openjdk/jdk/pull/10624, https://github.com/openjdk/jdk/pull/10544 and https://github.com/openjdk/jdk/pull/10893.

-------------

PR: https://git.openjdk.org/jdk/pull/10398

From jpai at openjdk.org  Wed Nov 30 00:40:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:40:21 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <yt80pFqXzOAv8ZoCHgjvBBruV1kcdXmPt-xEFPqfrr8=.ad0cd2c4-b730-4362-b031-337991eff415@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Thank you everyone for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From jpai at openjdk.org  Wed Nov 30 00:40:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:40:21 GMT
Subject: Integrated: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <E09ZXv_6AoFNPWbC2-vUhfflo09LMQMBXc5BoX-Pe7c=.8d7cafee-51cb-4f6d-b927-cef4ef4d06d0@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

This pull request has now been integrated.

Changeset: 0ce18272
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ce182723b8d3a98c71c1b71fa1d3f5a7479fba8
Stats:     20 lines in 19 files changed: 0 ins; 0 del; 20 mod

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Co-authored-by: Michael Ernst <mernst at openjdk.org>
Reviewed-by: alanb, lancea, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From smarks at openjdk.org  Wed Nov 30 04:07:20 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 30 Nov 2022 04:07:20 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <yl-EhpqgisOsGCpZN4p0QKEWmARfvrF2n3-rFooXPn8=.7ecd8165-a25d-4e1e-b41e-8b307b28810c@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Various changes such as fixing spelling errors, addition of `@Serial`, removing redundant type arguments, using `instanceof` patterns, and using switch expressions seem fine to me. However, I'll defer to the judgment of the maintainers of this code.

If a larger-scale refactoring is done to reduce the redundancy of UOE-throwing for the platforms where SCTP isn't supported, I'd recommend doing it in a separate bug/PR.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java line 66:

> 64:             default -> throw new AssertionError(
> 65:                     "Unknown Association Change Event type: " + intEvent);
> 66:         };

You might consider lining up the arrows of the non-default cases. The default case is quite different so I think it's ok to have it unaligned, in fact that's probably preferable. Similar alignment can be done in a few other places.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 886:

> 884:                     resultContainer.getSendFailed(), attachment);
> 885:             case SHUTDOWN -> absHandler.handleNotification(
> 886:                     resultContainer.getShutdown(), attachment);

Unfortunately since the code in each case is (probably) too long to fit on a line, lining up the arrows doesn't help. I guess what's here is ok. If I were maintaining this code, I'd try to make the names shorter in order for everything to fit on a single line... but that's probably out of scope. Also unfortunately, even though the code in each case has a very similar structure, there is redundancy across the classes that makes unifying the cases difficult. Specifically, resultContainer.type() returns a type, which is switched on to call different getter methods on resultContainer; the return value in turn is passed to different but corresponding overloads of absHandler.handleNotification. It seems to me that there ought to be a better way to structure this. Possibly pass the absHandler to the resultContainer and have it call the appropriate handleNotification() overload depending on what type it is? But that's also probably out of scope for this change.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From dholmes at openjdk.org  Wed Nov 30 06:07:30 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Nov 2022 06:07:30 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <WgvP0-stpzWV4Z7nlCb2_bBFnP4W-siUmkatZ4I-2l0=.43cbd4c2-3475-4034-93ee-26a370be0016@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>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
 <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>
 <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com>
 <WgvP0-stpzWV4Z7nlCb2_bBFnP4W-siUmkatZ4I-2l0=.43cbd4c2-3475-4034-93ee-26a370be0016@github.com>
Message-ID: <5dO9bO57dyw99J9wxZceMOy1FujzO-JFXWxODl3LlCc=.e37a178a-21c9-4aec-97f0-ec01eb3903b0@github.com>

On Tue, 29 Nov 2022 17:07:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`.
>> 
>> One obvious and cheap solution to that would be to make that enum public.  I think that would be an improvement vs the current friend declaration.  But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used.  Here's a patch that I think cleans this up.
>> 
>> 
>> diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
>> index 0651f0868f3..bf9e759b1d6 100644
>> --- a/src/hotspot/os/windows/os_windows.cpp
>> +++ b/src/hotspot/os/windows/os_windows.cpp
>> @@ -511,7 +511,9 @@ JNIEXPORT
>>  LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo);
>>  
>>  // Thread start routine for all newly created threads
>> -static unsigned __stdcall thread_native_entry(Thread* thread) {
>> +// Called with the associated Thread* as the argument.
>> +unsigned __stdcall os::win32::thread_native_entry(void* t) {
>> +  Thread* thread = static_cast<Thread*>(t);
>>  
>>    thread->record_stack_base_and_size();
>>    thread->initialize_thread_current();
>> @@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type,
>>      thread_handle =
>>        (HANDLE)_beginthreadex(NULL,
>>                               (unsigned)stack_size,
>> -                             (unsigned (__stdcall *)(void*)) thread_native_entry,
>> +                             &os::win32::thread_native_entry,
>>                               thread,
>>                               initflag,
>>                               &thread_id);
>> diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp
>> index 94d7c3c5e2d..197797078d7 100644
>> --- a/src/hotspot/os/windows/os_windows.hpp
>> +++ b/src/hotspot/os/windows/os_windows.hpp
>> @@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int);
>>  
>>  class os::win32 {
>>    friend class os;
>> -  friend unsigned __stdcall thread_native_entry(Thread*);
>>  
>>   protected:
>>    static int    _processor_type;
>> @@ -70,6 +69,10 @@ class os::win32 {
>>    static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen);
>>  
>>   private:
>> +  // The handler passed to _beginthreadex().
>> +  // Called with the associated Thread* as the argument.
>> +  static unsigned __stdcall thread_native_entry(void*);
>> +
>>    enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE };
>>    // Wrapper around _endthreadex(), exit() and _exit()
>>    static int exit_process_or_thread(Ept what, int exit_code);
>
> The issue with that would be that thread_native_entry is declared as static to the compilation unit on other other Operating Systems as well, and having it as a static member on the win32 class instead would end up breaking this convention, for which I'm not sure if there's a reason why all of them are declared like this

The thread entry functions are expected to be plain C functions as we use C library calls to create threads (`_beginthreadex`, `pthread_create`) not C++. They don't need to be visible outside the compilation unit hence static.

-------------

PR: https://git.openjdk.org/jdk/pull/11081

From xuelei at openjdk.org  Wed Nov 30 07:38:14 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 30 Nov 2022 07:38:14 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation [v4]
In-Reply-To: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
Message-ID: <0pXx3wYDSwt27ueLb9BN3lsnPoCJHZc2HJQns4z7YJI=.71858b34-e421-4bf3-8992-e74bb4ae6c7c@github.com>

> Hi,
> 
> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
> 
> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
> 
> Here are the benchmark numbers without the patch:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
> 
> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
> 
> 
> And here are the numbers with the patch applied:
> 
> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
> 
> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
> 
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  set maxadds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10398/files
  - new: https://git.openjdk.org/jdk/pull/10398/files/a9ec1b03..59e4818b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10398&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10398&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10398.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10398/head:pull/10398

PR: https://git.openjdk.org/jdk/pull/10398

From pminborg at openjdk.org  Wed Nov 30 07:46:07 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 07:46:07 GMT
Subject: Integrated: 8297515: serialVersionUID fields are not annotated with
 @Serial
In-Reply-To: <MqqET7v-K_FuquXBNxVsLgqZwsufulAQEOI0e6u8W7U=.7411e7f5-eb70-41da-9599-1c6fbc10141c@github.com>
References: <MqqET7v-K_FuquXBNxVsLgqZwsufulAQEOI0e6u8W7U=.7411e7f5-eb70-41da-9599-1c6fbc10141c@github.com>
Message-ID: <GzYrnK48-I-pqTuVTfk9DTAxAOSsVknr_R9_EFH8U-o=.93b0e535-e592-49fb-9fcd-0868a6b6906e@github.com>

On Thu, 24 Nov 2022 08:19:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Serial` annotations to certain fields participating in serialisation.

This pull request has now been integrated.

Changeset: f05bfb15
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f05bfb157837f5854efe1ce96070c615de21d1a9
Stats:     27 lines in 7 files changed: 27 ins; 0 del; 0 mod

8297515: serialVersionUID fields are not annotated with @Serial

Reviewed-by: rriggs, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/11347

From djelinski at openjdk.org  Wed Nov 30 07:50:13 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 30 Nov 2022 07:50:13 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation [v4]
In-Reply-To: <0pXx3wYDSwt27ueLb9BN3lsnPoCJHZc2HJQns4z7YJI=.71858b34-e421-4bf3-8992-e74bb4ae6c7c@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <0pXx3wYDSwt27ueLb9BN3lsnPoCJHZc2HJQns4z7YJI=.71858b34-e421-4bf3-8992-e74bb4ae6c7c@github.com>
Message-ID: <_TUofu2fuJKrPmUfetQA2E-jmE95GaWoVaCzeET-O1g=.b7788425-5af3-436b-8094-117a431c9bbf@github.com>

On Wed, 30 Nov 2022 07:38:14 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this performance improvement for Secp256R1 implementation in OpenJDK.  With this update, there is an about 20% performance improvement for Secp256R1 key generation and signature.
>> 
>> Basically, 256 bits EC curves could use 9 integer limbs for the computation.  The current implementation use 10 limbs instead.  By reducing the number of limbs, the implementation could benefit from less integer computation (add/sub/multiply/square/inverse/mod/pow, etc), and thus improve the performance.
>> 
>> Here are the benchmark numbers without the patch:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> Signatures.sign               64  thrpt   15  1.414 ? 0.022  ops/ms
>> Signatures.sign              512  thrpt   15  1.418 ? 0.004  ops/ms
>> Signatures.sign             2048  thrpt   15  1.419 ? 0.005  ops/ms
>> Signatures.sign            16384  thrpt   15  1.395 ? 0.003  ops/ms
>> 
>> KeyGenerators.keyPairGen          thrpt   15  1.475 ? 0.043  ops/ms
>> 
>> 
>> And here are the numbers with the patch applied:
>> 
>> Benchmark         (messageLength)   Mode  Cnt  Score   Error   Units
>> ECSignature.sign               64  thrpt   15  1.719 ? 0.010  ops/ms
>> ECSignature.sign              512  thrpt   15  1.704 ? 0.012  ops/ms
>> ECSignature.sign             2048  thrpt   15  1.699 ? 0.018  ops/ms
>> ECSignature.sign            16384  thrpt   15  1.681 ? 0.006  ops/ms
>> 
>> KeyGenerators.keyPairGen           thrpt   15  1.881 ? 0.008  ops/ms
>> 
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set maxadds

Please add a test that verifies that the worst case calculation still produces correct results. That is:
- build a number where the limb values are as high as possible (2^(numLimbs*bitsPerLimb)-1, or something close)
- sum that number with itself until numAdds = maxAdds
- square the result
- compare the result with the same calculations on BigInteger

-------------

PR: https://git.openjdk.org/jdk/pull/10398

From jwaters at openjdk.org  Wed Nov 30 07:55:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Nov 2022 07:55:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
 <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
 <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>
 <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com>
Message-ID: <X08uwA9tf91BTq70u3o3koABY-5ibEiJjUGuXECqoJ8=.496742e5-9430-4ff1-9944-9922e4070035@github.com>

On Wed, 23 Nov 2022 04:58:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? I've read through 8250269 briefly and unlike the issues that come with C++ attributes, alignas looks relatively straightforward to switch to, without much effect on existing code. Seems like a bit of a waste to leave the JBS entry sitting on the shelf to me
>> 
>>> The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.
>> 
>> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)
>
>> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? [...]
> 
> A PR to address JDK-8252584 would be welcomed by me. Just do the process for
> Style Guide changes (see the Style Guide or previous PRs for such). I don't
> expect it would be very controversial. I think the only reason it hasn't
> already happened is because nobody has gotten around to it, or felt the need
> for it.
> 
> JDK-8250269 touches a bit more code (mostly in stubGenerator_x86_64 and
> macroAssembler_x86_32), but also seems like it should be straightforward.
> 
>> > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.
>> 
>> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)
> 
> You are right that the Windows-conditionalized uses are in non-HotSpot code.
> I missed that context when skimming through the changes.  Since Visual Studio
> is always C++ (even though the shared files are written as C), using alignas
> with appropriate conditionalization in those files should be fine.

Resolved, will address re-implementing ATTRIBUTE_ALIGNED with alignas in another Pull Request

-------------

PR: https://git.openjdk.org/jdk/pull/11081

From pminborg at openjdk.org  Wed Nov 30 07:55:25 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 07:55:25 GMT
Subject: RFR: 8297519: Improve expressions and modernise code [v2]
In-Reply-To: <Jit7wap-FD6NRUX35yqcJFvCTWKvG9PABGuIJN6QrS0=.82604267-d11d-4b41-9432-0a8778b7a7ee@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
 <0mZVaka7WvA8eV4b8yZYZ33Abv_zstEr9tN47dWpcbQ=.e6cfa946-a98b-48bb-a880-959d5e98bb41@github.com>
 <Jit7wap-FD6NRUX35yqcJFvCTWKvG9PABGuIJN6QrS0=.82604267-d11d-4b41-9432-0a8778b7a7ee@github.com>
Message-ID: <mgEDn6wQicQmD_N7cqYj-QS23npbNIN9G0k5x6Exk_k=.09585aa3-3509-4658-89cd-54dbf1bb5d14@github.com>

On Tue, 29 Nov 2022 16:12:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update from the first round of comments
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 375:
> 
>> 373:                     tagLen = type.defTagLen;
>> 374:                 }
>> 375:                 default -> throw new AssertionError("Unsupported type " + type);
> 
> `default` is unnecessary.

This would enable total removal of the switch statement.

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From pminborg at openjdk.org  Wed Nov 30 08:03:50 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 08:03:50 GMT
Subject: RFR: 8297519: Improve expressions and modernise code [v3]
In-Reply-To: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
Message-ID: <8olH5zY_Jfy2eeLuYqdlwip5npksVBfUNNoOZIN9J5E=.4edd912e-ac59-4798-9c05-a81005605a57@github.com>

> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
> 
> 
> This branch has been tested and passed tier1-4 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove switch and use pattern matching

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11348/files
  - new: https://git.openjdk.org/jdk/pull/11348/files/8bfb4ad8..7be9041d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11348&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11348&range=01-02

  Stats: 18 lines in 2 files changed: 0 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11348/head:pull/11348

PR: https://git.openjdk.org/jdk/pull/11348

From pminborg at openjdk.org  Wed Nov 30 08:21:17 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 08:21:17 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
Message-ID: <v-oAy5bhGxQDLLmJuOc9ShFUTA34sXnWHjPon_D__MI=.dc7b35c8-7799-42e1-aac8-a7df7199fa0c@github.com>

On Tue, 29 Nov 2022 17:44:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It is a bit unusual to use a local class as a holder class (the typical manner is to a have a private static final nested class) but we didn't have local classes until recently - so maybe that's OK. I assume there's only one version of that class and it is static?

As I understand it, there are zero instances of the class as it is only declared. The class only contains a class variable. In a recent Java version, classes that are "effectively static" (my wording) (i.e. does not refernece the outer class) does not hold a reference to the outer class. So, it is not static but in this case, I believe it does not matter because 1) it is never instantiated and 2) if it was indeed instantiated, it is "effectively static".

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 08:28:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 08:28:23 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
Message-ID: <AEVKizNKVaINTSLAF14772wp4ubyf4Kx3N_SzXvYvGg=.a8212316-6464-4bcd-a6c9-0ab344909752@github.com>

On Tue, 29 Nov 2022 17:08:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>> 
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
>> 
>> * Replacing duplicate code segments 
>> * Making certain fields final 
>> * Using enhanced switch 
>> * Using records 
>> * Fixing typos 
>> * Marking fields participating in serialisation with `@Serial` 
>> * Modernizing toString() implementations 
>> * Using pattern matching 
>> * Using diamond operators
>
> src/jdk.sctp/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java line 32:
> 
>> 30: public record SctpStdSocketOption<T>(String name,
>> 31:                                      Class<T> type,
>> 32:                                      int constValue)
> 
> This changes the implementation of `toString`, `equals` and `hashCode`. Have you verified that it is OK to do so?

I agree this might be an issue. Especially `toString` in this case might be problematic. I think the best course of action here would be to revert the changes proposed.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 08:34:20 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 08:34:20 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
Message-ID: <i5VucbG7HYDTdoBADPh3cDttGEuv_qdoeKE1Tjo-F1A=.ab895de3-58a4-4372-be3f-c8b7e1b6e7ae@github.com>

On Tue, 29 Nov 2022 17:17:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>> 
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
>> 
>> * Replacing duplicate code segments 
>> * Making certain fields final 
>> * Using enhanced switch 
>> * Using records 
>> * Fixing typos 
>> * Marking fields participating in serialisation with `@Serial` 
>> * Modernizing toString() implementations 
>> * Using pattern matching 
>> * Using diamond operators
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 33:
> 
>> 31: import java.io.FileDescriptor;
>> 32: import java.io.IOException;
>> 33: import java.util.*;
> 
> It would be better to avoid wildcards in regular imports.

Agreed. I would have to find the settings in my IDE to prevent this automatic "feature".

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 09:03:26 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 09:03:26 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <9yk8TUxvPGC2gkULFMyTaprQ5WGiaJnaGBsJ4z1WQwM=.d9b3ba36-0219-40a0-80df-b3ff6c0fdb94@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>
 <9yk8TUxvPGC2gkULFMyTaprQ5WGiaJnaGBsJ4z1WQwM=.d9b3ba36-0219-40a0-80df-b3ff6c0fdb94@github.com>
Message-ID: <TsbLnHkN-WVVtV6hsz56N0ecG8KLeznZrVYU-9vTORY=.047a4d50-ee4a-4367-8539-2c0ff1aa6c6f@github.com>

On Tue, 29 Nov 2022 20:25:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.sctp/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 44:
>> 
>>> 42:  * Unimplemented.
>>> 43:  */
>>> 44: public class SctpChannelImpl extends SctpChannel {
>> 
>> Going a bit beyond just updating syntax; but that's a different PR...
>> There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception.  There would less duplication for unsupported platforms.
>
>> There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception. There would less duplication for unsupported platforms.
> 
> I think this is accident of history. As I recall, the "unsupported implementation" was Windows only in JDK 6 but it has since been copied. It could be cleaned up.

Created https://bugs.openjdk.org/browse/JDK-8297822?filter=-2 and will move changes for this to a separate PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 09:22:00 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 09:22:00 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v2]
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <1M2pNVpv9PXpMylD_DupWO71l5SjoYvRYO0v4MhllWA=.af9cafbd-9e8e-4783-ace0-7ff6b8fe730b@github.com>

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert dedup and align switch cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11418/files
  - new: https://git.openjdk.org/jdk/pull/11418/files/297be2af..e8040261

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=00-01

  Stats: 329 lines in 18 files changed: 48 ins; 64 del; 217 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From alanb at openjdk.org  Wed Nov 30 09:36:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 09:36:23 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v2]
In-Reply-To: <1M2pNVpv9PXpMylD_DupWO71l5SjoYvRYO0v4MhllWA=.af9cafbd-9e8e-4783-ace0-7ff6b8fe730b@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <1M2pNVpv9PXpMylD_DupWO71l5SjoYvRYO0v4MhllWA=.af9cafbd-9e8e-4783-ace0-7ff6b8fe730b@github.com>
Message-ID: <gYCl3kYKQEjgP8n1ai1ItWgBCXqu0dEU52-eL-0_H64=.6f289330-f88d-495a-937b-8aa860766b6c@github.com>

On Wed, 30 Nov 2022 09:22:00 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>> 
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
>> 
>> * Replacing duplicate code segments 
>> * Making certain fields final 
>> * Using enhanced switch 
>> * Using records 
>> * Fixing typos 
>> * Marking fields participating in serialisation with `@Serial` 
>> * Modernizing toString() implementations 
>> * Using pattern matching 
>> * Using diamond operators
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dedup and align switch cases

src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java line 37:

> 35:  * @since 1.7
> 36:  */
> 37: public final class SctpStandardSocketOptions {

com.sun.nio.sctp.SctpStandardSocketOptions is a JDK-specific API so technically changing it to final is an API change, although with no consequence as there is no accessible constructor.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 09:52:51 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 09:52:51 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v3]
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <nyRxSnxxdNRlssRiGW3K31_E5tAuf3wNA01HF0wZnhQ=.f8b6d9f3-f596-4ef5-b1e0-84be87fff9fd@github.com>

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert formatting and add javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11418/files
  - new: https://git.openjdk.org/jdk/pull/11418/files/e8040261..62058e4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=01-02

  Stats: 49 lines in 10 files changed: 2 ins; 0 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From naoto at openjdk.org  Wed Nov 30 17:03:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Nov 2022 17:03:57 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments
Message-ID: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>

This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

-------------

Commit messages:
 - Minor fixup
 - GetPropertyAction.privilegedGetProperty
 - Changed to use SharedSecrets
 - Password.readPassword() fix
 - Always returns Console, even without TTY attached
 - Comments refresh, clean-up
 - Removed charset from factory, added new jdk.console property
 - Revived the provider i/f
 - Replacing SPI with proxy delegate
 - javadoc
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ae5b1f76...96a46843

Changes: https://git.openjdk.org/jdk/pull/11421/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295803
  Stats: 387 lines in 10 files changed: 373 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From jlaskey at openjdk.org  Wed Nov 30 17:17:09 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 30 Nov 2022 17:17:09 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <SUWtCtsUcioHCAW1JuIZI1zrvQmv5yFmsbsOSEo5B3k=.59acf778-f4f3-4c15-9dde-5cd486c88eae@github.com>

On Tue, 29 Nov 2022 19:38:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

Looks good otherwise. Add tests.

src/java.base/share/classes/java/io/Console.java line 617:

> 615: 
> 616:             public Charset charset() {
> 617:                 return cons.charset();

What happens when cons is null?

-------------

PR: https://git.openjdk.org/jdk/pull/11421

From pminborg at openjdk.org  Wed Nov 30 17:34:50 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 17:34:50 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <O_4QtLVtXPaRnaLB55n2OJvIrC7nVVtoomPKgGN8lpY=.e65580e4-a7ed-47b1-9e61-590646d0187d@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

I've converted this PR to a draft because we want to wait for the PR_20 branch being merged [JEP 434](https://openjdk.org/jeps/434)

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From weijun at openjdk.org  Wed Nov 30 18:38:41 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 30 Nov 2022 18:38:41 GMT
Subject: RFR: 8297519: Improve expressions and modernise code [v3]
In-Reply-To: <8olH5zY_Jfy2eeLuYqdlwip5npksVBfUNNoOZIN9J5E=.4edd912e-ac59-4798-9c05-a81005605a57@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
 <8olH5zY_Jfy2eeLuYqdlwip5npksVBfUNNoOZIN9J5E=.4edd912e-ac59-4798-9c05-a81005605a57@github.com>
Message-ID: <CZk-jTduPsEHodWPVh3udph-vd-jMAdF7sPDr0ZIWOI=.d9553d25-219a-4ede-903b-333f055145d1@github.com>

On Wed, 30 Nov 2022 08:03:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
>> 
>> 
>> This branch has been tested and passed tier1-4 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove switch and use pattern matching

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From rriggs at openjdk.org  Wed Nov 30 18:47:48 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Nov 2022 18:47:48 GMT
Subject: RFR: 8297519: Improve expressions and modernise code [v3]
In-Reply-To: <8olH5zY_Jfy2eeLuYqdlwip5npksVBfUNNoOZIN9J5E=.4edd912e-ac59-4798-9c05-a81005605a57@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
 <8olH5zY_Jfy2eeLuYqdlwip5npksVBfUNNoOZIN9J5E=.4edd912e-ac59-4798-9c05-a81005605a57@github.com>
Message-ID: <PFOAaRblXSVapEeqbNe7Ie296NyzPVIbVzZ2KALBj5Y=.b1ae4044-ca6d-4682-a327-e2b85333f23b@github.com>

On Wed, 30 Nov 2022 08:03:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
>> 
>> 
>> This branch has been tested and passed tier1-4 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove switch and use pattern matching

A suggestion on the bug title, include "PKCS" or something to identity what code is being modernized.

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From naoto at openjdk.org  Wed Nov 30 18:49:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Nov 2022 18:49:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments
In-Reply-To: <SUWtCtsUcioHCAW1JuIZI1zrvQmv5yFmsbsOSEo5B3k=.59acf778-f4f3-4c15-9dde-5cd486c88eae@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <SUWtCtsUcioHCAW1JuIZI1zrvQmv5yFmsbsOSEo5B3k=.59acf778-f4f3-4c15-9dde-5cd486c88eae@github.com>
Message-ID: <7WZIOj2VKO3XArhieDZXxG_YQgQCHtjyNRuRtAbfxHs=.490ebf81-101f-4a91-8b87-f1c82f07e5f1@github.com>

On Wed, 30 Nov 2022 17:07:35 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> src/java.base/share/classes/java/io/Console.java line 617:
> 
>> 615: 
>> 616:             public Charset charset() {
>> 617:                 return cons.charset();
> 
> What happens when cons is null?

Turned out that `JavaIOAccess.charset()` is not used anywhere. Will remove this method. Will also add a test.

-------------

PR: https://git.openjdk.org/jdk/pull/11421

From weijun at openjdk.org  Wed Nov 30 19:37:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 30 Nov 2022 19:37:11 GMT
Subject: RFR: 8297519: Improve expressions and modernise code in PKCS [v3]
In-Reply-To: <8olH5zY_Jfy2eeLuYqdlwip5npksVBfUNNoOZIN9J5E=.4edd912e-ac59-4798-9c05-a81005605a57@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
 <8olH5zY_Jfy2eeLuYqdlwip5npksVBfUNNoOZIN9J5E=.4edd912e-ac59-4798-9c05-a81005605a57@github.com>
Message-ID: <mTyWbLTKSiPK-DuYq4YR7-Xn1Xq3NNlzXMbYYzEbg0s=.35910e9e-3ede-4dad-8bf1-57762884d932@github.com>

On Wed, 30 Nov 2022 08:03:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
>> 
>> 
>> This branch has been tested and passed tier1-4 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove switch and use pattern matching

Thanks. I'll sponsor it after some testing.

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From xuelei at openjdk.org  Wed Nov 30 19:46:20 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 30 Nov 2022 19:46:20 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation [v4]
In-Reply-To: <_TUofu2fuJKrPmUfetQA2E-jmE95GaWoVaCzeET-O1g=.b7788425-5af3-436b-8094-117a431c9bbf@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <0pXx3wYDSwt27ueLb9BN3lsnPoCJHZc2HJQns4z7YJI=.71858b34-e421-4bf3-8992-e74bb4ae6c7c@github.com>
 <_TUofu2fuJKrPmUfetQA2E-jmE95GaWoVaCzeET-O1g=.b7788425-5af3-436b-8094-117a431c9bbf@github.com>
Message-ID: <yu2gHhbx9MF0KL9wefAB15gxiIYUXEKG_6uxGYpDb3c=.b83c8ff6-16f9-4b69-9c42-f8e658373a89@github.com>

On Wed, 30 Nov 2022 07:46:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please add a test that verifies that the worst case calculation still produces correct results. That is:
> 
> * build a number where the limb values are as high as possible (2^(numLimbs*bitsPerLimb)-1, or something close)
> * sum that number with itself until numAdds = maxAdds
> * square the result
> * compare the result with the same calculations on BigInteger

It makes senses to me.  I would like to have an improvement in FieldGen.java instead, so that no illegal params could be set.  Let's see if I could make it before integration of this patch.

-------------

PR: https://git.openjdk.org/jdk/pull/10398

From valeriep at openjdk.org  Wed Nov 30 20:05:03 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 30 Nov 2022 20:05:03 GMT
Subject: RFR: 8297505: Declare fields in some sun.security.pkcs11 classes
 as final
In-Reply-To: <IKwYlwSCdO1z4rj16DSI5H-sWPvv37CLVu3tYdPgAII=.a982c8e6-cffb-4b91-9385-ac2a9fd24181@github.com>
References: <IKwYlwSCdO1z4rj16DSI5H-sWPvv37CLVu3tYdPgAII=.a982c8e6-cffb-4b91-9385-ac2a9fd24181@github.com>
Message-ID: <tZ81a4q8zUhzELgKbdsv74nmPSuX27WUZYJXkS7bMoA=.372b80fa-40bd-403f-a5db-accaf5f662eb@github.com>

On Thu, 24 Nov 2022 08:13:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring some fields as `final` to potentially unlock performance optimisations and improve thread visibility (e.g. for GC threads). The PR also fixes a "synchronising on a non-final field" anti-pattern.

I will take a look.

-------------

PR: https://git.openjdk.org/jdk/pull/11346

From weijun at openjdk.org  Wed Nov 30 20:10:52 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 30 Nov 2022 20:10:52 GMT
Subject: RFR: 8296384: [TESTBUG]
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently
 timeout
In-Reply-To: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
References: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
Message-ID: <6nBirPOYk4ItECXetgIza29FWlTc6VV920sOuMhblXo=.aa8da6e7-32e0-49c6-a15d-8af6d4255344@github.com>

On Mon, 7 Nov 2022 09:04:45 GMT, yansendao <duke at openjdk.org> wrote:

> 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

Change looks good. Thanks for the fix!

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11014

From pminborg at openjdk.org  Wed Nov 30 20:23:58 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 20:23:58 GMT
Subject: Integrated: 8297519: Improve expressions and modernise code in PKCS
In-Reply-To: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
References: <LNPzLoEGfG6tPpAEaSuZL-KKqbK5VNgNkYOwiooU5Eg=.2c67dd8b-dfbd-4606-bc16-cbd3f9c42534@github.com>
Message-ID: <7k2v-0qf1Nt9IOO-NEumZSw2X4aOTxKJLLpjsOPLY3s=.f69d2583-bf32-4355-8eef-2b6d0729ccea@github.com>

On Thu, 24 Nov 2022 08:24:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> During the work of another PR (https://github.com/openjdk/jdk/pull/11260), several improvement areas were identified. These are now adressed in this separate PR proposing the use of more modern Java constructs as well as simplifying a large number of logical expressions that were previously non-normative. 
> 
> 
> This branch has been tested and passed tier1-4 tests.

This pull request has now been integrated.

Changeset: e9d501e4
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9d501e442f78bec8bda38bd4f2e019005597a91
Stats:     1155 lines in 31 files changed: 161 ins; 377 del; 617 mod

8297519: Improve expressions and modernise code in PKCS

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/11348

From wetmore at openjdk.org  Wed Nov 30 20:38:20 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Nov 2022 20:38:20 GMT
Subject: RFR: 8296384: [TESTBUG]
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently
 timeout
In-Reply-To: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
References: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
Message-ID: <ahdDANdvIBUMcQ9cX9M9RKlljKzKo86WL_EMQeiAh10=.4086e36d-4028-479a-ba32-d376232c3829@github.com>

On Mon, 7 Nov 2022 09:04:45 GMT, yansendao <duke at openjdk.org> wrote:

> 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

Copyrights in both files need to be updated to include ", 2022".

Approval granted contingent on these changes.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11014

From naoto at openjdk.org  Wed Nov 30 20:44:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Nov 2022 20:44:30 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Adds a test
 - Removed JavaIOAccess.charset() which is no longer needed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/96a46843..3d2b01f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=00-01

  Stats: 70 lines in 4 files changed: 64 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From valeriep at openjdk.org  Wed Nov 30 23:53:30 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 30 Nov 2022 23:53:30 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ngsBon7c7baE3RewRW0ANd_QPDGbtdcZ2O3AARbWf2k=.91ac3d35-11b6-4206-bc0a-fa97c92a9523@github.com>
Message-ID: <1gLQDfzzyusZ1xj0vZaeBTMSxH_hmrT3eNO1YqQUQZY=.7a2bfbe9-8f93-4430-99f4-77031a9723ec@github.com>

On Wed, 16 Nov 2022 16:55:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment cleanup & finesse ByteBuffer implGCMCrypt better
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 580:
> 
>> 578:      * an upper limit on the number of blocks encrypted in the intrinsic.
>> 579:      *
>> 580:      * For decrypting in-place byte[], calling methods must ct must set to null
> 
> end of sentence mangled

"must ct must set to null" => "must set ct to null"?

-------------

PR: https://git.openjdk.org/jdk/pull/11121

From valeriep at openjdk.org  Wed Nov 30 23:53:31 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 30 Nov 2022 23:53:31 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <ou7e_ZdGVZUQXF_fZIUX-ssabz-9ggfd0dVPRchNUdo=.e36b0b9f-abed-4c1e-abc2-1c8eec14981f@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ou7e_ZdGVZUQXF_fZIUX-ssabz-9ggfd0dVPRchNUdo=.e36b0b9f-abed-4c1e-abc2-1c8eec14981f@github.com>
Message-ID: <j_3xQkMRfSvDwJfbF22cvkt9YuyNBjJH3Hl8cFCnSpU=.0a31e745-0a9f-4ac0-a1dd-7a245afca687@github.com>

On Mon, 21 Nov 2022 18:20:09 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment cleanup & finesse ByteBuffer implGCMCrypt better

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 583:

> 581:      * to avoid combined intrinsic, call GHASH directly before GCTR to avoid
> 582:      * a bad tag exception. This check is not performed here because it would
> 583:      * impose a check every operation which is less efficient.

Missing "for" after "check"?

-------------

PR: https://git.openjdk.org/jdk/pull/11121

From mstjohns at comcast.net  Tue Nov 29 03:15:14 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 29 Nov 2022 03:15:14 -0000
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
Message-ID: <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net>

Hi -

I need to repeat again.? Please avoid using www.ietf.org as the URL base 
for referencing RFCs.? The appropriate location is www.rfc-editor.org 
and is going to be more stable in the long run than any reference to an 
RFC that runs through the IETF's website.? These two websites have 
different purposes, and the structure of the IETF website has changed at 
least once recently and may change again relatively (~5 years) soon.

The most general and correct form for referencing RFCs is 
"https://www.rfc-editor.org/info/rfc<number>"? That will get you to the 
front page with pointers to all of the current semi-canonical versions 
of the spec (e.g. text, pdf-a, html, and xml).

Mike



On 11/28/2022 6:27 PM, Phil Race wrote:
> On Wed, 23 Nov 2022 18:57:03 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.
>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Remove updates from unexported files
> src/java.desktop/share/classes/java/awt/package-info.java line 58:
>
>> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
>> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
>> 58:  *                  The Java AWT Native Interface (JAWT)</a>
> Why only 1 of these 3 ?
>
> src/java.desktop/share/classes/java/awt/package-info.java line 62:
>
>> 60:  *
>> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
>> 62:  * @since 1.0
> I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
> But I also wonder why only the native_interface spec was added and not the other two ?
>
> src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:
>
>> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
>> 225:      * @see #TAG_COMPRESSION
>> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>
> Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11073