On Tue, 11 Jul 2023 18:09:26 GMT, Craig Andrews wrote:
> When loading the default JVM trust store, if the JVM trust store contains an
> invalid certificate, the exception contains insufficient information to
> determine which certificate is invalid, making it very difficult to fix the
> proble
On Thu, 21 Sep 2023 00:31:37 GMT, Mark Powers wrote:
> Without updating `Secmod/cert9.db` and `Secmod/key4.db`, both
> `Secmod/JksSetPrivateKey` and `Secmod/GetPrivateKey` will fail. The old
> values must have been incorrect. This was not noticed because `cert8.db` and
> `key3.db` were used if
On Fri, 22 Sep 2023 17:36:11 GMT, Weijun Wang wrote:
>> And leave `Utils.runAndCheckException` out of the fix? I'm fine either way.
>
> I'm OK either way too.
+1.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1334884534
On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote:
>> Hi All,
>> I would like to submit AES-GCM optimization for x86_64 architectures using
>> AVX2 instructions. This optimization interleaves AES and GHASH operations.
>>
>> Below are the performance numbers on my desktop system with -XX:Use
On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote:
>> Hi All,
>> I would like to submit AES-GCM optimization for x86_64 architectures using
>> AVX2 instructions. This optimization interleaves AES and GHASH operations.
>>
>> Below are the performance numbers on my desktop system with -XX:Use
On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote:
>> Hi All,
>> I would like to submit AES-GCM optimization for x86_64 architectures using
>> AVX2 instructions. This optimization interleaves AES and GHASH operations.
>>
>> Below are the performance numbers on my desktop system with -XX:Use
I'd fix it in one commit. https://bugs.openjdk.org/browse/JDK-8316771 filed.
Thanks,
Max
> On Sep 22, 2023, at 10:35 AM, Osipov, Michael (IN IT IN)
> wrote:
>
> Nothing at hand, at the moment. I was first waiting for you to confirm the
> issue. I think two distinct PRs are necessary here with
On Wed, 20 Sep 2023 21:56:50 GMT, Valerie Peng wrote:
> This PR reverts part of the changes under JDK-8312306 which zero-out the
> deserialized key bytes after an internal copy has been made. If considering
> the deserialized key bytes as input arguments, such cleaning action may be
> too aggr
On Wed, 20 Sep 2023 21:56:50 GMT, Valerie Peng wrote:
> This PR reverts part of the changes under JDK-8312306 which zero-out the
> deserialized key bytes after an internal copy has been made. If considering
> the deserialized key bytes as input arguments, such cleaning action may be
> too aggr
On Fri, 22 Sep 2023 15:56:08 GMT, Mark Powers wrote:
>> I was just thinking the tests are quite different. Now I re-read it and
>> maybe we can change the old code to call `generateCRLs` as well. The
>> existing `encoded_x` are very simple and only invalid SEQUENCES, which is
>> not at the lev
On Thu, 7 Sep 2023 18:12:28 GMT, Ben Perez wrote:
> Replaced "jks" with "pkcs12" in both the spec and fallback for
> `KeyStore.getDefaultType()`
This pull request has now been integrated.
Changeset: 53516aed
Author:Ben Perez
Committer: Sean Mullan
URL:
https://git.openjdk.org/jdk/
On Fri, 22 Sep 2023 13:02:57 GMT, Weijun Wang wrote:
>> Why not just updating UnexpectedNPE test with `Utils.runAndCheckException`
>> calls?
>
> I was just thinking the tests are quite different. Now I re-read it and maybe
> we can change the old code to call `generateCRLs` as well. The existin
On Mon, 31 Jul 2023 17:02:15 GMT, Brian Burkhalter wrote:
>> Limit native memory allocation and move write loop from the native layer
>> into Java. This change should make the OOME reported in the issue much less
>> likely.
>
> Brian Burkhalter has updated the pull request incrementally with on
On Thu, 21 Sep 2023 19:43:29 GMT, Ben Perez wrote:
>> Replaced "jks" with "pkcs12" in both the spec and fallback for
>> `KeyStore.getDefaultType()`
>
> Ben Perez has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Changed @run arguments to com
On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added sta
On Thu, 21 Sep 2023 19:15:52 GMT, Valerie Peng wrote:
>> I can do that. My primary motivation for using the existing test was that
>> `UnexpectedNPE.java` is the perfect name for my test.
>
> Why not just updating UnexpectedNPE test with `Utils.runAndCheckException`
> calls?
I was just thinkin
16 matches
Mail list logo