On Mon, 24 Oct 2022 09:02:58 GMT, Tobias Hartmann 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
On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes 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
On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters 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
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters 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
> 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
On Mon, 14 Nov 2022 13:08:56 GMT, Kim Barrett 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:
>
>>
On Mon, 14 Nov 2022 21:44:14 GMT, Weijun Wang wrote:
>> test/jdk/sun/security/pkcs/pkcs9/PKCS9AttrTypeTests.java line 176:
>>
>>> 174: // Encoding is supported
>>> 175: DerOutputStream dos = new DerOutputStream();
>>> 176: p9Attr.encode(dos);
>>
On Mon, 14 Nov 2022 22:19:32 GMT, Weijun Wang 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
On Tue, 15 Nov 2022 00:35:31 GMT, Weijun Wang 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
>
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
On Mon, 14 Nov 2022 17:58:36 GMT, Volodymyr Paprotski 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
On Tue, 15 Nov 2022 00:25:46 GMT, Sandhya Viswanathan
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`
On Tue, 15 Nov 2022 00:10:35 GMT, Vladimir Ivanov 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
On Mon, 14 Nov 2022 17:58:36 GMT, Volodymyr Paprotski 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
> 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
> 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
On Thu, 10 Nov 2022 02:43:21 GMT, Weijun Wang 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
On Mon, 14 Nov 2022 21:47:38 GMT, Valerie Peng 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:
On Mon, 14 Nov 2022 17:58:36 GMT, Volodymyr Paprotski 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
On Thu, 10 Nov 2022 02:43:21 GMT, Weijun Wang 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
On Mon, 14 Nov 2022 16:47:22 GMT, Weijun Wang 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
On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang wrote:
> Make two fields inside `CertificateValidity` final.
This pull request has now been integrated.
Changeset: a7c2338a
Author:Weijun Wang
URL:
https://git.openjdk.org/jdk/commit/a7c2338a6d71bdbbceee9ad7481badc76456fadf
Stats:
On Fri, 11 Nov 2022 13:57:39 GMT, pandaapo 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
On Mon, 14 Nov 2022 17:48:25 GMT, Volodymyr Paprotski 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
On Fri, 11 Nov 2022 17:56:55 GMT, Volodymyr Paprotski 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
> 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
On Fri, 11 Nov 2022 20:46:57 GMT, Volodymyr Paprotski 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
>>
On Mon, 17 Oct 2022 17:45:13 GMT, Mark Powers wrote:
> https://bugs.openjdk.org/browse/JDK-8293681
This pull request has now been integrated.
Changeset: e269dc03
Author:Mark Powers
Committer: Weijun Wang
URL:
On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang wrote:
> Make two fields inside `CertificateValidity` final.
Marked as reviewed by mullan (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/11126
On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang 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
On Mon, 14 Nov 2022 16:47:22 GMT, Weijun Wang 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
On Mon, 14 Nov 2022 16:47:22 GMT, Weijun Wang 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
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
On Mon, 14 Nov 2022 16:47:22 GMT, Weijun Wang 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
> 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
On Sun, 13 Nov 2022 21:32:48 GMT, Weijun Wang wrote:
> Make two fields inside `CertificateValidity` final.
The changes look good to me.
-
PR: https://git.openjdk.org/jdk/pull/11126
> 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
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
ScoreError Units
On Wed, 9 Nov 2022 22:32:19 GMT, Weijun Wang 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
On Mon, 14 Nov 2022 01:42:40 GMT, Julian Waters 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 \
>>>
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters 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
On Mon, 14 Nov 2022 08:01:27 GMT, David Holmes 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)
On Mon, 14 Nov 2022 08:08:40 GMT, David Holmes 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
On Mon, 14 Nov 2022 08:28:04 GMT, Thomas Stuefe 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,
>
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
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters 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
On Mon, 14 Nov 2022 01:39:17 GMT, Julian Waters 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,
>>>
On Mon, 14 Nov 2022 01:17:38 GMT, Julian Waters 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
48 matches
Mail list logo
