On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer wrote:
> The test is failing currently and the JBS issue could not be resolved since
> about a month, so let's exclude the test for now.
@rhalade could you please bless this exclusion now since it pops up in tests of
all our codelines every da
On Thu, 13 Jun 2024 09:25:11 GMT, Christoph Langer wrote:
> Let's exclude these CAInterop tests until the problem is fixed.
@rhalade could you please bless this exclusion quickly since it pops up in
tests of all our codelines every day...
-
PR Comment: https://git.openjdk.org/jdk/
Exclude CAInterop.java#microsoftecc2017 because it generates lots of noice in
CI.
-
Commit messages:
- JDK-8334365
Changes: https://git.openjdk.org/jdk/pull/19741/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19741&range=00
Issue: https://bugs.openjdk.org/browse/JDK-83
On Mon, 17 Jun 2024 08:01:39 GMT, Christoph Langer wrote:
> Exclude CAInterop.java#microsoftecc2017 because it generates lots of noice in
> CI.
@rhalade Please also have a look at this one. Thank you!
-
PR Comment: https://git.openjdk.org/jdk/pull/19741#issuecomment-2172587640
On Fri, 14 Jun 2024 00:58:30 GMT, SendaoYan wrote:
> The infra tests are not part of any of our CI tiers, so generally there is
> more time to investigate and figure out what the issue is in tests like this
> before putting it on the Problem List. Often the certificate tests fail
> because of
Since HttpsURLConnectionTest attempts to reach external servers, it can fail if
run on hosts without outbound traffic allowed. Therefore, it should not be
executed in CI pipelines but rather manually on a host with no firewall rules
preventing egress traffic.
-
Commit messages:
-
While doing SSL/TLS connection, start the Client with protocol TLSv1.2 and
Server with protocol TLSv1.3. During handshake process, the exception shows as
"javax.net.ssl.SSLHandshakeException: The client supported protocol versions
[TLSv1.2] are not accepted by server preferences [TLS13]", where
On Mon, 17 Jun 2024 09:16:45 GMT, Fernando Guallini
wrote:
> Since HttpsURLConnectionTest attempts to reach external servers, it can fail
> if run on hosts without outbound traffic allowed. Therefore, it should not be
> executed in CI pipelines but rather manually on a host with no firewall ru
On Fri, 14 Jun 2024 22:48:59 GMT, Anthony Scarpino
wrote:
>> On the contrary, you are in control of this error. The client OS resets the
>> connection whenever the client closes the socket without reading all
>> available data from the buffers. When the reset is delivered to the server,
>> an
> This fix recovers XDH performance but removes some of the P256 gains
> (~-8-14%). Still faster, but not as much.
>
> The fix is to undo 'int' return type on mult()/square(), which allowed to
> return partially reduced result (e.g. this avoids extra reductions when
> mult() result is fed into
On Fri, 14 Jun 2024 23:39:54 GMT, Sandhya Viswanathan
wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve non-intrinsic p256 performance
>
> src/hotspot/share/opto/runtime.cpp line 1417:
>
>> 1415: /
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 16:28:16 GMT, Daniel Jeliński wrote:
>> Maybe the comment could use some rewording, but I tried to not write whole
>> bug report in a code comment.
>>
>> When this was first prototyped as non-threaded, the SocketException occurred
>> because multiple NSTs were sent after th
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 18:12:16 GMT, Vladimir Kozlov wrote:
> What causes regression in P256 "(~-8-14%)"? From what I see, you re-arranged
> code to not execute some code ("reducePositive()") when it is not needed. How
> this affects P256?
Actually, the other way around; reducePositive is now an
On Mon, 17 Jun 2024 09:58:24 GMT, Arno Zeller wrote:
> > The infra tests are not part of any of our CI tiers, so generally there is
> > more time to investigate and figure out what the issue is in tests like
> > this before putting it on the Problem List. Often the certificate tests
> > fail b
On Mon, 17 Jun 2024 18:51:33 GMT, Volodymyr Paprotski wrote:
>> What causes regression in P256 "(~-8-14%)"?
>> From what I see, you re-arranged code to not execute some code
>> ("reducePositive()") when it is not needed. How this affects P256?
>
>> What causes regression in P256 "(~-8-14%)"? Fro
On Mon, 17 Jun 2024 18:51:33 GMT, Volodymyr Paprotski wrote:
> Actually, the other way around; reducePositive is now an unconditionally
> executed for both pure java and the intrinsic paths.
Looking on `MontgomeryIntegerPolynomialP256.java` the code in `multImpl() +
reducePositive()` is simil
On Mon, 17 Jun 2024 19:22:01 GMT, Vladimir Kozlov wrote:
> Looking on `MontgomeryIntegerPolynomialP256.java` the code in `multImpl() +
> reducePositive()` is similar to original `mult()` except new additional code
> at the end of `multImpl()`.
Yep, I split the original java mult() into multIm
On Mon, 17 Jun 2024 07:47:19 GMT, Christoph Langer wrote:
> @rhalade could you please bless this exclusion now since it pops up in tests
> of all our codelines every day...
Drawing parallel with other reviews for this test and the pending discussion,
we should hold on this PR for now. I will r
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 21:21:01 GMT, Vladimir Kozlov wrote:
> Let me know that I got it right:
>
> * The reduction operation was optional and P256 benefitted by not executing
> it.
> * Previous `mult()` **Java** code always retuned 0 because it executes
> reduction so callers do not need to do it
On Mon, 17 Jun 2024 21:52:22 GMT, Volodymyr Paprotski wrote:
> numAdds is now again pretty much a 'private' concept to the IntegerPolynomial
> class, so figure it was fine before, it should be fine now?
I did not mean it for this changes but as general improvement of code in other
RFE. But it
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Mon, 17 Jun 2024 23:29:18 GMT, Vladimir Kozlov wrote:
> Talking about future improvements. Is it possible to optimize reduction code
> by converting it to intrinsic too? Or code generated by C2 is good enough?
I had some experiments to try where I was using virtual methods to add
optimizati
On Mon, 17 Jun 2024 16:38:55 GMT, Volodymyr Paprotski wrote:
>> This fix recovers XDH performance but removes some of the P256 gains
>> (~-8-14%). Still faster, but not as much.
>>
>> The fix is to undo 'int' return type on mult()/square(), which allowed to
>> return partially reduced result (
On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino
wrote:
> Hi
>
> This change is to improve TLS 1.3 session resumption by allowing a TLS server
> to send more than one resumption ticket per connection and clients to store
> more. Resumption is a quick way to use an existing TLS session to e
27 matches
Mail list logo
