From anders.rundgren.net at gmail.com Mon Feb 1 07:32:20 2021 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 1 Feb 2021 08:32:20 +0100 Subject: Keytool does not agree with RFC 8410 In-Reply-To: References: Message-ID: On 2021-01-31 20:00, Wei-Jun Wang wrote: > https://bugs.openjdk.java.net/browse/JDK-8260693 filed. Thanx! In the bug report you also write: We'll also need a way to generate this kind of certificate (or certreq). There is no signature algorithm on XDH and we need to use EdDSA instead. See https://tools.ietf.org/html/rfc8410#section-10.2. AFAIK there is no standard for CSRs for encryption keys. You need to use a signature key that sort of vouches for the enclosed public key. This key may use any valid signature algorithm. As a side note, my own applications use a key container attestation key for *all* CSRs which is a more useful method than self-signed CSRs. Regards, Anders > > Thanks, > Max > >> On Jan 31, 2021, at 2:12 AM, Anders Rundgren wrote: >> >> Since the JDK bug report tool does not include "keytool" I posted this here. >> >> Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of unknown size" for a certificate containing the following public key: >> >> 148: SEQUENCE { >> 150: SEQUENCE { >> 152: OBJECT IDENTIFIER X25519 (1.3.101.110) >> } >> 157: BIT STRING, 32 bytes >> 0000: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^....A........v' >> 0010: 0e a1 ba 82 19 2e c3 90 21 89 05 5a f6 d9 e6 50 '........!..Z...P' >> } >> >> which seems to be aligned with: https://tools.ietf.org/html/rfc8410#section-10.2 >> >> You can verify this issue by importing the certificate in the RFC. >> >> Anders > From github.com+4146708+a74nh at openjdk.java.net Mon Feb 1 09:34:47 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Mon, 1 Feb 2021 09:34:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 14:58:27 GMT, Vladimir Kempik wrote: >> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. > >> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. > > I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed. You need add macos arm64 to hsdis. Having it working is fairly essential for debugging. Inside src/utils/hsdis, After cloning binutils make; make demo; ./build/macosx-arm64/hsdis-demo Results in: Hello, world! ...And now for something completely different: Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform hsdis output options: I fixed it by changing the makefile to force the build flags: ARCH=aarch64 CFLAGS/aarch64 += -m64 Resulting in: Hello, world! ...And now for something completely different: Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual Decoding for CPU 'aarch64' main: 0x10012719c sub sp, sp, #0x60 0x1001271a0 stp x29, x30, [sp, #80] ...etc Putting the library in the right place then made disassembly in java work for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ewhelan at openjdk.java.net Mon Feb 1 10:42:58 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 1 Feb 2021 10:42:58 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output Message-ID: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Hi everyone, Please review my fix for JDK-8211227 This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. Thanks, Evan ------------- Commit messages: - 8211227: Inconsistent TLS protocol version in debug output Changes: https://git.openjdk.java.net/jdk/pull/2331/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2331&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211227 Stats: 103 lines in 6 files changed: 92 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2331/head:pull/2331 PR: https://git.openjdk.java.net/jdk/pull/2331 From vkempik at openjdk.java.net Mon Feb 1 11:22:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 1 Feb 2021 11:22:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward wrote: > You need add macos arm64 to hsdis. Having it working is fairly essential for debugging. > > Inside src/utils/hsdis, After cloning binutils > > ``` > make; make demo; ./build/macosx-arm64/hsdis-demo > ``` > > Results in: > > ``` > Hello, world! > ...And now for something completely different: > > Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual > hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform > hsdis output options: > ``` > > I fixed it by changing the makefile to force the build flags: > > ``` > ARCH=aarch64 > CFLAGS/aarch64 += -m64 > ``` > > Resulting in: > > ``` > Hello, world! > ...And now for something completely different: > > Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual > Decoding for CPU 'aarch64' > main: > 0x10012719c sub sp, sp, #0x60 > 0x1001271a0 stp x29, x30, [sp, #80] > ...etc > ``` > > Putting the library in the right place then made disassembly in java work for me. Hello, hsdis is a separate out-of-tree project and is not part of this jep. support for looking for proper hsdis dylib library was added as part of this jep. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Mon Feb 1 11:44:52 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 1 Feb 2021 11:44:52 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v6] In-Reply-To: References: Message-ID: On Sun, 31 Jan 2021 18:45:19 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > 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 15 additional commits since the last revision: > > - move test > - Merge branch 'master' into 8257858 > - a test > > only in patch2: > unchanged: > - end values should be vectors > - phil comment > - same behavior as before -- empty realm map > - error check, new JavaStringToNSString > - do not find class and method in loop > - no more header file > > reverted: > - better macro, no more JNI_COCOA_ENTER > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/fdd718db...ef337f12 Basically looks good, but the Obj-C test file needs proper handling. make/test/JtregNativeJdk.gmk line 84: > 82: -framework Cocoa -framework JavaNativeFoundation > 83: BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJniInvocationTest := -ljli > 84: BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libTestDynamicStore := -ObjC Instead of "tricking" the build system of compiling an Obj-C file by masquerading it as a C file and passing compiler options, you should expose the test file for what it is, and add support in the build system to handle this. I can help you with that part. ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1845 From github.com+4146708+a74nh at openjdk.java.net Mon Feb 1 12:37:45 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Mon, 1 Feb 2021 12:37:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> Message-ID: <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> On Mon, 1 Feb 2021 11:19:34 GMT, Vladimir Kempik wrote: > Hello, hsdis is a separate out-of-tree project and is not part of this jep. Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) >support for looking for proper hsdis dylib library was added as part of this jep. I'm a little confused. Are you planning on adding a new disassembler? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Mon Feb 1 14:09:51 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 1 Feb 2021 14:09:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward wrote: > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > support for looking for proper hsdis dylib library was added as part of this jep. > > I'm a little confused. Are you planning on adding a new disassembler? @a74nh I think Vladimir is referring to https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From davin.kevin at gmail.com Mon Feb 1 14:35:37 2021 From: davin.kevin at gmail.com (Kevin Davin) Date: Mon, 1 Feb 2021 15:35:37 +0100 Subject: fix(truststore): log about truststore not found prints every time the same value Message-ID: Hi everyone, I'm contacting you because I've opened a PR to fix a bug, but it seems to be required to have an issue associated with it. The OCA team said to me I've to ask you to open one for me. Is it ok for you ? Without it, my PR is blocked https://github.com/openjdk/jdk/pull/1690, and the bridgekeeper bot said it should be close if there is no further activity on this PR. Thank you for your help and support. Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Feb 1 15:01:19 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 1 Feb 2021 15:01:19 +0000 Subject: Keytool does not agree with RFC 8410 In-Reply-To: References: Message-ID: > On Feb 1, 2021, at 2:32 AM, Anders Rundgren wrote: > > On 2021-01-31 20:00, Wei-Jun Wang wrote: >> https://bugs.openjdk.java.net/browse/JDK-8260693 filed. > > Thanx! > In the bug report you also write: > > We'll also need a way to generate this kind of certificate (or certreq). > There is no signature algorithm on XDH and we need to use EdDSA instead. > See https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$ . > > AFAIK there is no standard for CSRs for encryption keys. You need to use a signature key that sort of vouches for the enclosed public key. This key may use any valid signature algorithm. https://tools.ietf.org/html/rfc2986#section-3 says: 1. A CertificationRequestInfo value containing a subject distinguished name, a subject public key, and optionally a set of attributes is constructed by an entity requesting certification. 2. The CertificationRequestInfo value is signed with the subject entity's private key. (See Section 4.2.) It hasn?t said the ?public key? and ?private key? above should be a pair, though. > > As a side note, my own applications use a key container attestation key for *all* CSRs which is a more useful method than self-signed CSRs. Interesting. Is there any document describing this feature? Thanks, Max > > Regards, > Anders > > >> Thanks, >> Max >>> On Jan 31, 2021, at 2:12 AM, Anders Rundgren wrote: >>> >>> Since the JDK bug report tool does not include "keytool" I posted this here. >>> >>> Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of unknown size" for a certificate containing the following public key: >>> >>> 148: SEQUENCE { >>> 150: SEQUENCE { >>> 152: OBJECT IDENTIFIER X25519 (1.3.101.110) >>> } >>> 157: BIT STRING, 32 bytes >>> 0000: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^....A........v' >>> 0010: 0e a1 ba 82 19 2e c3 90 21 89 05 5a f6 d9 e6 50 '........!..Z...P' >>> } >>> >>> which seems to be aligned with: https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$ >>> You can verify this issue by importing the certificate in the RFC. >>> >>> Anders From github.com+30433125+djelinski at openjdk.java.net Mon Feb 1 16:06:50 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Mon, 1 Feb 2021 16:06:50 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability Message-ID: Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. Baseline results before any MemoryCache changes: Benchmark (size) (timeout) Mode Cnt Score Error Units CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: Benchmark (size) (timeout) Mode Cnt Score Error Units CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: Benchmark (size) (timeout) Mode Cnt Score Error Units CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op I wasn't expecting that much of an improvement, and don't know how to explain it. The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. ------------- Commit messages: - Do not invalidate objects before GC - Always expunge on put - Stop scanning expired entries after first non-expired one - Add cache microbenchmark Changes: https://git.openjdk.java.net/jdk/pull/2255/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259886 Stats: 138 lines in 3 files changed: 85 ins; 40 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/2255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2255/head:pull/2255 PR: https://git.openjdk.java.net/jdk/pull/2255 From anders.rundgren.net at gmail.com Mon Feb 1 16:23:27 2021 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 1 Feb 2021 17:23:27 +0100 Subject: Keytool does not agree with RFC 8410 In-Reply-To: References: Message-ID: <77a9e951-8283-a85e-89cb-cf5453ee081b@gmail.com> On 2021-02-01 16:01, Wei-Jun Wang wrote: > >> On Feb 1, 2021, at 2:32 AM, Anders Rundgren wrote: >> >> On 2021-01-31 20:00, Wei-Jun Wang wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8260693 filed. >> >> Thanx! >> In the bug report you also write: >> >> We'll also need a way to generate this kind of certificate (or certreq). >> There is no signature algorithm on XDH and we need to use EdDSA instead. >> See https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$ . >> >> AFAIK there is no standard for CSRs for encryption keys. You need to use a signature key that sort of vouches for the enclosed public key. This key may use any valid signature algorithm. > > https://tools.ietf.org/html/rfc2986#section-3 says: > > 1. A CertificationRequestInfo value containing a subject > distinguished name, a subject public key, and optionally a > set of attributes is constructed by an entity requesting > certification. > > 2. The CertificationRequestInfo value is signed with the subject > entity's private key. (See Section 4.2.) > > It hasn?t said the ?public key? and ?private key? above should be a pair, though. I believe this is sort of "implicit" because otherwise there would be a need to indicate which key that was used in order to verify the signature. CMC was probably designed to cope with this restriction. https://tools.ietf.org/html/rfc5272#section-3.2 >> As a side note, my own applications use a key container attestation key for *all* CSRs which is a more useful method than self-signed CSRs. > > Interesting. Is there any document describing this feature? WebAuthn appears to use this method although they only register public keys: https://www.w3.org/TR/webauthn-2/#sctn-api My particular take on this is a bit more elaborate because the attestation is rather creating a session and shared key which permits secure multi-step key (store) management operations: https://cyberphone.github.io/doc/security/keygen2.html Thanx, Anders > > Thanks, > Max > >> >> Regards, >> Anders >> >> >>> Thanks, >>> Max >>>> On Jan 31, 2021, at 2:12 AM, Anders Rundgren wrote: >>>> >>>> Since the JDK bug report tool does not include "keytool" I posted this here. >>>> >>>> Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of unknown size" for a certificate containing the following public key: >>>> >>>> 148: SEQUENCE { >>>> 150: SEQUENCE { >>>> 152: OBJECT IDENTIFIER X25519 (1.3.101.110) >>>> } >>>> 157: BIT STRING, 32 bytes >>>> 0000: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^....A........v' >>>> 0010: 0e a1 ba 82 19 2e c3 90 21 89 05 5a f6 d9 e6 50 '........!..Z...P' >>>> } >>>> >>>> which seems to be aligned with: https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$ >>>> You can verify this issue by importing the certificate in the RFC. >>>> >>>> Anders > From weijun at openjdk.java.net Mon Feb 1 16:51:12 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 1 Feb 2021 16:51:12 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: - file attr error - objc use .m ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/ef337f12..b5f1e15d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=05-06 Stats: 6 lines in 4 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Mon Feb 1 16:51:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 1 Feb 2021 16:51:19 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v6] In-Reply-To: References: Message-ID: <5fDhxKXlxhoFuYxSEPfLxrgMeHlcpKGn2rXcaMo4AJQ=.0831bc54-b9ea-484e-8686-e8b336a0fb12@github.com> On Mon, 1 Feb 2021 11:41:02 GMT, Magnus Ihse Bursie wrote: >> 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 15 additional commits since the last revision: >> >> - move test >> - Merge branch 'master' into 8257858 >> - a test >> >> only in patch2: >> unchanged: >> - end values should be vectors >> - phil comment >> - same behavior as before -- empty realm map >> - error check, new JavaStringToNSString >> - do not find class and method in loop >> - no more header file >> >> reverted: >> - better macro, no more JNI_COCOA_ENTER >> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/81433b38...ef337f12 > > make/test/JtregNativeJdk.gmk line 84: > >> 82: -framework Cocoa -framework JavaNativeFoundation >> 83: BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJniInvocationTest := -ljli >> 84: BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libTestDynamicStore := -ObjC > > Instead of "tricking" the build system of compiling an Obj-C file by masquerading it as a C file and passing compiler options, you should expose the test file for what it is, and add support in the build system to handle this. I can help you with that part. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From xuelei at openjdk.java.net Mon Feb 1 17:20:46 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 1 Feb 2021 17:20:46 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output In-Reply-To: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: <0wuQlrZs2fubz_OtruAmt_Vhec5WKAG3l4bHgrbqHEM=.dca0aa65-3326-442d-ac5f-725b759cb7eb@github.com> On Mon, 1 Feb 2021 10:37:35 GMT, Evan Whelan wrote: > Hi everyone, > > Please review my fix for JDK-8211227 > > This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. > > Thanks, > Evan Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From weijun.wang at oracle.com Mon Feb 1 17:28:19 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 1 Feb 2021 17:28:19 +0000 Subject: Keytool does not agree with RFC 8410 In-Reply-To: <77a9e951-8283-a85e-89cb-cf5453ee081b@gmail.com> References: <77a9e951-8283-a85e-89cb-cf5453ee081b@gmail.com> Message-ID: <1A8FEE47-DF2C-4A8F-8B4C-B8DA0F3505F8@oracle.com> Thanks. I also noticed ?openssl x509? has a -force_pubkey for this case. We?ll think about what is the best we can do. ?Max > On Feb 1, 2021, at 11:23 AM, Anders Rundgren wrote: > > On 2021-02-01 16:01, Wei-Jun Wang wrote: >>> On Feb 1, 2021, at 2:32 AM, Anders Rundgren wrote: >>> >>> On 2021-01-31 20:00, Wei-Jun Wang wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8260693 filed. >>> >>> Thanx! >>> In the bug report you also write: >>> >>> We'll also need a way to generate this kind of certificate (or certreq). >>> There is no signature algorithm on XDH and we need to use EdDSA instead. >>> See https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$ . >>> >>> AFAIK there is no standard for CSRs for encryption keys. You need to use a signature key that sort of vouches for the enclosed public key. This key may use any valid signature algorithm. >> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc2986*section-3__;Iw!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1pH23wpwA$ says: >> 1. A CertificationRequestInfo value containing a subject >> distinguished name, a subject public key, and optionally a >> set of attributes is constructed by an entity requesting >> certification. >> 2. The CertificationRequestInfo value is signed with the subject >> entity's private key. (See Section 4.2.) >> It hasn?t said the ?public key? and ?private key? above should be a pair, though. > > I believe this is sort of "implicit" because otherwise there would be a need to indicate which key that was used in order to verify the signature. > > CMC was probably designed to cope with this restriction. > https://urldefense.com/v3/__https://tools.ietf.org/html/rfc5272*section-3.2__;Iw!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1pvrP3bEQ$ >>> As a side note, my own applications use a key container attestation key for *all* CSRs which is a more useful method than self-signed CSRs. >> Interesting. Is there any document describing this feature? > > WebAuthn appears to use this method although they only register public keys: > https://urldefense.com/v3/__https://www.w3.org/TR/webauthn-2/*sctn-api__;Iw!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1olcwu24Q$ > My particular take on this is a bit more elaborate because the attestation is rather creating a session and shared key which permits secure multi-step key (store) management operations: > https://urldefense.com/v3/__https://cyberphone.github.io/doc/security/keygen2.html__;!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1rBveLZ7A$ > Thanx, > Anders > >> Thanks, >> Max >>> >>> Regards, >>> Anders >>> >>> >>>> Thanks, >>>> Max >>>>> On Jan 31, 2021, at 2:12 AM, Anders Rundgren wrote: >>>>> >>>>> Since the JDK bug report tool does not include "keytool" I posted this here. >>>>> >>>>> Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of unknown size" for a certificate containing the following public key: >>>>> >>>>> 148: SEQUENCE { >>>>> 150: SEQUENCE { >>>>> 152: OBJECT IDENTIFIER X25519 (1.3.101.110) >>>>> } >>>>> 157: BIT STRING, 32 bytes >>>>> 0000: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^....A........v' >>>>> 0010: 0e a1 ba 82 19 2e c3 90 21 89 05 5a f6 d9 e6 50 '........!..Z...P' >>>>> } >>>>> >>>>> which seems to be aligned with: https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$ >>>>> You can verify this issue by importing the certificate in the RFC. >>>>> >>>>> Anders > From erikj at openjdk.java.net Mon Feb 1 18:21:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 1 Feb 2021 18:21:41 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 11:32:08 GMT, djelinski wrote: > Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. > > First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. > Baseline results before any MemoryCache changes: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op > CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op > CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op > CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op > there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. > > Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op > CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op > The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. > > The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op > CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op > I wasn't expecting that much of an improvement, and don't know how to explain it. > > The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. make/test/BuildMicrobenchmark.gmk line 97: > 95: SRC := $(MICROBENCHMARK_SRC), \ > 96: BIN := $(MICROBENCHMARK_CLASSES), \ > 97: JAVAC_FLAGS := $(JAVAC_FLAGS) --add-exports java.base/sun.security.util=ALL-UNNAMED, \ Why do you need to add $(JAVAC_FLAGS) here? ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From github.com+30433125+djelinski at openjdk.java.net Mon Feb 1 18:27:41 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Mon, 1 Feb 2021 18:27:41 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: <5T0hYAFXsfI5MhX_VsTdhRwrvU2LnP5y34snVSFgqAc=.1ea25657-dc89-49e1-998b-b30267d63068@github.com> On Mon, 1 Feb 2021 18:18:51 GMT, Erik Joelsson wrote: >> Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. >> >> First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. >> Baseline results before any MemoryCache changes: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op >> CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op >> CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op >> CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op >> there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. >> >> Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op >> CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op >> The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. >> >> The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op >> CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op >> I wasn't expecting that much of an improvement, and don't know how to explain it. >> >> The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. > > make/test/BuildMicrobenchmark.gmk line 97: > >> 95: SRC := $(MICROBENCHMARK_SRC), \ >> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >> 97: JAVAC_FLAGS := $(JAVAC_FLAGS) --add-exports java.base/sun.security.util=ALL-UNNAMED, \ > > Why do you need to add $(JAVAC_FLAGS) here? I'm trying to benchmark a class that is in a non-exported package `sun.security.util`. Without this line the benchmark doesn't compile. I couldn't find any other benchmarks that access non-exported classes, so I came up with my own implementation. Is there a better way to get the benchmark to compile? ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From erikj at openjdk.java.net Mon Feb 1 18:31:46 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 1 Feb 2021 18:31:46 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - file attr error > - objc use .m Build changes look good. Thanks for fixing the .m support in TestFilesCompilation.gmk! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1845 From erikj at openjdk.java.net Mon Feb 1 18:34:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 1 Feb 2021 18:34:53 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability In-Reply-To: References: <5T0hYAFXsfI5MhX_VsTdhRwrvU2LnP5y34snVSFgqAc=.1ea25657-dc89-49e1-998b-b30267d63068@github.com> Message-ID: On Mon, 1 Feb 2021 18:30:14 GMT, Erik Joelsson wrote: >> I'm trying to benchmark a class that is in a non-exported package `sun.security.util`. Without this line the benchmark doesn't compile. I couldn't find any other benchmarks that access non-exported classes, so I came up with my own implementation. >> >> Is there a better way to get the benchmark to compile? > > Adding "--add-exports java.base/sun.security.util=ALL-UNNAMED" is fine, I'm asking about "$(JAVAC_FLAGS)". Hm, maybe you just misunderstand how this makefile construct works. If you just want to add "--add-exports java.base/sun.security.util=ALL-UNNAMED", then that's all you should put in this assignment. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From erikj at openjdk.java.net Mon Feb 1 18:34:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 1 Feb 2021 18:34:53 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability In-Reply-To: <5T0hYAFXsfI5MhX_VsTdhRwrvU2LnP5y34snVSFgqAc=.1ea25657-dc89-49e1-998b-b30267d63068@github.com> References: <5T0hYAFXsfI5MhX_VsTdhRwrvU2LnP5y34snVSFgqAc=.1ea25657-dc89-49e1-998b-b30267d63068@github.com> Message-ID: On Mon, 1 Feb 2021 18:24:46 GMT, djelinski wrote: >> make/test/BuildMicrobenchmark.gmk line 97: >> >>> 95: SRC := $(MICROBENCHMARK_SRC), \ >>> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >>> 97: JAVAC_FLAGS := $(JAVAC_FLAGS) --add-exports java.base/sun.security.util=ALL-UNNAMED, \ >> >> Why do you need to add $(JAVAC_FLAGS) here? > > I'm trying to benchmark a class that is in a non-exported package `sun.security.util`. Without this line the benchmark doesn't compile. I couldn't find any other benchmarks that access non-exported classes, so I came up with my own implementation. > > Is there a better way to get the benchmark to compile? Adding "--add-exports java.base/sun.security.util=ALL-UNNAMED" is fine, I'm asking about "$(JAVAC_FLAGS)". ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From github.com+30433125+djelinski at openjdk.java.net Mon Feb 1 18:38:43 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Mon, 1 Feb 2021 18:38:43 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability In-Reply-To: References: <5T0hYAFXsfI5MhX_VsTdhRwrvU2LnP5y34snVSFgqAc=.1ea25657-dc89-49e1-998b-b30267d63068@github.com> Message-ID: On Mon, 1 Feb 2021 18:31:39 GMT, Erik Joelsson wrote: >> Adding "--add-exports java.base/sun.security.util=ALL-UNNAMED" is fine, I'm asking about "$(JAVAC_FLAGS)". > > Hm, maybe you just misunderstand how this makefile construct works. If you just want to add "--add-exports java.base/sun.security.util=ALL-UNNAMED", then that's all you should put in this assignment. yeah, I'm new to makefiles. Let me try that... ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From github.com+30433125+djelinski at openjdk.java.net Mon Feb 1 18:49:04 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Mon, 1 Feb 2021 18:49:04 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: Message-ID: > Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. > > First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. > Baseline results before any MemoryCache changes: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op > CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op > CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op > CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op > there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. > > Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op > CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op > The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. > > The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op > CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op > I wasn't expecting that much of an improvement, and don't know how to explain it. > > The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. djelinski has updated the pull request incrementally with one additional commit since the last revision: Simplify makefile ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2255/files - new: https://git.openjdk.java.net/jdk/pull/2255/files/5859a032..34949970 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2255/head:pull/2255 PR: https://git.openjdk.java.net/jdk/pull/2255 From github.com+30433125+djelinski at openjdk.java.net Mon Feb 1 18:49:04 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Mon, 1 Feb 2021 18:49:04 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <5T0hYAFXsfI5MhX_VsTdhRwrvU2LnP5y34snVSFgqAc=.1ea25657-dc89-49e1-998b-b30267d63068@github.com> Message-ID: On Mon, 1 Feb 2021 18:35:56 GMT, djelinski wrote: >> Hm, maybe you just misunderstand how this makefile construct works. If you just want to add "--add-exports java.base/sun.security.util=ALL-UNNAMED", then that's all you should put in this assignment. > > yeah, I'm new to makefiles. Let me try that... Removed. I could have sworn I tried this... but apparently I didn't. Thanks for the suggestion! ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From aph at openjdk.java.net Mon Feb 1 18:49:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 1 Feb 2021 18:49:58 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Sun, 31 Jan 2021 20:14:01 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: > > - Merge branch 'master' into jdk-macos > - Update copyright year for BsdAARCH64ThreadContext.java > - Fix inclusing of StubRoutines header > - Redo buildsys fix > - Revert harfbuzz changes, disable warnings for it > - Little adjustement of SlowSignatureHandler > - Partially bring previous commit > - Revert "Address feedback for signature generators" > > This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin > - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 84: > 82: // on stack. Natural alignment for types are still in place, > 83: // for example double/long should be 8 bytes alligned > 84: This comment is a bit confusing because it's no longer #ifdef APPLE. Better move it up to Line 41. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 352: > 350: > 351: #ifdef __APPLE__ > 352: virtual void pass_byte() Please remove ```#ifdef __APPLE__``` around this region. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: > 837: // The code unable to handle this, bailout. > 838: return -1; > 839: #endif This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From erikj at openjdk.java.net Mon Feb 1 19:24:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 1 Feb 2021 19:24:42 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 18:49:04 GMT, djelinski wrote: >> Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. >> >> First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. >> Baseline results before any MemoryCache changes: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op >> CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op >> CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op >> CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op >> there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. >> >> Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op >> CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op >> The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. >> >> The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op >> CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op >> I wasn't expecting that much of an improvement, and don't know how to explain it. >> >> The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. > > djelinski has updated the pull request incrementally with one additional commit since the last revision: > > Simplify makefile Build change looks good, but I would like to hear from @cl4es too. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2255 From rhalade at openjdk.java.net Mon Feb 1 19:43:43 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 1 Feb 2021 19:43:43 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output In-Reply-To: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: On Mon, 1 Feb 2021 10:37:35 GMT, Evan Whelan wrote: > Hi everyone, > > Please review my fix for JDK-8211227 > > This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. > > Thanks, > Evan Changes requested by rhalade (Reviewer). test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 36: > 34: /* > 35: * This test runs in another process so we can monitor the debug > 36: * results. The OutputAnalyzer must see correct debug output to return a Suggestion: * results. The OutputAnalyzer must see correct debug output to return a test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 83: > 81: // Re-enabling as test depends on these algorithms > 82: SecurityUtils.removeFromDisabledTlsAlgs("TLSv1", "TLSv1.1"); > 83: var url = new URL("https://jpg-data.us.oracle.com/"); This URL is not accessible outside. test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 50: > 48: public class LoggingFormatConsistency { > 49: public static void main(String[] args) throws Exception { > 50: if (args.length == 0){ Please add a comment to explain when the test should be run with parameter. ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From github.com+1970922+davinkevin at openjdk.java.net Mon Feb 1 22:20:50 2021 From: github.com+1970922+davinkevin at openjdk.java.net (Davin Kevin) Date: Mon, 1 Feb 2021 22:20:50 GMT Subject: RFR: 8260861: TrustStoreDescriptor log the same value Message-ID: If both jssecacerts and cacerts are not defined, the same log is printed twice, talking about the jssecacerts instead of cacerts the second time.? ------------- Commit messages: - fix(truststore): log about truststore not found print everytime the same value Changes: https://git.openjdk.java.net/jdk/pull/1690/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1690&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260861 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1690/head:pull/1690 PR: https://git.openjdk.java.net/jdk/pull/1690 From xuelei at openjdk.java.net Mon Feb 1 22:20:51 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 1 Feb 2021 22:20:51 GMT Subject: RFR: 8260861: TrustStoreDescriptor log the same value In-Reply-To: References: Message-ID: <_CT5xj5j_z21E7VM8uq9UhwnlOnj6CwLhwsfl8fjP40=.71ce58ae-f6e2-4111-bc43-61cdad52a79a@github.com> On Tue, 8 Dec 2020 09:35:26 GMT, Davin Kevin wrote: > If both jssecacerts and cacerts are not defined, the same log is printed twice, talking about the jssecacerts instead of cacerts the second time.? Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1690 From github.com+1970922+davinkevin at openjdk.java.net Mon Feb 1 22:20:51 2021 From: github.com+1970922+davinkevin at openjdk.java.net (Davin Kevin) Date: Mon, 1 Feb 2021 22:20:51 GMT Subject: RFR: 8260861: TrustStoreDescriptor log the same value In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:35:26 GMT, Davin Kevin wrote: > If both jssecacerts and cacerts are not defined, the same log is printed twice, talking about the jssecacerts instead of cacerts the second time.? OCA has been signed and my name has been added into the OCA listing page: * https://www.oracle.com/technical-resources/oracle-contributor-agreement.html What is the next step to make this contribution eligible to merge ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1690 From github.com+1970922+davinkevin at openjdk.java.net Mon Feb 1 22:20:51 2021 From: github.com+1970922+davinkevin at openjdk.java.net (Davin Kevin) Date: Mon, 1 Feb 2021 22:20:51 GMT Subject: RFR: 8260861: TrustStoreDescriptor log the same value In-Reply-To: References: Message-ID: On Thu, 31 Dec 2020 09:43:18 GMT, Davin Kevin wrote: >> If both jssecacerts and cacerts are not defined, the same log is printed twice, talking about the jssecacerts instead of cacerts the second time.? > > OCA has been signed and my name has been added into the OCA listing page: > * https://www.oracle.com/technical-resources/oracle-contributor-agreement.html > > What is the next step to make this contribution eligible to merge ? I've made all the tasks required, so I don't know why the process is blocked ??. ------------- PR: https://git.openjdk.java.net/jdk/pull/1690 From dcubed at openjdk.java.net Mon Feb 1 22:45:50 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Feb 2021 22:45:50 GMT Subject: RFR: 8260864: ProblemList two security/krb5 tests on Linux Message-ID: A trivial fix to ProblemList these two tests on Linux: sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java sun/security/krb5/auto/ReplayCacheTestProc.java We're rolling machines over to Linux 8.3 and these two tests are starting to fail in the CI in Tier2 (so far). So we need to reduce the noise. ------------- Commit messages: - 8260864: ProblemList two security/krb5 tests on Linux Changes: https://git.openjdk.java.net/jdk/pull/2342/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2342&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260864 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2342.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2342/head:pull/2342 PR: https://git.openjdk.java.net/jdk/pull/2342 From redestad at openjdk.java.net Mon Feb 1 22:47:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 1 Feb 2021 22:47:39 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 19:22:22 GMT, Erik Joelsson wrote: >> djelinski has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify makefile > > Build change looks good, but I would like to hear from @cl4es too. Adding an `--add-exports` to `JAVAC_FLAGS` is a bit iffy, but should be OK. Yes, all benchmarks will now be compiled with that package exported and visible, but that should have no unintentional effect on other compilations. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From dholmes at openjdk.java.net Mon Feb 1 22:53:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 1 Feb 2021 22:53:41 GMT Subject: RFR: 8260864: ProblemList two security/krb5 tests on Linux In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:41:16 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList these two tests on Linux: > > sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java > sun/security/krb5/auto/ReplayCacheTestProc.java > > We're rolling machines over to Linux 8.3 and these two tests are starting > to fail in the CI in Tier2 (so far). So we need to reduce the noise. LGTM! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2342 From dcubed at openjdk.java.net Mon Feb 1 22:53:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Feb 2021 22:53:42 GMT Subject: RFR: 8260864: ProblemList two security/krb5 tests on Linux In-Reply-To: References: Message-ID: <9Ypg_dQh1xAUqHcUEhWWEHuZZnurAWFYppVY260SidM=.edd23532-0730-43ac-9032-2f071282dd46@github.com> On Mon, 1 Feb 2021 22:50:37 GMT, David Holmes wrote: >> A trivial fix to ProblemList these two tests on Linux: >> >> sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java >> sun/security/krb5/auto/ReplayCacheTestProc.java >> >> We're rolling machines over to Linux 8.3 and these two tests are starting >> to fail in the CI in Tier2 (so far). So we need to reduce the noise. > > LGTM! @wangweij - just a heads up that I'm ProblemListing the two tests you said to "ignore". @dholmes-ora - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2342 From dcubed at openjdk.java.net Mon Feb 1 22:57:47 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Feb 2021 22:57:47 GMT Subject: Integrated: 8260864: ProblemList two security/krb5 tests on Linux In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:41:16 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList these two tests on Linux: > > sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java > sun/security/krb5/auto/ReplayCacheTestProc.java > > We're rolling machines over to Linux 8.3 and these two tests are starting > to fail in the CI in Tier2 (so far). So we need to reduce the noise. This pull request has now been integrated. Changeset: a6d95058 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/a6d95058 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8260864: ProblemList two security/krb5 tests on Linux Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2342 From weijun at openjdk.java.net Mon Feb 1 23:02:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 1 Feb 2021 23:02:42 GMT Subject: RFR: 8260864: ProblemList two security/krb5 tests on Linux In-Reply-To: <9Ypg_dQh1xAUqHcUEhWWEHuZZnurAWFYppVY260SidM=.edd23532-0730-43ac-9032-2f071282dd46@github.com> References: <9Ypg_dQh1xAUqHcUEhWWEHuZZnurAWFYppVY260SidM=.edd23532-0730-43ac-9032-2f071282dd46@github.com> Message-ID: On Mon, 1 Feb 2021 22:51:06 GMT, Daniel D. Daugherty wrote: > @wangweij - just a heads up that I'm ProblemListing the two tests you said to "ignore". No problem! Good idea!! Well done!!! ------------- PR: https://git.openjdk.java.net/jdk/pull/2342 From hchao at openjdk.java.net Mon Feb 1 23:11:52 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Mon, 1 Feb 2021 23:11:52 GMT Subject: RFR: 8257497: Key identifier compliance issue Message-ID: This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. ------------- Commit messages: - 8257497: Key identifier compliance issue Changes: https://git.openjdk.java.net/jdk/pull/2343/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257497 Stats: 32 lines in 2 files changed: 22 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2343/head:pull/2343 PR: https://git.openjdk.java.net/jdk/pull/2343 From cverghese at openjdk.java.net Tue Feb 2 01:19:01 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Tue, 2 Feb 2021 01:19:01 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v7] In-Reply-To: References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Fri, 29 Jan 2021 00:50:04 GMT, Xue-Lei Andrew Fan wrote: >> Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Please make sure all tier1 and tier2 tests passed on all supported platforms. Except the failed I commented in the update, javax/net/ssl/SSLSession/TestEnabledProtocols.java is also failed with a similar stack on Windows. Maybe, the pull request command "/test tier1" and "/test tier2" could help speed up the testing. Hi, Thank you for the feedback. I have verified that tier1 and tier2 tests pass on Windows, MacOS and Linux. ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From cverghese at openjdk.java.net Tue Feb 2 01:19:01 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Tue, 2 Feb 2021 01:19:01 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v9] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Fix test failures ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2057/files - new: https://git.openjdk.java.net/jdk/pull/2057/files/573406dd..43cb77d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From xuelei at openjdk.java.net Tue Feb 2 01:37:40 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 2 Feb 2021 01:37:40 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:45:17 GMT, Claes Redestad wrote: >> Build change looks good, but I would like to hear from @cl4es too. > > Adding an `--add-exports` to `JAVAC_FLAGS` is a bit iffy, but should be OK. Yes, all benchmarks will now be compiled with that package exported and visible, but that should have no unintentional effect on other compilations. The impact could beyond the JSSE implementation, andI will have a look as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From xuelei at openjdk.java.net Tue Feb 2 02:40:44 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 2 Feb 2021 02:40:44 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: Message-ID: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> On Mon, 1 Feb 2021 18:49:04 GMT, djelinski wrote: >> Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. >> >> First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. >> Baseline results before any MemoryCache changes: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op >> CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op >> CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op >> CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op >> there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. >> >> Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op >> CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op >> The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. >> >> The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op >> CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op >> I wasn't expecting that much of an improvement, and don't know how to explain it. >> >> The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. > > djelinski has updated the pull request incrementally with one additional commit since the last revision: > > Simplify makefile If I get the patch right, the benchmark performance improvement is a trade-off between CPU and memory, by keeping expired entries while putting a new entry in the cache. I'm not very sure of the performance impact on memory and GC collections. Would you mind add two more types of benchmark: get the entries and remove the entries, for cases that there are 1/10, 1/4, 1/3 and 1/2 expired entries in the cache? And increase the size to some big scales, like 2M and 20M. It looks like a spec update as it may change the behavior of a few JDK components (TLS session cache, OCSP stapling response cache, cert store cache, certificate factory, etc), because of "expired entries are no longer guaranteed to be removed before live ones". I'm not very sure of the impact. I may suggest to file a CSR and have more eyes to check the compatibility impact before moving forward. ------------- Changes requested by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2255 From ihse at openjdk.java.net Tue Feb 2 08:09:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 2 Feb 2021 08:09:50 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - file attr error > - objc use .m Looks good now! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1845 From vkempik at openjdk.java.net Tue Feb 2 11:45:04 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 2 Feb 2021 11:45:04 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Mon, 1 Feb 2021 14:06:32 GMT, Magnus Ihse Bursie wrote: >>> Hello, hsdis is a separate out-of-tree project and is not part of this jep. >> >> Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) >> >>>support for looking for proper hsdis dylib library was added as part of this jep. >> >> I'm a little confused. Are you planning on adding a new disassembler? > >> > Hello, hsdis is a separate out-of-tree project and is not part of this jep. >> >> Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > >> >> > support for looking for proper hsdis dylib library was added as part of this jep. >> >> I'm a little confused. Are you planning on adding a new disassembler? > > @a74nh I think Vladimir is referring to https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > > > > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of this jep. > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( Sorry I was under impression hsdis is not part of openjdk tree. Alan, could you please share with us the version of binutils you were using in your test ? Regards, Vladimir ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Feb 2 11:59:08 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 2 Feb 2021 11:59:08 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: support macos_aarch64 in hsdis ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/b421e0b4..3c705ae5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=07-08 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Feb 2 11:59:09 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 2 Feb 2021 11:59:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Tue, 2 Feb 2021 11:14:12 GMT, Vladimir Kempik wrote: > > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > > > > > > > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > > > > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of this jep. > > > > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > > > > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( > > Sorry I was under impression hsdis is not part of openjdk tree. > > Alan, could you please share with us the version of binutils you were using in your test ? > > Regards, Vladimir I have updated PR with patch for hsdis, one thing to notice, LP64 is not defined for arm64 in Makefile ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+4146708+a74nh at openjdk.java.net Tue Feb 2 12:17:47 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Tue, 2 Feb 2021 12:17:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Tue, 2 Feb 2021 11:56:12 GMT, Vladimir Kempik wrote: > > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > > > > > > > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > > > > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of this jep. > > > > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > > > > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( > > Sorry I was under impression hsdis is not part of openjdk tree. > > Alan, could you please share with us the version of binutils you were using in your test ? > I was just using the latest HEAD: git clone git://sourceware.org/git/binutils-gdb.git src/utils/hsdis/build/binutils A slightly safer approach would be to grab the latest release: https://ftp.gnu.org/gnu/binutils/binutils-2.36.tar.gz Once hsdis-demo was working for me, for only other oddity I had was that the library needed renaming when copying/linking into the build dir: jdk/lib/server/libhsdis-aarch64.dylib ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+30433125+djelinski at openjdk.java.net Tue Feb 2 12:21:42 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Tue, 2 Feb 2021 12:21:42 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> Message-ID: On Tue, 2 Feb 2021 02:37:39 GMT, Xue-Lei Andrew Fan wrote: > the benchmark performance improvement is a trade-off between CPU and memory, by keeping expired entries while putting a new entry in the cache Not exactly. The memory use is capped by cache size. The patch is a trade off between the cache's hit/miss ratio and CPU; we will get faster cache access at the cost of more frequent cache misses. All calls to `put()` remove expired items from the front of the queue, and never perform a full scan. `get()` calls shuffle the queue, moving the accessed item to the back. Compare this to original code where `put()` only removed expired items when the cache overflowed, and scanned the entire cache. Let me give some examples. **Example 1**: insertions at a fast pace leading to cache overflows and no expirations. Here the new implementation improves performance. Consider a cache with size=4, timeout=10, and the following sequence of events: T=1, put(1); T=2, put(2); T=3, put(3); T=4, put(4); Cache contents after these calls (same in old and new scenario). Queue order: least recently accessed items on the left, most recently accessed on the right. _K_ denotes cache key, _exp_ denotes entry expiration time and is equal to insertion time _T_ plus timeout: |K=1, exp=11|K=2, exp=12|K=3, exp=13|K=4, exp=14| If we now add another item to the queue, it will overflow. Here's where the implementations behave differently, but the outcome is identical: old one scans the entire list for expired entries; new one improves performance by ending the search for expired entries after encountering the first non-expired entry (which is the first entry in the above example). The end result is the same in both cases - oldest (least recently accessed) item is dropped: T=5, put(5) |K=2, exp=12|K=3, exp=13|K=4, exp=14|K=5, exp=15| **Example 2**: insertions at a moderate pace, with interleaved reads. Here the new implementation improves performance, but at a possible cost of wasting cache capacity on expired entries. Consider a cache with size=4, timeout=7, and the following sequence of events: T=1, put(1); T=3, put(3); T=5, put(5); T=7, put(7); T=7, get(1); Cache contents after these calls: |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=1, exp=8| `get(1)` operation moved item with K=1 to the back of the queue. If we wait for item with K=1 to expire and then add another item to the queue, it will overflow. Here's where the implementations behave differently, and the outcome is different: old one scans the entire list for expired entries, finds entry with K=1 and drops it; new one gives up after first non-expired entry (which is the first entry), and drops the first entry. So, when we perform: T=9, put(9); Old implementation will get: |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16| New implementation will get: |K=5, exp=12|K=7, exp=14|K=1, exp=8(expired)|K=9, exp=16| Note that: - an attempt to retrieve expired item (i.e. `get(1)`) will immediately remove that item from cache, making room for other items - retrieving a non-expired item will move it to the back of the queue, behind all expired items **Example 3**: insertions at a slow pace, where most items expire before queue overflows. Here the new implementation improves memory consumption. Consider a cache with size=4, timeout=1, and the following sequence of events: T=1, put(1); T=3, put(3); T=5, put(5); T=7, put(7); Every cache item is expired at then point when a new one is added. Old implementation only removes expired entries when cache overflows, so all entries will still be there: |K=1, exp=2(expired)|K=3, exp=4(expired)|K=5, exp=6(expired)|K=7, exp=8| New implementation removes expired entries on every put, so after the last put only one entry is in the cache: |K=7, exp=8| After another put the old implementation will encounter a cache overflow and remove all expired items. Let me know if that helped. > add two more types of benchmark: get the entries and remove the entries Both these operations are constant-time, both before and after my changes. Do you expect to see some oddities here, or do we just want a benchmark that could be used to compare other implementations? > increase the size to some big scales, like 2M and 20M Can do. Do you think it makes sense to also benchmark the scenario where GC kicks in and collects soft references? > it may change the behavior of a few JDK components Of all uses of Cache, only `SSLSessionContextImpl` (TLS session cache), `StatusResponseManager` (OCSP stapling) and `LDAPCertStoreImpl` (I'm not familiar with that one) set expiration timeout; when the timeout is not set, the behavior is exactly the same as before. `StatusResponseManager` is constantly querying the same keys, and is liberally sized, so I don't expect much of an impact. TLS session cache changes may result in fewer session resumptions and more full handshakes; I expect the cache performance improvement to more than offset the CPU cycles lost on full handshakes. How do I file a CSR? Also, what do you think about the changes done in `Do not invalidate objects before GC` 5859a03 commit? They offer a minor performance improvement, but if clearing the values before GC is an important security feature of this cache, I'm prepared to drop that commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From xuelei at openjdk.java.net Tue Feb 2 16:35:44 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 2 Feb 2021 16:35:44 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v7] In-Reply-To: References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Tue, 2 Feb 2021 01:15:25 GMT, Clive Verghese wrote: > Hi, > > Thank you for the feedback. > > I have verified that tier1 and tier2 tests pass on Windows, MacOS and Linux. Thank you! I will address the closed test failures. I will post you when the update is ready. ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From mullan at openjdk.java.net Tue Feb 2 18:23:52 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 2 Feb 2021 18:23:52 GMT Subject: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:22:52 GMT, Rajan Halade wrote: > Following two roots are added to cacerts store - > > CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > Release Note is at - https://bugs.openjdk.java.net/browse/JDK-8260597 Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2272 From rhalade at openjdk.java.net Tue Feb 2 18:29:40 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 2 Feb 2021 18:29:40 GMT Subject: Integrated: 8256421: Add 2 HARICA roots to cacerts truststore In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:22:52 GMT, Rajan Halade wrote: > Following two roots are added to cacerts store - > > CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > Release Note is at - https://bugs.openjdk.java.net/browse/JDK-8260597 This pull request has now been integrated. Changeset: 69189f88 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/69189f88 Stats: 393 lines in 4 files changed: 390 ins; 0 del; 3 mod 8256421: Add 2 HARICA roots to cacerts truststore Reviewed-by: hchao, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2272 From gziemski at openjdk.java.net Tue Feb 2 18:55:48 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 2 Feb 2021 18:55:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 11:59:08 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > support macos_aarch64 in hsdis Changes requested by gziemski (Committer). src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 390: > 388: store_and_inc(_to, from_obj, NativeStack::intSpace); > 389: > 390: _num_int_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use 2 of them inside `if else` branches. We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 404: > 402: } else { > 403: store_and_inc(_to, from_obj, NativeStack::longSpace); > 404: _num_int_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 418: > 416: } else { > 417: store_and_inc(_to, (*from_addr == 0) ? (intptr_t)NULL : (intptr_t) from_addr, wordSize); > 418: _num_int_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433: > 431: store_and_inc(_to, from_obj, NativeStack::floatSpace); > 432: > 433: _num_fp_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 448: > 446: } else { > 447: store_and_inc(_to, from_obj, NativeStack::doubleSpace); > 448: _num_fp_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271: > 5269: // > 5270: void MacroAssembler::get_thread(Register dst) { > 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ? src/hotspot/os/posix/signals_posix.cpp line 1297: > 1295: kern_return_t kr; > 1296: kr = task_set_exception_ports(mach_task_self(), > 1297: EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC, Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here? src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93: > 91: CPU_MARVELL = 'V', > 92: CPU_INTEL = 'i', > 93: CPU_APPLE = 'a', The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Tue Feb 2 19:00:56 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 2 Feb 2021 19:00:56 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:52:29 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > Changes requested by gziemski (Committer). There were bunch of assembly code that I couldn't review. I also shallow reviewed the brand new files that were copies of the existing BSD x86_64 files - I hope I can get back to those when I figure out how to build/run these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Tue Feb 2 19:25:49 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 2 Feb 2021 19:25:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:23:04 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os/posix/signals_posix.cpp line 1297: > >> 1295: kern_return_t kr; >> 1296: kr = task_set_exception_ports(mach_task_self(), >> 1297: EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC, > > Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here? See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+1970922+davinkevin at openjdk.java.net Tue Feb 2 20:56:42 2021 From: github.com+1970922+davinkevin at openjdk.java.net (Davin Kevin) Date: Tue, 2 Feb 2021 20:56:42 GMT Subject: Integrated: 8260861: TrustStoreDescriptor log the same value In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:35:26 GMT, Davin Kevin wrote: > If both jssecacerts and cacerts are not defined, the same log is printed twice, talking about the jssecacerts instead of cacerts the second time.? This pull request has now been integrated. Changeset: 105d3e8f Author: Davin Kevin Committer: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/105d3e8f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8260861: TrustStoreDescriptor log the same value Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/1690 From martin.doerr at sap.com Tue Feb 2 20:28:18 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 2 Feb 2021 20:28:18 +0000 Subject: [11u] RFR: 8244683: A TSA server used by tests Message-ID: Hi, JDK-8244683 is backported to 11.0.11-oracle. I'd like to backport it for parity. It doesn't apply cleanly. TimestampCheck.java: - The parts which get removed contain minor differences (see [1]) - Resolution: Take new version. TsaHandler.java and TsaSigner.java: - New code contains usages of KnownOIDs which don't exist in 11u. - Resolution: Translate them (see [2]) TsaSigner.java: - New code uses ObjectIdentifier.of - Resolution: Change back to "new ObjectIdentifier" according to [1] - Uses HexPrinter (for debug code) which doesn't exist in 11u. - Resolution: Use HexDumpEncoder instead: System.out.println(new HexDumpEncoder().encode(bytes)); An additional testfix is needed: https://bugs.openjdk.java.net/browse/JDK-8246709 which applies cleanly except that it needs an import change (see [3]). That change is not included in the webrev. I just want to push 11u backport of 8244683 together with 8246709 (including [3]) together. Bug: https://bugs.openjdk.java.net/browse/JDK-8244683 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/56bda3e6d148 11u backport: http://cr.openjdk.java.net/~mdoerr/8244683_TSA_11u/webrev.00/ Please review. Best regards, Martin [1] diff JDK11u:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java JDK16:TimestampCheck_before_8244683.java 65a66 > * 8242151 137c138 < ObjectIdentifier policyId = new ObjectIdentifier(defaultPolicyId); --- > ObjectIdentifier policyId = ObjectIdentifier.of(defaultPolicyId); 161c162 < policyId = new ObjectIdentifier(defaultPolicyId); --- > policyId = ObjectIdentifier.of(defaultPolicyId); 233c234 < ContentInfo contentInfo = new ContentInfo(new ObjectIdentifier( --- > ContentInfo contentInfo = new ContentInfo(ObjectIdentifier.of( [2] KnownOIDs Translation: https://github.com/openjdk/jdk/commit/080b3b83ebffe5149fbc9ac48e921fb51e9c3c63#diff-e6d5bd6b166be4737084473fcf55b0f101a710263c899c19b0df2a702c89a30e [3] diff JDK16:TSA_testfix_orig.patch resolved_JDK11u:8246709_TSA.patch < import jdk.test.lib.process.OutputAnalyzer; --- > import jdk.testlibrary.OutputAnalyzer; -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Feb 2 22:05:07 2021 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Tue, 2 Feb 2021 22:05:07 +0000 Subject: fix(truststore): log about truststore not found prints every time the same value In-Reply-To: References: Message-ID: Hi Kevin, I think you are done with this PR. I created the bug for you, and you linked the bug with the PR. The PR now is integrated. Xuelei On Feb 2, 2021, at 1:24 PM, Kevin Davin wrote: ? Hi everyone, I'm contacting you because I've opened a PR to fix a bug, but it seems to be required to have an issue associated with it. The OCA team said to me I've to ask you to open one for me. Is it ok for you ? Without it, my PR is blocked https://github.com/openjdk/jdk/pull/1690, and the bridgekeeper bot said it should be close if there is no further activity on this PR. Thank you for your help and support. Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcubed at openjdk.java.net Tue Feb 2 23:13:00 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Feb 2021 23:13:00 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 11:59:08 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > support macos_aarch64 in hsdis For platform files that were copied from other ports to this port, if the file wasn't changed I presume the copyright years are left alone. If the file required changes for this port, I expect the year to be updated to 2021. How are you verifying that these copyright years are being properly managed on the new files? For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment explaining why one was landed in a particular place would help reviewers. Also see my comment about creating a new ThreadToNativeWithWXExecFromVM helper. I'm stopping my review with all the src/hotspot files done for now. make/autoconf/flags.m4 line 140: > 138: else > 139: MACOSX_VERSION_MIN=10.12.0 > 140: fi Not something that needs to be addressed here, but these changes illustrate that our collective use of macOSX/MACOSX/MacOSX names are tied to the fact that the macOS major version number was at 10 for a very long time. @magicus - Do we have an RFE to rename MACOSX or are we sticking with it and evolving our interpretation of the 'X' from '10' to */splat/asterik? make/common/NativeCompilation.gmk line 1178: > 1176: endif > 1177: # This only works if the openjdk_codesign identity is present on the system. Let > 1178: # silently fail otherwise. Might want to add a comment here: # The '-f' option will replace an existing signature if one exists. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 41: > 39: #define __ _masm-> > 40: > 41: //describe amount of space in bytes occupied by type on native stack nit - needs a space after `//` src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 83: > 81: // On macos/aarch64 native stack is packed, int/float are using only 4 bytes > 82: // on stack. Natural alignment for types are still in place, > 83: // for example double/long should be 8 bytes alligned nit typo: s/alligned/aligned/ And sentence should end with a period. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: > 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); > 322: > 323: str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset())); I don't think this switch from `JavaThread::saved_fp_address_offset()` to `JavaFrameAnchor::saved_fp_address_offset()` is correct since `rthread` is still used and is a JavaThread*. The new code will give you: `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor The old code gave you: `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread Those are not the same things. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31: > 29: #include "asm/assembler.inline.hpp" > 30: #include "oops/compressedOops.hpp" > 31: #include "runtime/vm_version.hpp" It's not clear why this include needed to be added. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810: > 808: #ifdef __APPLE__ > 809: // Less-than word types are stored one after another. > 810: // The code unable to handle this, bailout. Perhaps: // The code is unable to handle this so bailout. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 837: > 835: #ifdef __APPLE__ > 836: // Less-than word types are stored one after another. > 837: // The code unable to handle this, bailout. Perhaps: // The code is unable to handle this so bailout. src/hotspot/os/aix/os_aix.cpp line 69: > 67: #include "runtime/sharedRuntime.hpp" > 68: #include "runtime/statSampler.hpp" > 69: #include "runtime/stubRoutines.inline.hpp" It is not clear why this include to inline-include change was made. src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 37: > 35: #include "runtime/init.hpp" > 36: #include "runtime/os.hpp" > 37: #include "runtime/stubRoutines.inline.hpp" It is not clear why this include to inline-include change was made. src/hotspot/os/windows/os_windows.cpp line 65: > 63: #include "runtime/sharedRuntime.hpp" > 64: #include "runtime/statSampler.hpp" > 65: #include "runtime/stubRoutines.inline.hpp" It is not clear why this include to inline-include change was made. src/hotspot/os_cpu/bsd_aarch64/atomic_bsd_aarch64.hpp line 59: > 57: } > 58: > 59: // __attribute__((unused)) on dest is to get rid of spurious GCC warnings. Is the GCC comment appropriate? Does this file get built with GCC or just Apple compilers? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 92: > 90: # define DEFAULT_MAIN_THREAD_STACK_PAGES 2048 > 91: # define OS_X_10_9_0_KERNEL_MAJOR_VERSION 13 > 92: #endif Does this work around for Maveriks (10.9.0) need to be here? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 103: > 101: // 10.5 UNIX03 member name prefixes > 102: #define DU3_PREFIX(s, m) __ ## s.__ ## m > 103: # else Does this work around for macOS 10.5 need to be here? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195: > 193: frame os::get_sender_for_C_frame(frame* fr) { > 194: return frame(fr->link(), fr->link(), fr->sender_pc()); > 195: } Is this file going to be built by GCC or just macOS compilers? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 221: > 219: assert(sig == info->si_signo, "bad siginfo"); > 220: } > 221: */ Should this code be deleted? From here and from where it was copied from if it is also commented out there... src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363: > 361: address pc = os::Posix::ucontext_get_pc(uc); > 362: > 363: if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means Is this TODO going to be resolved by this port? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 374: > 372: > 373: last_addr = (address) -1; > 374: } else if (pc == addr && uc->context_esr == 0x8200000f) { //TODO: figure out what this value means Is this TODO going to be resolved by this port? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: > 433: // | |\ Java thread created by VM does not have glibc > 434: // | glibc guard page | - guard, attached Java thread usually has > 435: // | |/ 1 glibc guard page. Is this code going to be built by GCC (with glibc) or will only macOS compilers and libraries be used? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486: > 484: } > 485: } > 486: } This appears to be a mix for Mavericks (10.9) and 10.12 work arounds. Is this code needed by this project? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45: > 43: // Atomically copy 64 bits of data > 44: static void atomic_copy64(const volatile void *src, volatile void *dst) { > 45: *(jlong *) dst = *(const jlong *) src; Is this construct actually atomic on aarch64? src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp line 43: > 41: assert(Thread::current() == this, "caller must be current thread"); > 42: return pd_get_top_frame(fr_addr, ucontext, isInJava); > 43: } Is AsyncGetCallTrace() being supported by this port? src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp line 43: > 41: > 42: private: > 43: 'private' usually has once space in front of it. Also why the blank line after it? src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp line 46: > 44: static void current_thread_enable_wx_impl(WXMode mode) { } > 45: > 46: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/bsd_x86/os_bsd_x86.hpp line 41: > 39: > 40: private: > 41: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/bsd_x86/os_bsd_x86.hpp line 44: > 42: static void current_thread_enable_wx_impl(WXMode mode) { } > 43: > 44: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/bsd_zero/os_bsd_zero.hpp line 57: > 55: > 56: private: > 57: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/bsd_zero/os_bsd_zero.hpp line 60: > 58: static void current_thread_enable_wx_impl(WXMode mode) { } > 59: > 60: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.hpp line 43: > 41: > 42: private: > 43: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.hpp line 46: > 44: static void current_thread_enable_wx_impl(WXMode mode) { } > 45: > 46: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp line 74: > 72: > 73: private: > 74: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp line 77: > 75: static void current_thread_enable_wx_impl(WXMode mode) { } > 76: > 77: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 36: > 34: > 35: private: > 36: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 39: > 37: static void current_thread_enable_wx_impl(WXMode mode) { } > 38: > 39: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_s390/os_linux_s390.hpp line 35: > 33: > 34: private: > 35: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_s390/os_linux_s390.hpp line 38: > 36: static void current_thread_enable_wx_impl(WXMode mode) { } > 37: > 38: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_x86/os_linux_x86.hpp line 54: > 52: > 53: private: > 54: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_x86/os_linux_x86.hpp line 57: > 55: static void current_thread_enable_wx_impl(WXMode mode) { } > 56: > 57: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_zero/os_linux_zero.hpp line 94: > 92: > 93: private: > 94: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_zero/os_linux_zero.hpp line 97: > 95: static void current_thread_enable_wx_impl(WXMode mode) { } > 96: > 97: private: I think this should 'public' (with one space in front of it). src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 37: > 35: > 36: private: > 37: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 40: > 38: static void current_thread_enable_wx_impl(WXMode mode) { } > 39: > 40: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp line 47: > 45: > 46: private: > 47: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp line 50: > 48: static void current_thread_enable_wx_impl(WXMode mode) { } > 49: > 50: public: 'public' usually has one space in front of it. src/hotspot/share/gc/shared/oopStorage.cpp line 40: > 38: #include "runtime/os.hpp" > 39: #include "runtime/safepoint.hpp" > 40: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline-include is not clear. src/hotspot/share/logging/logStream.hpp line 35: > 33: class LogStream : public outputStream { > 34: // see test/hotspot/gtest/logging/test_logStream.cpp > 35: friend class LogStreamTest; It's not clear why this change is made for this port. src/hotspot/share/prims/jni.cpp line 3930: > 3928: > 3929: // Go to the execute mode, the initial state of the thread on creation. > 3930: // Use os interface as the thread is not a java one anymore. Perhaps: s/not a java one anymore./not a JavaThread anymore./ src/hotspot/share/prims/nativeEntryPoint.cpp line 45: > 43: guarantee(status == JNI_OK && !env->ExceptionOccurred(), > 44: "register jdk.internal.invoke.NativeEntryPoint natives"); > 45: JNI_END I thought that jcheck caught a missing new-line? src/hotspot/share/runtime/globals.hpp line 1855: > 1853: \ > 1854: product(intx, UnguardOnExecutionViolation, 0, \ > 1855: "Unguard page and retry on no-execute fault " \ Taking away the "(Win32 only)" and not replacing it with new text feels wrong. I can't imagine that this flag works on any additional platforms except for macos-aarch64. src/hotspot/share/runtime/os.cpp line 58: > 56: #include "runtime/osThread.hpp" > 57: #include "runtime/sharedRuntime.hpp" > 58: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline include is not clear. src/hotspot/share/runtime/objectMonitor.cpp line 52: > 50: #include "runtime/safepointMechanism.inline.hpp" > 51: #include "runtime/sharedRuntime.hpp" > 52: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline include is not clear. src/hotspot/share/runtime/stubRoutines.cpp line 34: > 32: #include "runtime/timerTrace.hpp" > 33: #include "runtime/sharedRuntime.hpp" > 34: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline include is not clear. src/hotspot/share/runtime/stubRoutines.inline.hpp line 1: > 1: /* NOW I understand the reason for switching from include to inline-include. Is there a reason that this change is part of this project and not extracted into a separate RFE. That would reduce the number of files touched by this project. src/hotspot/share/runtime/thread.cpp line 3991: > 3989: JavaThread* thread = JavaThread::current(); > 3990: ThreadToNativeFromVM ttn(thread); > 3991: Thread::WXExecFromWriteSetter wx_exec; I saw somewhere in this review a comment about why this new WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM and I understand that not every current ThreadToNativeFromVM needs the new helper. If the vast majority of the ThreadToNativeFromVM locations need WXExecFromWriteSetter, then perhaps those locations that currently have a ThreadToNativeFromVM followed by the new WXExecFromWriteSetter should use a new helper: ThreadToNativeWithWXExecFromVM so we'll see changes from: ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM where we need them and hopefully a short comment can be added at the same time to explain the need for WXExec. This will allow us to easily distinguish ThreadToNativeFromVM locations that DO NOT need WXExec from those that DO need it. src/java.base/macosx/native/libjli/java_md_macosx.m line 210: > 208: if (preferredJVM == NULL) { > 209: #if defined(__i386__) > 210: preferredJVM = "client"; #if defined(__i386__) preferredJVM = "client"; Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Wed Feb 3 09:25:52 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 3 Feb 2021 09:25:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:03:50 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271: > >> 5269: // >> 5270: void MacroAssembler::get_thread(Register dst) { >> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; > > The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ? Surely this should be saved_regs = RegSet::range(r0, r1) BSD_ONLY(+ RegSet::range(r2, r17)) + lr - dst;``` Shouldn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Wed Feb 3 09:25:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 3 Feb 2021 09:25:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:49:36 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: > >> 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); >> 322: >> 323: str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset())); > > I don't think this switch from `JavaThread::saved_fp_address_offset()` > to `JavaFrameAnchor::saved_fp_address_offset()` is correct since > `rthread` is still used and is a JavaThread*. The new code will give you: > > `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor > > The old code gave you: > > `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread > > Those are not the same things. I agree, I don't understand why this change was made. > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45: > >> 43: // Atomically copy 64 bits of data >> 44: static void atomic_copy64(const volatile void *src, volatile void *dst) { >> 45: *(jlong *) dst = *(const jlong *) src; > > Is this construct actually atomic on aarch64? Yes. > src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 37: > >> 35: >> 36: private: >> 37: > > 'private' usually has one space in front of it. > Also, why the blank line after it? It reads better with the blank line, and it's not in violation of HotSpot conventions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From valeriep at openjdk.java.net Wed Feb 3 11:30:41 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 3 Feb 2021 11:30:41 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - file attr error > - objc use .m src/java.security.jgss/share/classes/sun/security/krb5/SCDynamicStoreConfig.java line 103: > 101: ri.put("kdc", kdcs); > 102: } > 103: realms.put(nextRealm, ri); Do you need to check if ri is empty? ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From valeriep at openjdk.java.net Wed Feb 3 12:18:52 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 3 Feb 2021 12:18:52 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote: >> This fix covers both >> >> - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) >> - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - file attr error > - objc use .m Rest of the Kerberos config handling changes look fine. Thanks! ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1845 From weijun at openjdk.java.net Wed Feb 3 12:58:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 3 Feb 2021 12:58:44 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7] In-Reply-To: References: Message-ID: <_YhfqbHH3RrHA0PM8kMfw5etIb1jrORXG_OrAdLXHyo=.647dd6e9-57f2-463f-9366-0dca8c5064cf@github.com> On Wed, 3 Feb 2021 11:27:49 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: >> >> - file attr error >> - objc use .m > > src/java.security.jgss/share/classes/sun/security/krb5/SCDynamicStoreConfig.java line 103: > >> 101: ri.put("kdc", kdcs); >> 102: } >> 103: realms.put(nextRealm, ri); > > Do you need to check if ri is empty? It should make no difference to applications whether there is an empty section or not, but I can remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From fguallini at openjdk.java.net Wed Feb 3 13:35:57 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 3 Feb 2021 13:35:57 GMT Subject: RFR: 8163498: Many long-running security libs tests Message-ID: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg sun/security/provider/DSA/SupportedDSAParamGen.java sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average ------------- Commit messages: - rename tests - remove updated copyright year in new files - split long running files inot two - use fake key generator and remove not needed code Changes: https://git.openjdk.java.net/jdk/pull/2381/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2381&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8163498 Stats: 215 lines in 8 files changed: 192 ins; 11 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2381/head:pull/2381 PR: https://git.openjdk.java.net/jdk/pull/2381 From weijun at openjdk.java.net Wed Feb 3 14:43:14 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 3 Feb 2021 14:43:14 GMT Subject: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v8] In-Reply-To: References: Message-ID: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: valerie comment, remove useless test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1845/files - new: https://git.openjdk.java.net/jdk/pull/1845/files/b5f1e15d..41fed31f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1845&range=06-07 Stats: 107 lines in 2 files changed: 2 ins; 105 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845 PR: https://git.openjdk.java.net/jdk/pull/1845 From jlaskey at openjdk.java.net Wed Feb 3 15:07:49 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 3 Feb 2021 15:07:49 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 00:15:16 GMT, Mark Reinhold wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update package info to credit LMX algorithm > > src/java.base/share/classes/java/util/random/RandomGenerator.java line 110: > >> 108: /** >> 109: * Returns an instance of {@link RandomGenerator} that utilizes the >> 110: * {@code name} algorithm. > > Shouldn't this method, and related methods, mention the fact that `RandomGenerator` instances are located as services? I see no mention of of that fact anywhere, unless I missed it, but I do see the `uses` and `provides` declarations in the module declaration. A paragraph explaining how services are used here, perhaps in the package specification, would be ideal. I agree. Will add. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From weijun at openjdk.java.net Wed Feb 3 15:09:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 3 Feb 2021 15:09:42 GMT Subject: RFR: 8163498: Many long-running security libs tests In-Reply-To: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: On Wed, 3 Feb 2021 13:29:54 GMT, Fernando Guallini wrote: > The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg > sun/security/provider/DSA/SupportedDSAParamGen.java > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java > > sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average test/jdk/sun/security/rsa/SignatureTest.java line 137: > 135: return new Key[]{ > 136: kf.generatePublic(kf.getKeySpec(key, RSAPublicKeySpec.class)), > 137: kf.generatePublic(new X509EncodedKeySpec(key.getEncoded())) Here, the test ensures keys created from a `RSAPublicKeySpec` are the same no matter if the `RSAPublicKeySpec` is retrieved from `KeyFactory::getKeySpec` or manually created. If you can prove the two `RSAPublicKeySpec` objects are effectively the same (or it has already been proven in other tests) then there's no need to generate the key again. On the other hand, we can actually add more keys into the array. The 1st is `key` itself, and the 2nd is one generated from `kf.getKeySpec(key, X509EncodedKeySpec.class)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From weijun at openjdk.java.net Wed Feb 3 16:23:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 3 Feb 2021 16:23:45 GMT Subject: Integrated: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote: > This fix covers both > > - [[macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860) This pull request has now been integrated. Changeset: 4a8b5c16 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/4a8b5c16 Stats: 805 lines in 12 files changed: 369 ins; 317 del; 119 mod 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m 8257860: [macOS]: Remove JNF dependency from libosxkrb5/SCDynamicStoreConfig.m Reviewed-by: erikj, prr, ihse, valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/1845 From xuelei at openjdk.java.net Wed Feb 3 17:50:47 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 3 Feb 2021 17:50:47 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v9] In-Reply-To: References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Tue, 2 Feb 2021 01:19:01 GMT, Clive Verghese wrote: >> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed >> >> This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Fix test failures It looks good to me now. I will take care of the closed test update. Please finalize the CSR request before integration. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2057 From fguallini at openjdk.java.net Wed Feb 3 18:26:41 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 3 Feb 2021 18:26:41 GMT Subject: RFR: 8163498: Many long-running security libs tests In-Reply-To: References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: On Wed, 3 Feb 2021 15:06:37 GMT, Weijun Wang wrote: >> The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg >> sun/security/provider/DSA/SupportedDSAParamGen.java >> sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java >> com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java >> >> sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average > > test/jdk/sun/security/rsa/SignatureTest.java line 137: > >> 135: return new Key[]{ >> 136: kf.generatePublic(kf.getKeySpec(key, RSAPublicKeySpec.class)), >> 137: kf.generatePublic(new X509EncodedKeySpec(key.getEncoded())) > > Here, the test ensures keys created from a `RSAPublicKeySpec` are the same no matter if the `RSAPublicKeySpec` is retrieved from `KeyFactory::getKeySpec` or manually created. If you can prove the two `RSAPublicKeySpec` objects are effectively the same (or it has already been proven in other tests) then there's no need to generate the key again. > > On the other hand, we can actually add more keys into the array. The 1st is `key` itself, and the 2nd is one generated from `kf.getKeySpec(key, X509EncodedKeySpec.class)`. That is right, PSSKeyCompatibility already explicitly proves they both are equal and there are other tests that generates both manually and using KeyFactory. In addition, this test focuses on signature verification rather than key creation. ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From rhalade at openjdk.java.net Wed Feb 3 18:47:41 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 3 Feb 2021 18:47:41 GMT Subject: RFR: 8163498: Many long-running security libs tests In-Reply-To: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: On Wed, 3 Feb 2021 13:29:54 GMT, Fernando Guallini wrote: > The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg > sun/security/provider/DSA/SupportedDSAParamGen.java > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java > > sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From weijun at openjdk.java.net Wed Feb 3 19:52:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 3 Feb 2021 19:52:42 GMT Subject: RFR: 8163498: Many long-running security libs tests In-Reply-To: References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: On Wed, 3 Feb 2021 18:24:05 GMT, Fernando Guallini wrote: >> test/jdk/sun/security/rsa/SignatureTest.java line 137: >> >>> 135: return new Key[]{ >>> 136: kf.generatePublic(kf.getKeySpec(key, RSAPublicKeySpec.class)), >>> 137: kf.generatePublic(new X509EncodedKeySpec(key.getEncoded())) >> >> Here, the test ensures keys created from a `RSAPublicKeySpec` are the same no matter if the `RSAPublicKeySpec` is retrieved from `KeyFactory::getKeySpec` or manually created. If you can prove the two `RSAPublicKeySpec` objects are effectively the same (or it has already been proven in other tests) then there's no need to generate the key again. >> >> On the other hand, we can actually add more keys into the array. The 1st is `key` itself, and the 2nd is one generated from `kf.getKeySpec(key, X509EncodedKeySpec.class)`. > > That is right, PSSKeyCompatibility already explicitly proves they both are equal and there are other tests that generates both manually and using KeyFactory. In addition, this test focuses on signature verification rather than key creation. Not only does a key have encoded form and an algorithm, it might contain other internal info that could affect its usage (here, it's signing and verifying). That's why there are multiple keys there. A Spec type is different, it only has public data and is easy to prove equality. ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From akozlov at openjdk.java.net Wed Feb 3 20:01:15 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:01:15 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - Add comments to WX transitions + minor change of placements - Use macro conditionals instead of empty functions - Add W^X to tests - Do not require known W^X state - Revert w^x in gtests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/3c705ae5..80827176 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=08-09 Stats: 444 lines in 64 files changed: 112 ins; 278 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:01:16 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:01:16 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > For platform files that were copied from other ports to this port, if the file wasn't > changed I presume the copyright years are left alone. If the file required changes > for this port, I expect the year to be updated to 2021. How are you verifying that > these copyright years are being properly managed on the new files? > > For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment > explaining why one was landed in a particular place would help reviewers. > Also see my comment about creating a new ThreadToNativeWithWXExecFromVM > helper. > > I'm stopping my review with all the src/hotspot files done for now. Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten. The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From jlaskey at openjdk.java.net Wed Feb 3 20:03:04 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 3 Feb 2021 20:03:04 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v15] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/38369702..96f98765 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=13-14 Stats: 599 lines in 8 files changed: 311 ins; 253 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From akozlov at openjdk.java.net Wed Feb 3 20:11:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Wed, 3 Feb 2021 19:57:24 GMT, Anton Kozlov wrote: >> For platform files that were copied from other ports to this port, if the file wasn't >> changed I presume the copyright years are left alone. If the file required changes >> for this port, I expect the year to be updated to 2021. How are you verifying that >> these copyright years are being properly managed on the new files? >> >> For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment >> explaining why one was landed in a particular place would help reviewers. >> Also see my comment about creating a new ThreadToNativeWithWXExecFromVM >> helper. >> >> I'm stopping my review with all the src/hotspot files done for now. > > Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten. > > The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions. > I wonder if this is the right choice > ... > ``` > OopStorageParIterPerf::~OopStorageParIterPerf() { > ... > ``` > The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite. I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped. I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ... are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests. Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore. W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From mikael at openjdk.java.net Wed Feb 3 20:11:50 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 3 Feb 2021 20:11:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Wed, 3 Feb 2021 20:05:29 GMT, Anton Kozlov wrote: >> Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten. >> >> The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions. > >> I wonder if this is the right choice >> ... >> ``` >> OopStorageParIterPerf::~OopStorageParIterPerf() { >> ... >> ``` >> > > The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite. > > I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped. > > I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ... are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests. > > Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore. > > W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions. Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov wrote: >> Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like: >> class ThreadInVMfromNative : public ThreadStateTransition { >> ResetNoHandleMark __rnhm; >> >> We can look at it with cleaning up the thread transitions RFE or as a follow-on. If every line of ThreadInVMfromNative has to have one of these Thread::WXWriteVerifier __wx_write; people are going to miss them when adding the former. > > Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this. I've dropped this transition here and in similar places after state tracking always available. As a benefit, there are few places really using the setter and all of them are tied to VM_ENTRY macro or similar one. I expect we don't need to do W^X management near every java thread state change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:51 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> Message-ID: On Tue, 26 Jan 2021 12:01:30 GMT, Coleen Phillimore wrote: >> I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. >> * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. >> * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance. >> >> If such costs are negligible, I can do as suggested. > > I really just want the minimal number of lines of code and hooks in thread.hpp. You can still access it through the thread, just like these lines currently. Look at HandshakeState as an example. Please take a look at the recent changes. Changes in thread.hpp were reduced: https://github.com/openjdk/jdk/pull/2200/files#diff-abdc409967d04172ecc20e3747aa55a79e755584d570b57c4d58902a9813d188 thread.inline.hpp provides definitions of accessors (non-trivial): https://github.com/openjdk/jdk/pull/2200/files#diff-3a29f7f952bf2bd936f49e97cb3b86a7324851133e879c142dec724455310b50 And new threadWXSetters.hpp defines RAII context setter: https://github.com/openjdk/jdk/pull/2200/files#diff-6424782ec43941031282f079e89adaa76d341ce340a3b78b0e9657358ec16278 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Wed Feb 3 20:11:52 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 20:11:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 19:23:16 GMT, Bernhard Urban-Forster wrote: >> src/hotspot/os/posix/signals_posix.cpp line 1297: >> >>> 1295: kern_return_t kr; >>> 1296: kr = task_set_exception_ports(mach_task_self(), >>> 1297: EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC, >> >> Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here? > > See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`. Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then. We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb: `// gdb installs both standard BSD signal handlers, and mach exception` `// handlers. By replacing the existing task exception handler, we disable gdb's mach` `// exception handling, while leaving the standard BSD signal handlers functional.` Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:53 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:53 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 23:03:45 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/runtime/thread.cpp line 3991: > >> 3989: JavaThread* thread = JavaThread::current(); >> 3990: ThreadToNativeFromVM ttn(thread); >> 3991: Thread::WXExecFromWriteSetter wx_exec; > > I saw somewhere in this review a comment about why this new > WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM > and I understand that not every current ThreadToNativeFromVM needs > the new helper. If the vast majority of the ThreadToNativeFromVM > locations need WXExecFromWriteSetter, then perhaps those locations > that currently have a ThreadToNativeFromVM followed by the new > WXExecFromWriteSetter should use a new helper: > > ThreadToNativeWithWXExecFromVM > > so we'll see changes from: > > ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM > > where we need them and hopefully a short comment can be added > at the same time to explain the need for WXExec. This will allow us > to easily distinguish ThreadToNativeFromVM locations that DO NOT > need WXExec from those that DO need it. With a small overhead for tracking the current W^X state, I avoided WXExecFromWriteSetter near ThreadToNativeFromVM at all. New ThreadWXEnable(WXExec) is used only to call a generated function. More common ThreadWXEnable(WXWrite) is tied to JVM entry functions. I added comments for functions that are not clear to be entries, although they are. Thank you for the suggestion! ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:54 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:00:06 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 390: > >> 388: store_and_inc(_to, from_obj, NativeStack::intSpace); >> 389: >> 390: _num_int_args++; > > `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use 2 of them inside `if else` branches. > > We should be consistent. Agree. I'm going to do as much refactoring as needed before this patch under JDK-8261071 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:16:52 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:16:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 09:14:24 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271: >> >>> 5269: // >>> 5270: void MacroAssembler::get_thread(Register dst) { >>> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; >> >> The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ? > > Surely this should be > > saved_regs = RegSet::range(r0, r1) BSD_ONLY(+ RegSet::range(r2, r17)) + lr - dst;``` > > Shouldn't it? Interesting, I wonder why it has built successfully on Linux. I'm going to fix this under as JDK-8261072 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Wed Feb 3 20:32:47 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 20:32:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:04:18 GMT, Gerard Ziemski wrote: >> See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`. > > Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then. > > We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb: > > `// gdb installs both standard BSD signal handlers, and mach exception` > `// handlers. By replacing the existing task exception handler, we disable gdb's mach` > `// exception handling, while leaving the standard BSD signal handlers functional.` > > Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow? To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS` Remaining questions: a) why we need `EXC_MASK_ARITHMETIC` ? b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that? c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From fguallini at openjdk.java.net Wed Feb 3 22:08:12 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 3 Feb 2021 22:08:12 GMT Subject: RFR: 8163498: Many long-running security libs tests [v2] In-Reply-To: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: > The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg > sun/security/provider/DSA/SupportedDSAParamGen.java > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java > > sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: prove factory key spec and manual instantiated key spec are equal ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2381/files - new: https://git.openjdk.java.net/jdk/pull/2381/files/36a5276b..45b877e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2381&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2381&range=00-01 Stats: 38 lines in 1 file changed: 32 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2381/head:pull/2381 PR: https://git.openjdk.java.net/jdk/pull/2381 From fguallini at openjdk.java.net Wed Feb 3 22:08:12 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 3 Feb 2021 22:08:12 GMT Subject: RFR: 8163498: Many long-running security libs tests [v2] In-Reply-To: References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: On Wed, 3 Feb 2021 19:50:02 GMT, Weijun Wang wrote: >> That is right, PSSKeyCompatibility already explicitly proves they both are equal and there are other tests that generates both manually and using KeyFactory. In addition, this test focuses on signature verification rather than key creation. > > Not only does a key have encoded form and an algorithm, it might contain other internal info that could affect its usage (here, it's signing and verifying). That's why there are multiple keys there. > > A Spec type is different, it only has public data and is easy to prove equality. Sure, the equality verification was added now ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From burban at openjdk.java.net Wed Feb 3 22:19:58 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Wed, 3 Feb 2021 22:19:58 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:29:48 GMT, Gerard Ziemski wrote: >> Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then. >> >> We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb: >> >> `// gdb installs both standard BSD signal handlers, and mach exception` >> `// handlers. By replacing the existing task exception handler, we disable gdb's mach` >> `// exception handling, while leaving the standard BSD signal handlers functional.` >> >> Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow? > > To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS` > > Remaining questions: > > a) why we need `EXC_MASK_ARITHMETIC` ? > b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that? > c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? > d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? Thanks for your questions Gerard. > Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals. That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ). > Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow? `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? > a) why we need `EXC_MASK_ARITHMETIC` ? I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here. > b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that? The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`. > c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases. > d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? Maybe. I don't see any value in it though, except making the code more complicated to read ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From fguallini at openjdk.java.net Wed Feb 3 22:24:03 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 3 Feb 2021 22:24:03 GMT Subject: RFR: 8163498: Many long-running security libs tests [v3] In-Reply-To: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: > The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg > sun/security/provider/DSA/SupportedDSAParamGen.java > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java > > sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add key itself to signature verification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2381/files - new: https://git.openjdk.java.net/jdk/pull/2381/files/45b877e9..56ff061e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2381&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2381&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2381/head:pull/2381 PR: https://git.openjdk.java.net/jdk/pull/2381 From weijun at openjdk.java.net Wed Feb 3 22:37:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 3 Feb 2021 22:37:43 GMT Subject: RFR: 8163498: Many long-running security libs tests [v3] In-Reply-To: References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: <-0QaKTOZELEzDWUloZpaDP6UEsFzfHGF2WyoLaHrFgE=.3f96c83a-dc2f-44c8-b2a3-096e744b4f79@github.com> On Wed, 3 Feb 2021 22:24:03 GMT, Fernando Guallini wrote: >> The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg >> sun/security/provider/DSA/SupportedDSAParamGen.java >> sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java >> com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java >> >> sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > add key itself to signature verification New structure looks good. test/jdk/sun/security/provider/NSASuiteB/TestDSAGenParameterSpecLongKey.java line 30: > 28: * DSA within some certain range of key sizes as described in the class > 29: * specification (L, N) as (1024, 160), (2048, 224), (2048, 256) and > 30: * (3072, 256) should be OK for DSAGenParameterSpec. Please modify the `@summary` to match what this test does. test/jdk/sun/security/rsa/SignatureTest.java line 145: > 143: Asserts.assertTrue(keySpecEquals(pubKeySpec1, pubKeySpec2), > 144: "Both RSAPublicKeySpec should be equal"); > 145: Do you also want to add similar check on X509EncodedKeySpec? Same for PKCS8EncodedKeySpec below. ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From gziemski at openjdk.java.net Wed Feb 3 23:55:06 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 23:55:06 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 22:17:02 GMT, Bernhard Urban-Forster wrote: >> To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS` >> >> Remaining questions: >> >> a) why we need `EXC_MASK_ARITHMETIC` ? >> b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that? >> c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? >> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? > > Thanks for your questions Gerard. > >> Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals. > > That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ). > >> Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow? > > `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? > >> a) why we need `EXC_MASK_ARITHMETIC` ? > > I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here. > >> b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that? > > The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`. > >> c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? > > aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases. > >> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? > > Maybe. I don't see any value in it though, except making the code more complicated to read ?? I don't like the idea of using masks on architectures that do not require them. How about something like this? `#if defined(__APPLE__)` ` // lldb (gdb) installs both standard BSD signal handlers, and mach exception` ` // handlers. By replacing the existing task exception handler, we disable lldb's mach` ` // exception handling, while leaving the standard BSD signal handlers functional.` ` //` ` // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking` ` // EXC_MASK_ARITHMETIC needed by i386` ` // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization` ` kern_return_t kr;` ` kr = task_set_exception_ports(mach_task_self(),` ` EXC_MASK_BAD_ACCESS` ` NOT_LP64(| EXC_MASK_ARITHMETIC)` ` AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),` ` MACH_PORT_NULL,` ` EXCEPTION_STATE_IDENTITY,` ` MACHINE_THREAD_STATE);` ` ` ` assert(kr == KERN_SUCCESS, "could not set mach task signal handler");` `#endif` If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Wed Feb 3 23:55:07 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 23:55:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 22:44:18 GMT, Gerard Ziemski wrote: >> Thanks for your questions Gerard. >> >>> Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals. >> >> That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ). >> >>> Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow? >> >> `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? >> >>> a) why we need `EXC_MASK_ARITHMETIC` ? >> >> I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here. >> >>> b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that? >> >> The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`. >> >>> c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? >> >> aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases. >> >>> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? >> >> Maybe. I don't see any value in it though, except making the code more complicated to read ?? > > I don't like the idea of using masks on architectures that do not require them. How about something like this? > > `#if defined(__APPLE__)` > ` // lldb (gdb) installs both standard BSD signal handlers, and mach exception` > ` // handlers. By replacing the existing task exception handler, we disable lldb's mach` > ` // exception handling, while leaving the standard BSD signal handlers functional.` > ` //` > ` // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking` > ` // EXC_MASK_ARITHMETIC needed by i386` > ` // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization` > ` kern_return_t kr;` > ` kr = task_set_exception_ports(mach_task_self(),` > ` EXC_MASK_BAD_ACCESS` > ` NOT_LP64(| EXC_MASK_ARITHMETIC)` > ` AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),` > ` MACH_PORT_NULL,` > ` EXCEPTION_STATE_IDENTITY,` > ` MACHINE_THREAD_STATE);` > ` ` > ` assert(kr == KERN_SUCCESS, "could not set mach task signal handler");` > `#endif` > > If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code. No idea how to insert spaces and make text align :-( ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Wed Feb 3 23:55:07 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 23:55:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 23:13:12 GMT, Bernhard Urban-Forster wrote: >> No idea how to insert spaces and make text align :-( > > using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks > > I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64: > https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524 > and aarch64: > https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323 > (What happened with the formatting here, ugh?) > > Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that? So it should be: #if defined(__APPLE__) // lldb (gdb) installs both standard BSD signal handlers, and mach exception // handlers. By replacing the existing task exception handler, we disable lldb's mach // exception handling, while leaving the standard BSD signal handlers functional. // // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking // EXC_MASK_ARITHMETIC needed by all architectures for div by 0 checking // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization kern_return_t kr; kr = task_set_exception_ports(mach_task_self(), EXC_MASK_BAD_ACCESS | EXC_MASK_ARITHMETIC AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION), MACH_PORT_NULL, EXCEPTION_STATE_IDENTITY, MACHINE_THREAD_STATE); assert(kr == KERN_SUCCESS, "could not set mach task signal handler"); #endif ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Wed Feb 3 23:55:07 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Wed, 3 Feb 2021 23:55:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 22:48:33 GMT, Gerard Ziemski wrote: >> I don't like the idea of using masks on architectures that do not require them. How about something like this? >> >> `#if defined(__APPLE__)` >> ` // lldb (gdb) installs both standard BSD signal handlers, and mach exception` >> ` // handlers. By replacing the existing task exception handler, we disable lldb's mach` >> ` // exception handling, while leaving the standard BSD signal handlers functional.` >> ` //` >> ` // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking` >> ` // EXC_MASK_ARITHMETIC needed by i386` >> ` // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization` >> ` kern_return_t kr;` >> ` kr = task_set_exception_ports(mach_task_self(),` >> ` EXC_MASK_BAD_ACCESS` >> ` NOT_LP64(| EXC_MASK_ARITHMETIC)` >> ` AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),` >> ` MACH_PORT_NULL,` >> ` EXCEPTION_STATE_IDENTITY,` >> ` MACHINE_THREAD_STATE);` >> ` ` >> ` assert(kr == KERN_SUCCESS, "could not set mach task signal handler");` >> `#endif` >> >> If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code. > > No idea how to insert spaces and make text align :-( using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64: https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524 and aarch64: https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323 (What happened with the formatting here, ugh?) Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From mikael at openjdk.java.net Thu Feb 4 08:30:48 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 4 Feb 2021 08:30:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt wrote: >>> I wonder if this is the right choice >>> ... >>> ``` >>> OopStorageParIterPerf::~OopStorageParIterPerf() { >>> ... >>> ``` >>> >> >> The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite. >> >> I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped. >> >> I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ... are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests. >> >> Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore. >> >> W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions. >> >> Thank you! > > Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?). You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Thu Feb 4 09:51:57 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 4 Feb 2021 09:51:57 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Thu, 4 Feb 2021 08:26:35 GMT, Mikael Vidstedt wrote: > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. it's thread-specific https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon >Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From Alan.Bateman at oracle.com Thu Feb 4 10:36:14 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Feb 2021 10:36:14 +0000 Subject: Module jdk.jartool should provide jarsigner tool In-Reply-To: References: Message-ID: <00c18610-5351-6b34-9583-fd555a275d25@oracle.com> On 04/02/2021 07:38, Christian Stein wrote: > Module jdk.jartoo already provides java.util.spi.ToolProvider with > sun.tools.jar.JarToolProvider. [0] > > Is there a reason why it does provide a JarSignerToolProvider allowing > `jarsigner` to be run in-process? Perhaps too many System.exit() calls > in sun/security/tools/jarsigner/Main.java? > > cc'ing security-dev as that is where the jarsigner tool is maintained. This may have come up in JDK 9 but I can't find any mails in the archives. Yes, it would need a bit of refactoring so that the System.exit is only called when invoked via the launcher/main method. There are also CLI options that prompt for a password that may not be suitable for programmatic use. I'm sure Max or others on security-dev will have more to say on this. -Alan From valeriep at openjdk.java.net Thu Feb 4 10:58:14 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 4 Feb 2021 10:58:14 GMT Subject: RFR: 8248268: Support KWP in addition to KW Message-ID: This change updates SunJCE provider as below: - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. Thanks, Valerie ------------- Commit messages: - 8248268: Support KWP in addition to KW Changes: https://git.openjdk.java.net/jdk/pull/2404/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248268 Stats: 2534 lines in 14 files changed: 1923 ins; 536 del; 75 mod Patch: https://git.openjdk.java.net/jdk/pull/2404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404 PR: https://git.openjdk.java.net/jdk/pull/2404 From akozlov at openjdk.java.net Thu Feb 4 12:00:51 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 4 Feb 2021 12:00:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <9N0zJ8ZgY9e3yIF3IKnkdbkRu80waLyh8GHBti22DK8=.949c0612-f514-44a0-9d2b-ff9e2eb539d1@github.com> On Tue, 2 Feb 2021 22:56:55 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/runtime/stubRoutines.inline.hpp line 1: > >> 1: /* > > NOW I understand the reason for switching from include to inline-include. > Is there a reason that this change is part of this project and not extracted > into a separate RFE. That would reduce the number of files touched by > this project. Makes sense, thanks. I'll do this as JDK-8261075. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From jlaskey at openjdk.java.net Thu Feb 4 12:42:00 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 4 Feb 2021 12:42:00 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v16] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'master' into 8248862 - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. - Update package info to credit LMX algorithm - Merge branch 'master' into 8248862 - Correct range used by nextBytes - Merge branch 'master' into 8248862 - Use annotation for properties. Add getDefault(). - Merge branch 'master' into 8248862 - Introduce RandomGeneratorProperties annotation - ... and 34 more: https://git.openjdk.java.net/jdk/compare/83357b11...1c17ad35 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=15 Stats: 13259 lines in 26 files changed: 11119 ins; 2050 del; 90 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From valeriep at openjdk.java.net Thu Feb 4 12:44:20 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 4 Feb 2021 12:44:20 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v2] In-Reply-To: References: Message-ID: > This change updates SunJCE provider as below: > - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. > - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. > > Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. > > Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Restored Iv algorithm parameters impl. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2404/files - new: https://git.openjdk.java.net/jdk/pull/2404/files/fa468921..bc912f63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=00-01 Stats: 330 lines in 4 files changed: 177 ins; 147 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404 PR: https://git.openjdk.java.net/jdk/pull/2404 From fguallini at openjdk.java.net Thu Feb 4 13:08:46 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 4 Feb 2021 13:08:46 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset Message-ID: The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java javax/net/ssl/TLSCommon/TLSTest.java sun/security/ssl/CipherSuite/SupportedGroups.java javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. ------------- Commit messages: - update log message - add catch clause - Merge remote-tracking branch 'upstream/master' into 8241372 - bind to loopback address instead of wildcard Changes: https://git.openjdk.java.net/jdk/pull/2405/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241372 Stats: 29 lines in 4 files changed: 19 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405 PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Thu Feb 4 13:08:46 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 4 Feb 2021 13:08:46 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini wrote: > The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: > sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java > javax/net/ssl/TLSCommon/TLSTest.java > sun/security/ssl/CipherSuite/SupportedGroups.java > > > javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. @dfuch a similar fix was applied here: https://bugs.openjdk.java.net/browse/JDK-8230858 ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From aph at openjdk.java.net Thu Feb 4 14:30:49 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 4 Feb 2021 14:30:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Thu, 4 Feb 2021 09:49:17 GMT, Vladimir Kempik wrote: > > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. > > it's thread-specific > > https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon > > > Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region. Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Thu Feb 4 14:43:51 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 4 Feb 2021 14:43:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Thu, 4 Feb 2021 14:27:53 GMT, Andrew Haley wrote: > > > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. > > > > > > it's thread-specific > > https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon > > > Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region. > > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From dfuchs at openjdk.java.net Thu Feb 4 15:14:47 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 4 Feb 2021 15:14:47 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini wrote: > The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: > sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java > javax/net/ssl/TLSCommon/TLSTest.java > sun/security/ssl/CipherSuite/SupportedGroups.java > > > javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 29: > 27: /* > 28: * @test > 29: * @bug 4416068 4478803 4479736 8241372 Here and in the other tests: If a fix is a test bug and only contains test changes, we usually don't add the bug id to the modified tests. Instead we add the label `noreg-self` to the JBS issue. The bug ids in the tests files are supposed to identify *source changes* that can be verified by running the test. test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145: > 143: // The server side may have closed the socket. > 144: System.out.println("Client SSLException:"); > 145: ssle.printStackTrace(System.out); If security / TLS experts agree that this is OK, then it is OK for me. Not being an expert, I'd be concerned that catching plain SSLException might be too wide and that this might hide errors. In that case, and if the error is intermittent, one possibility could be to respin the test in case of SSLException (do client side and server side again) and fail if the second attempts fails too. test/jdk/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java line 90: > 88: (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); > 89: InetSocketAddress socketAddress = > 90: new InetSocketAddress(InetAddress.getLoopbackAddress(), serverPort); The client is using 127.0.0.1. InetAddress.getLoopbackAddress() might return ::1 (IPv6 loopback) on certain configurations. Two possibility: 1. run this test with -Djava.net.preferIPv4Stack to force usage of IPv4, but trivially pass if IPv4 is not available on the machine (see IPSupport in the test library) 2. use InetAddress.getLoopbackAddress().getHostAddress() on the client side instead of "127.0.0.1" If you choose 2. you may want to add an additional @run the test with -Djava.net.preferIPv6Address to verify that it works with IPv6 - as there are several ways to represent the IPv6 loopback as a string ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From akozlov at openjdk.java.net Thu Feb 4 15:16:49 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 4 Feb 2021 15:16:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com> On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt wrote: > Out of curiosity, have you looked at the performance of the W^X state transition? Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations. >From the other hand, I've used https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the cost of the transition. I re-did measurements with the current implementation and on consumer hardware: testJNI thrpt 25 277997000.151 ? 4095685.956 ops/s testJniNanoTime thrpt 25 17851098.010 ? 119489.599 ops/s testNanoTime thrpt 25 78007491.762 ? 628455.971 ops/s testNothing thrpt 25 1724298829.088 ? 100537565.068 ops/s testTwoStateAndWX thrpt 25 21958839.057 ? 210490.755 ops/s testWX thrpt 25 23299813.266 ? 149837.302 ops/s There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From valeriep at openjdk.java.net Thu Feb 4 15:22:44 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 4 Feb 2021 15:22:44 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v5] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 16:12:58 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > cleanups for key generations src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 690: > 688: limit = ROUNDS*4; > 689: > 690: // store the expanded sub keys into 'sessionK' Update the comment with "erase the previous values in sessionK or other similar wording. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Thu Feb 4 15:27:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 4 Feb 2021 15:27:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v5] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 16:12:58 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > cleanups for key generations src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java line 2: > 1: /* > 2: * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved. No changes? Why update copyright year? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From fguallini at openjdk.java.net Thu Feb 4 16:08:09 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 4 Feb 2021 16:08:09 GMT Subject: RFR: 8163498: Many long-running security libs tests [v4] In-Reply-To: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: > The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg > sun/security/provider/DSA/SupportedDSAParamGen.java > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java > > sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add short description regarding test split. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2381/files - new: https://git.openjdk.java.net/jdk/pull/2381/files/56ff061e..e408a627 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2381&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2381&range=02-03 Stats: 41 lines in 7 files changed: 37 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2381/head:pull/2381 PR: https://git.openjdk.java.net/jdk/pull/2381 From fguallini at openjdk.java.net Thu Feb 4 16:08:11 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 4 Feb 2021 16:08:11 GMT Subject: RFR: 8163498: Many long-running security libs tests [v3] In-Reply-To: <-0QaKTOZELEzDWUloZpaDP6UEsFzfHGF2WyoLaHrFgE=.3f96c83a-dc2f-44c8-b2a3-096e744b4f79@github.com> References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> <-0QaKTOZELEzDWUloZpaDP6UEsFzfHGF2WyoLaHrFgE=.3f96c83a-dc2f-44c8-b2a3-096e744b4f79@github.com> Message-ID: On Wed, 3 Feb 2021 22:30:02 GMT, Weijun Wang wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> add key itself to signature verification > > test/jdk/sun/security/provider/NSASuiteB/TestDSAGenParameterSpecLongKey.java line 30: > >> 28: * DSA within some certain range of key sizes as described in the class >> 29: * specification (L, N) as (1024, 160), (2048, 224), (2048, 256) and >> 30: * (3072, 256) should be OK for DSAGenParameterSpec. > > Please modify the `@summary` to match what this test does. sure, short description about this change was added to summary > test/jdk/sun/security/rsa/SignatureTest.java line 145: > >> 143: Asserts.assertTrue(keySpecEquals(pubKeySpec1, pubKeySpec2), >> 144: "Both RSAPublicKeySpec should be equal"); >> 145: > > Do you also want to add similar check on X509EncodedKeySpec? Same for PKCS8EncodedKeySpec below. Both verifications included now ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From valeriep at openjdk.java.net Thu Feb 4 16:15:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 4 Feb 2021 16:15:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: References: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> Message-ID: On Thu, 28 Jan 2021 16:13:01 GMT, Weijun Wang wrote: > > > New commit for key generations. How about the Tls*Generator classes in SunJCE provider? Looks like they need to be handled as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Thu Feb 4 16:17:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 4 Feb 2021 16:17:41 GMT Subject: RFR: 8163498: Many long-running security libs tests [v4] In-Reply-To: References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: On Thu, 4 Feb 2021 16:08:09 GMT, Fernando Guallini wrote: >> The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg >> sun/security/provider/DSA/SupportedDSAParamGen.java >> sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java >> com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java >> >> sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > add short description regarding test split. Perfect. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2381 From github.com+30433125+djelinski at openjdk.java.net Thu Feb 4 19:16:59 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Thu, 4 Feb 2021 19:16:59 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v3] In-Reply-To: References: Message-ID: > Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. > > First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. > Baseline results before any MemoryCache changes: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op > CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op > CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op > CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op > there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. > > Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op > CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op > The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. > > The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op > CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op > I wasn't expecting that much of an improvement, and don't know how to explain it. > > The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. djelinski has updated the pull request incrementally with one additional commit since the last revision: Add benchmarks for get and remove ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2255/files - new: https://git.openjdk.java.net/jdk/pull/2255/files/34949970..abe0e238 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=01-02 Stats: 76 lines in 1 file changed: 54 ins; 4 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/2255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2255/head:pull/2255 PR: https://git.openjdk.java.net/jdk/pull/2255 From github.com+30433125+djelinski at openjdk.java.net Thu Feb 4 19:19:42 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Thu, 4 Feb 2021 19:19:42 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> Message-ID: <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> On Tue, 2 Feb 2021 12:19:22 GMT, djelinski wrote: >> If I get the patch right, the benchmark performance improvement is a trade-off between CPU and memory, by keeping expired entries while putting a new entry in the cache. I'm not very sure of the performance impact on memory and GC collections. Would you mind add two more types of benchmark: get the entries and remove the entries, for cases that there are 1/10, 1/4, 1/3 and 1/2 expired entries in the cache? And increase the size to some big scales, like 2M and 20M. >> >> It looks like a spec update as it may change the behavior of a few JDK components (TLS session cache, OCSP stapling response cache, cert store cache, certificate factory, etc), because of "expired entries are no longer guaranteed to be removed before live ones". I'm not very sure of the impact. I may suggest to file a CSR and have more eyes to check the compatibility impact before moving forward. > >> the benchmark performance improvement is a trade-off between CPU and memory, by keeping expired entries while putting a new entry in the cache > > Not exactly. The memory use is capped by cache size. The patch is a trade off between the cache's hit/miss ratio and CPU; we will get faster cache access at the cost of more frequent cache misses. > > All calls to `put()` remove expired items from the front of the queue, and never perform a full scan. `get()` calls shuffle the queue, moving the accessed item to the back. Compare this to original code where `put()` only removed expired items when the cache overflowed, and scanned the entire cache. > Let me give some examples. > **Example 1**: insertions at a fast pace leading to cache overflows and no expirations. Here the new implementation improves performance. Consider a cache with size=4, timeout=10, and the following sequence of events: > T=1, put(1); > T=2, put(2); > T=3, put(3); > T=4, put(4); > Cache contents after these calls (same in old and new scenario). Queue order: least recently accessed items on the left, most recently accessed on the right. _K_ denotes cache key, _exp_ denotes entry expiration time and is equal to insertion time _T_ plus timeout: > > |K=1, exp=11|K=2, exp=12|K=3, exp=13|K=4, exp=14| > > If we now add another item to the queue, it will overflow. Here's where the implementations behave differently, but the outcome is identical: old one scans the entire list for expired entries; new one improves performance by ending the search for expired entries after encountering the first non-expired entry (which is the first entry in the above example). The end result is the same in both cases - oldest (least recently accessed) item is dropped: > T=5, put(5) > > |K=2, exp=12|K=3, exp=13|K=4, exp=14|K=5, exp=15| > > **Example 2**: insertions at a moderate pace, with interleaved reads. Here the new implementation improves performance, but at a possible cost of wasting cache capacity on expired entries. Consider a cache with size=4, timeout=7, and the following sequence of events: > T=1, put(1); > T=3, put(3); > T=5, put(5); > T=7, put(7); > T=7, get(1); > Cache contents after these calls: > > |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=1, exp=8| > > `get(1)` operation moved item with K=1 to the back of the queue. > > If we wait for item with K=1 to expire and then add another item to the queue, it will overflow. Here's where the implementations behave differently, and the outcome is different: old one scans the entire list for expired entries, finds entry with K=1 and drops it; new one gives up after first non-expired entry (which is the first entry), and drops the first entry. > > So, when we perform: > T=9, put(9); > > Old implementation will get: > |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16| > > New implementation will get: > |K=5, exp=12|K=7, exp=14|K=1, exp=8(expired)|K=9, exp=16| > > Note that: > - an attempt to retrieve expired item (i.e. `get(1)`) will immediately remove that item from cache, making room for other items > - retrieving a non-expired item will move it to the back of the queue, behind all expired items > > **Example 3**: insertions at a slow pace, where most items expire before queue overflows. Here the new implementation improves memory consumption. Consider a cache with size=4, timeout=1, and the following sequence of events: > T=1, put(1); > T=3, put(3); > T=5, put(5); > T=7, put(7); > Every cache item is expired at then point when a new one is added. Old implementation only removes expired entries when cache overflows, so all entries will still be there: > > |K=1, exp=2(expired)|K=3, exp=4(expired)|K=5, exp=6(expired)|K=7, exp=8| > > New implementation removes expired entries on every put, so after the last put only one entry is in the cache: > > |K=7, exp=8| > > After another put the old implementation will encounter a cache overflow and remove all expired items. > > Let me know if that helped. > >> add two more types of benchmark: get the entries and remove the entries > > Both these operations are constant-time, both before and after my changes. Do you expect to see some oddities here, or do we just want a benchmark that could be used to compare other implementations? > >> increase the size to some big scales, like 2M and 20M > > Can do. Do you think it makes sense to also benchmark the scenario where GC kicks in and collects soft references? > >> it may change the behavior of a few JDK components > > Of all uses of Cache, only `SSLSessionContextImpl` (TLS session cache), `StatusResponseManager` (OCSP stapling) and `LDAPCertStoreImpl` (I'm not familiar with that one) set expiration timeout; when the timeout is not set, the behavior is exactly the same as before. > `StatusResponseManager` is constantly querying the same keys, and is liberally sized, so I don't expect much of an impact. > TLS session cache changes may result in fewer session resumptions and more full handshakes; I expect the cache performance improvement to more than offset the CPU cycles lost on full handshakes. > > How do I file a CSR? > > Also, what do you think about the changes done in `Do not invalidate objects before GC` 5859a03 commit? They offer a minor performance improvement, but if clearing the values before GC is an important security feature of this cache, I'm prepared to drop that commit. Added benchmarks for get & remove. Added tests for 5M cache size. Switched time units to nanoseconds. Results: Benchmark (size) (timeout) Mode Cnt Score Error Units CacheBench.get 20480 86400 avgt 25 62.999 ? 2.017 ns/op CacheBench.get 20480 0 avgt 25 41.519 ? 1.113 ns/op CacheBench.get 204800 86400 avgt 25 67.995 ? 4.530 ns/op CacheBench.get 204800 0 avgt 25 46.439 ? 2.222 ns/op CacheBench.get 5120000 86400 avgt 25 72.516 ? 0.759 ns/op CacheBench.get 5120000 0 avgt 25 53.471 ? 0.491 ns/op CacheBench.put 20480 86400 avgt 25 117.117 ? 3.424 ns/op CacheBench.put 20480 0 avgt 25 73.582 ? 1.484 ns/op CacheBench.put 204800 86400 avgt 25 116.983 ? 0.743 ns/op CacheBench.put 204800 0 avgt 25 73.945 ? 0.515 ns/op CacheBench.put 5120000 86400 avgt 25 230.878 ? 7.582 ns/op CacheBench.put 5120000 0 avgt 25 192.526 ? 7.048 ns/op CacheBench.remove 20480 86400 avgt 25 39.048 ? 2.036 ns/op CacheBench.remove 20480 0 avgt 25 36.293 ? 0.281 ns/op CacheBench.remove 204800 86400 avgt 25 43.899 ? 0.895 ns/op CacheBench.remove 204800 0 avgt 25 43.046 ? 0.759 ns/op CacheBench.remove 5120000 86400 avgt 25 51.896 ? 0.640 ns/op CacheBench.remove 5120000 0 avgt 25 51.537 ? 0.536 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From research at bensmyth.com Thu Feb 4 19:37:00 2021 From: research at bensmyth.com (Ben Smyth) Date: Thu, 4 Feb 2021 20:37:00 +0100 Subject: OpenJDK-TLS Manual: (Second) call for contributions Message-ID: I've written an OpenJDK-TLS manual, intended to ease readers into the most recent TLS specification and OpenJDK's implementation. (At the very least, it helped me get to grips with the spec and the code!) I've made the manual available on GitHub (https://github.com/BenSmyth/tls-tutorial/) and a pdf is also available: https://bensmyth.com/files/Smyth19-TLS-tutorial.pdf I hope the manual will help you too. I'm far from perfect and I'm sure the manuscript has numerous deficiencies. Interesting aspects are omitted, because I didn't have the time, knowledge, or expertise to add them. In particular, my coverage of OpenJDK could be substantially improved and extended. I encourage you to improve the manuscript. Fix a typo. Patch grammar. Revise awkward, overcomplicated, or otherwise poorly-written passages, and correct my outright mistakes. Contribute an entire section, there's certainly a lot of scope regarding OpenJDK. Help evolve the manual. (Perhaps get in touch prior to writing an entire section! We should probably reach consensus on what to add.) Contributions will be recognised through acknowledgements or co-authorship. Best regards, Ben -- https://bensmyth.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Thu Feb 4 19:40:42 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 4 Feb 2021 19:40:42 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> Message-ID: On Thu, 4 Feb 2021 19:17:21 GMT, djelinski wrote: >>> the benchmark performance improvement is a trade-off between CPU and memory, by keeping expired entries while putting a new entry in the cache >> >> Not exactly. The memory use is capped by cache size. The patch is a trade off between the cache's hit/miss ratio and CPU; we will get faster cache access at the cost of more frequent cache misses. >> >> All calls to `put()` remove expired items from the front of the queue, and never perform a full scan. `get()` calls shuffle the queue, moving the accessed item to the back. Compare this to original code where `put()` only removed expired items when the cache overflowed, and scanned the entire cache. >> Let me give some examples. >> **Example 1**: insertions at a fast pace leading to cache overflows and no expirations. Here the new implementation improves performance. Consider a cache with size=4, timeout=10, and the following sequence of events: >> T=1, put(1); >> T=2, put(2); >> T=3, put(3); >> T=4, put(4); >> Cache contents after these calls (same in old and new scenario). Queue order: least recently accessed items on the left, most recently accessed on the right. _K_ denotes cache key, _exp_ denotes entry expiration time and is equal to insertion time _T_ plus timeout: >> >> |K=1, exp=11|K=2, exp=12|K=3, exp=13|K=4, exp=14| >> >> If we now add another item to the queue, it will overflow. Here's where the implementations behave differently, but the outcome is identical: old one scans the entire list for expired entries; new one improves performance by ending the search for expired entries after encountering the first non-expired entry (which is the first entry in the above example). The end result is the same in both cases - oldest (least recently accessed) item is dropped: >> T=5, put(5) >> >> |K=2, exp=12|K=3, exp=13|K=4, exp=14|K=5, exp=15| >> >> **Example 2**: insertions at a moderate pace, with interleaved reads. Here the new implementation improves performance, but at a possible cost of wasting cache capacity on expired entries. Consider a cache with size=4, timeout=7, and the following sequence of events: >> T=1, put(1); >> T=3, put(3); >> T=5, put(5); >> T=7, put(7); >> T=7, get(1); >> Cache contents after these calls: >> >> |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=1, exp=8| >> >> `get(1)` operation moved item with K=1 to the back of the queue. >> >> If we wait for item with K=1 to expire and then add another item to the queue, it will overflow. Here's where the implementations behave differently, and the outcome is different: old one scans the entire list for expired entries, finds entry with K=1 and drops it; new one gives up after first non-expired entry (which is the first entry), and drops the first entry. >> >> So, when we perform: >> T=9, put(9); >> >> Old implementation will get: >> |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16| >> >> New implementation will get: >> |K=5, exp=12|K=7, exp=14|K=1, exp=8(expired)|K=9, exp=16| >> >> Note that: >> - an attempt to retrieve expired item (i.e. `get(1)`) will immediately remove that item from cache, making room for other items >> - retrieving a non-expired item will move it to the back of the queue, behind all expired items >> >> **Example 3**: insertions at a slow pace, where most items expire before queue overflows. Here the new implementation improves memory consumption. Consider a cache with size=4, timeout=1, and the following sequence of events: >> T=1, put(1); >> T=3, put(3); >> T=5, put(5); >> T=7, put(7); >> Every cache item is expired at then point when a new one is added. Old implementation only removes expired entries when cache overflows, so all entries will still be there: >> >> |K=1, exp=2(expired)|K=3, exp=4(expired)|K=5, exp=6(expired)|K=7, exp=8| >> >> New implementation removes expired entries on every put, so after the last put only one entry is in the cache: >> >> |K=7, exp=8| >> >> After another put the old implementation will encounter a cache overflow and remove all expired items. >> >> Let me know if that helped. >> >>> add two more types of benchmark: get the entries and remove the entries >> >> Both these operations are constant-time, both before and after my changes. Do you expect to see some oddities here, or do we just want a benchmark that could be used to compare other implementations? >> >>> increase the size to some big scales, like 2M and 20M >> >> Can do. Do you think it makes sense to also benchmark the scenario where GC kicks in and collects soft references? >> >>> it may change the behavior of a few JDK components >> >> Of all uses of Cache, only `SSLSessionContextImpl` (TLS session cache), `StatusResponseManager` (OCSP stapling) and `LDAPCertStoreImpl` (I'm not familiar with that one) set expiration timeout; when the timeout is not set, the behavior is exactly the same as before. >> `StatusResponseManager` is constantly querying the same keys, and is liberally sized, so I don't expect much of an impact. >> TLS session cache changes may result in fewer session resumptions and more full handshakes; I expect the cache performance improvement to more than offset the CPU cycles lost on full handshakes. >> >> How do I file a CSR? >> >> Also, what do you think about the changes done in `Do not invalidate objects before GC` 5859a03 commit? They offer a minor performance improvement, but if clearing the values before GC is an important security feature of this cache, I'm prepared to drop that commit. > > Added benchmarks for get & remove. Added tests for 5M cache size. Switched time units to nanoseconds. Results: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.get 20480 86400 avgt 25 62.999 ? 2.017 ns/op > CacheBench.get 20480 0 avgt 25 41.519 ? 1.113 ns/op > CacheBench.get 204800 86400 avgt 25 67.995 ? 4.530 ns/op > CacheBench.get 204800 0 avgt 25 46.439 ? 2.222 ns/op > CacheBench.get 5120000 86400 avgt 25 72.516 ? 0.759 ns/op > CacheBench.get 5120000 0 avgt 25 53.471 ? 0.491 ns/op > CacheBench.put 20480 86400 avgt 25 117.117 ? 3.424 ns/op > CacheBench.put 20480 0 avgt 25 73.582 ? 1.484 ns/op > CacheBench.put 204800 86400 avgt 25 116.983 ? 0.743 ns/op > CacheBench.put 204800 0 avgt 25 73.945 ? 0.515 ns/op > CacheBench.put 5120000 86400 avgt 25 230.878 ? 7.582 ns/op > CacheBench.put 5120000 0 avgt 25 192.526 ? 7.048 ns/op > CacheBench.remove 20480 86400 avgt 25 39.048 ? 2.036 ns/op > CacheBench.remove 20480 0 avgt 25 36.293 ? 0.281 ns/op > CacheBench.remove 204800 86400 avgt 25 43.899 ? 0.895 ns/op > CacheBench.remove 204800 0 avgt 25 43.046 ? 0.759 ns/op > CacheBench.remove 5120000 86400 avgt 25 51.896 ? 0.640 ns/op > CacheBench.remove 5120000 0 avgt 25 51.537 ? 0.536 ns/op Thank you for the comment. The big picture is more clear to me now. > Example 2: > Old implementation will get: > |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16| > > New implementation will get: > |K=5, exp=12|K=7, exp=14|K=1, exp=8(expired)|K=9, exp=16| K=3 is not expired yet, but get removed, while K=1 is kept. This behavior change may cause more overall performance hurt than improving the cache put/get performance. For example, it need to grab the value remotely. A full handshake or OCSP status grabbing could counteract all the performance gain with the cache update. > All calls to put() remove expired items from the front of the queue, and never perform a full scan. get() calls shuffle the queue, moving the accessed item to the back. Compare this to original code where put() only removed expired items when the cache overflowed, and scanned the entire cache. I think the idea that put() remove expired items from the front of the queue is good. I was wondering if it is an option to have the get() method that removed expired items until the 1st un-expired item, without scan the full queue and change the order of the queue. But there is still an issue that the SoftReference may have clear an item, which may be still valid. In general, I think the get() performance is more important than put() method, as get() is called more frequently. So we should try to keep the cache small if possible. >> increase the size to some big scales, like 2M and 20M > > Can do. Do you think it makes sense to also benchmark the scenario where GC kicks in and collects soft references? In the update, the SoftReference.clear() get removed. I'm not sure of the impact of the enqueued objects any longer. In theory, it could improve the memory use, which could counteract the performance gain in some situation. > Also, what do you think about the changes done in Do not invalidate objects before GC 5859a03 commit? See above, it is a concern to me that the soft reference cannot be cleared with this update. > How do I file a CSR? Could you edit the bug: https://bugs.openjdk.java.net/browse/JDK-8259886? In the more drop down menu, there is a "Create CSR" option. You can do it if we have an agreement about the solution and impact. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From github.com+30433125+djelinski at openjdk.java.net Thu Feb 4 20:48:42 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Thu, 4 Feb 2021 20:48:42 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> Message-ID: <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> On Thu, 4 Feb 2021 19:36:24 GMT, Xue-Lei Andrew Fan wrote: >> Added benchmarks for get & remove. Added tests for 5M cache size. Switched time units to nanoseconds. Results: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.get 20480 86400 avgt 25 62.999 ? 2.017 ns/op >> CacheBench.get 20480 0 avgt 25 41.519 ? 1.113 ns/op >> CacheBench.get 204800 86400 avgt 25 67.995 ? 4.530 ns/op >> CacheBench.get 204800 0 avgt 25 46.439 ? 2.222 ns/op >> CacheBench.get 5120000 86400 avgt 25 72.516 ? 0.759 ns/op >> CacheBench.get 5120000 0 avgt 25 53.471 ? 0.491 ns/op >> CacheBench.put 20480 86400 avgt 25 117.117 ? 3.424 ns/op >> CacheBench.put 20480 0 avgt 25 73.582 ? 1.484 ns/op >> CacheBench.put 204800 86400 avgt 25 116.983 ? 0.743 ns/op >> CacheBench.put 204800 0 avgt 25 73.945 ? 0.515 ns/op >> CacheBench.put 5120000 86400 avgt 25 230.878 ? 7.582 ns/op >> CacheBench.put 5120000 0 avgt 25 192.526 ? 7.048 ns/op >> CacheBench.remove 20480 86400 avgt 25 39.048 ? 2.036 ns/op >> CacheBench.remove 20480 0 avgt 25 36.293 ? 0.281 ns/op >> CacheBench.remove 204800 86400 avgt 25 43.899 ? 0.895 ns/op >> CacheBench.remove 204800 0 avgt 25 43.046 ? 0.759 ns/op >> CacheBench.remove 5120000 86400 avgt 25 51.896 ? 0.640 ns/op >> CacheBench.remove 5120000 0 avgt 25 51.537 ? 0.536 ns/op > > Thank you for the comment. The big picture is more clear to me now. > >> Example 2: >> Old implementation will get: >> |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16| >> >> New implementation will get: >> |K=5, exp=12|K=7, exp=14|K=1, exp=8(expired)|K=9, exp=16| > > K=3 is not expired yet, but get removed, while K=1 is kept. This behavior change may cause more overall performance hurt than improving the cache put/get performance. For example, it need to grab the value remotely. A full handshake or OCSP status grabbing could counteract all the performance gain with the cache update. > >> All calls to put() remove expired items from the front of the queue, and never perform a full scan. get() calls shuffle the queue, moving the accessed item to the back. Compare this to original code where put() only removed expired items when the cache overflowed, and scanned the entire cache. > > I think the idea that put() remove expired items from the front of the queue is good. I was wondering if it is an option to have the get() method that removed expired items until the 1st un-expired item, without scan the full queue and change the order of the queue. But there is still an issue that the SoftReference may have clear an item, which may be still valid. > > In general, I think the get() performance is more important than put() method, as get() is called more frequently. So we should try to keep the cache small if possible. > >>> increase the size to some big scales, like 2M and 20M >> >> Can do. Do you think it makes sense to also benchmark the scenario where GC kicks in and collects soft references? > > In the update, the SoftReference.clear() get removed. I'm not sure of the impact of the enqueued objects any longer. In theory, it could improve the memory use, which could counteract the performance gain in some situation. > >> Also, what do you think about the changes done in Do not invalidate objects before GC 5859a03 commit? > See above, it is a concern to me that the soft reference cannot be cleared with this update. > >> How do I file a CSR? > Could you edit the bug: https://bugs.openjdk.java.net/browse/JDK-8259886? In the more drop down menu, there is a "Create CSR" option. You can do it if we have an agreement about the solution and impact. Thanks for your review! Some comments below. > A full handshake or OCSP status grabbing could counteract all the performance gain with the cache update. Yes, but that's unlikely. Note that K=3 is before K=1 in the queue only because 3 wasn't used since 1 was last used. This means that either K=3 is used less frequently than K=1, or that all cached items are in active use. In the former case we don't lose much by dropping K=3, and in the latter we are dealing with full cache at all times, which means that most `put()`s remove un-expired items anyway. > get() [..] without [..] change the order of the queue If we do that, frequently used entries will be evicted at the same age as never used ones. This means we will have to recompute (full handshake/fresh OCSP) both the frequently used and the infrequently used entries. It's better to recompute only the infrequently used ones, and reuse the frequently used as long as possible - we will do less work that way. > get() performance is more important [..] so we should try to keep the cache small if possible I don't see the link; could you explain? > In the update, the SoftReference.clear() get removed. I'm not sure of the impact of the enqueued objects any longer. In theory, it could improve the memory use, which could counteract the performance gain in some situation. That's the best part: no objects ever get enqueued! We only called `clear()` right before losing the last reference to `SoftCacheEntry` (which is the `SoftReference`). When GC collects the `SoftReference`, it does not enqueue anything. GC only enqueues the `SoftReference` when it collects the referenced object (session / OCSP response) without collecting the `SoftReference` (cache entry) itself. I wasn't sure about this at first, so I added code to crash the benchmark if `emptyQueue` ever finds anything. It didn't crash. > Could you edit the bug I'd need an account on the bug tracker first. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From vkempik at openjdk.java.net Thu Feb 4 21:53:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 4 Feb 2021 21:53:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com> References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com> Message-ID: On Thu, 4 Feb 2021 15:13:49 GMT, Anton Kozlov wrote: >> Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?). > >> Out of curiosity, have you looked at the performance of the W^X state transition? > > Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations. > > From the other hand, I've used https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the cost of the transition. > I re-did measurements with the current implementation and on consumer hardware: > > testJNI thrpt 25 277997000.151 ? 4095685.956 ops/s > testJniNanoTime thrpt 25 17851098.010 ? 119489.599 ops/s > testNanoTime thrpt 25 78007491.762 ? 628455.971 ops/s > testNothing thrpt 25 1724298829.088 ? 100537565.068 ops/s > testTwoStateAndWX thrpt 25 21958839.057 ? 210490.755 ops/s > testWX thrpt 25 23299813.266 ? 149837.302 ops/s > > There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry. > _Mailing list message from [erik.joelsson at oracle.com](mailto:erik.joelsson at oracle.com) on [2d-dev](mailto:2d-dev at openjdk.java.net):_ > > On 2021-01-26 04:44, Magnus Ihse Bursie wrote: > > > On 2021-01-26 13:09, Vladimir Kempik wrote: > > > On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward > > > wrote: > > > > AIUI, the configure line needs passing a prebuilt > > > > JavaNativeFoundation framework > > > > ie: > > > > `--with-extra-ldflags='-F > > > > /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` > > > > Otherwise there will be missing _JNFNative* functions. > > > > Is this the long term plan? Or will eventually the required code be > > > > moved into JDK and/or the xcode one automatically get picked up by > > > > the configure scripts? > > > > There is ongoing work by P. Race to eliminate dependence on JNF at all > > > > How far has that work come? Otherwise the logic should be added to > > > > configure to look for this framework automatically, and provide a way > > > > to override it/set it if not found. > > > > > > I don't think it's OK to publish a new port that cannot build > > out-of-the-box without hacks like this. > > My understanding is that Apple chose to not provide JNF for aarch64, so > if you want to build OpenJDK, you first need to build JNF yourself (it's > available in github). Phil is working on removing this dependency > completely, which will solve this issue [1]. > > In the meantime, I don't think we should rely on finding JNF in > unsupported locations inside Xcode. Could we wait with integrating this > port until it can be built without such hacks? If not, then adding > something in the documentation on how to get a working JNF would at > least be needed. > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8257852 This doesn't seem to be an issue anymore, After P.Race have finished with JDK-8257852, Macarm port can be build without extra ld flags. J2Demo works fine as example. This can be checked if one merges pull/2200 branch into his local copy of master branch. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:01:51 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:01:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com> On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194: > 192: // may get turned off by -fomit-frame-pointer. > 193: frame os::get_sender_for_C_frame(frame* fr) { > 194: return frame(fr->link(), fr->link(), fr->sender_pc()); Why is it return frame(fr->link(), fr->link(), fr->sender_pc()); and not return frame(fr->sender_sp(), fr->link(), fr->sender_pc()); like in the bsd-x86 counter part? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:18:49 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:18:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 291: > 289: bool is_unsafe_arraycopy = (thread->doing_unsafe_access() && UnsafeCopyMemory::contains_pc(pc)); > 290: if ((nm != NULL && nm->has_unsafe_access()) || is_unsafe_arraycopy) { > 291: address next_pc = pc + NativeCall::instruction_size; Replace address next_pc = pc + NativeCall::instruction_size; with address next_pc = Assembler::locate_next_instruction(pc); there is at least one other place that needs it. src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 322: > 320: #ifdef __APPLE__ > 321: } else if (sig == SIGFPE && info->si_code == FPE_NOOP) { > 322: Unimplemented(); Is there a follow up issue for this? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:22:48 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:22:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 198: > 196: > 197: NOINLINE frame os::current_frame() { > 198: intptr_t *fp = *(intptr_t **)__builtin_frame_address(0); In the bsd_x86 counter part we initialize `fp` to `_get_previous_fp()` - do we need to implement it on aarch64 as well (and using address 0 is just a temp workaround) or is it doing the right thing here? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:36:49 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:36:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com> On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 237: > 235: os::Posix::ucontext_set_pc(uc, StubRoutines::continuation_for_safefetch_fault(pc)); > 236: return true; > 237: } Isn't this case already handled by `JVM_HANDLE_XXX_SIGNAL()` ? Why do we need it here again? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:44:47 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:44:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <5xcTYtv5IrRdAkhPa6uG0C__8L6IsXKQOCsAaeha0vk=.217371e5-85a4-4b62-a885-5236a94cd242@github.com> On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302: > 300: const uint64_t *detail_msg_ptr > 301: = (uint64_t*)(pc + NativeInstruction::instruction_size); > 302: const char *detail_msg = (const char *)*detail_msg_ptr; Where is `detail_msg` used? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:51:50 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:51:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297: > 295: stub = SharedRuntime::handle_unsafe_access(thread, next_pc); > 296: } > 297: } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) { Can we add a comment here describing what this case means? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 23:08:50 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 23:08:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests I reviewed bsd_aarch64.cpp digging bit deeper and left some comments. ------------- Changes requested by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Thu Feb 4 23:32:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 4 Feb 2021 23:32:45 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v5] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 15:25:14 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanups for key generations > > src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java line 2: > >> 1: /* >> 2: * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved. > > No changes? Why update copyright year? Oops. Will revert. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Thu Feb 4 23:53:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 4 Feb 2021 23:53:45 GMT Subject: RFR: 8258915: Temporary buffer cleanup In-Reply-To: References: <3huz4-M0uvvkVcjW65pMh4ztclajxPGlVAUpjq2JgU8=.68888537-9851-418e-b517-65f4aa89d28e@github.com> Message-ID: On Thu, 4 Feb 2021 16:13:11 GMT, Valerie Peng wrote: > > New commit for key generations. > > How about the Tls*Generator classes in SunJCE provider? Looks like they need to be handled as well. I'll take a look. I thought the secrets going in and out of them are ephemeral. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Fri Feb 5 00:25:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 5 Feb 2021 00:25:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v5] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 15:20:02 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanups for key generations > > src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 690: > >> 688: limit = ROUNDS*4; >> 689: >> 690: // store the expanded sub keys into 'sessionK' > > Update the comment with "erase the previous values in sessionK or other similar wording. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From gziemski at openjdk.java.net Fri Feb 5 05:03:54 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 5 Feb 2021 05:03:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403: > 401: } > 402: > 403: return false; // Mute compiler Is this comment needed? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 420: > 418: size_t os::Posix::_compiler_thread_min_stack_allowed = 72 * K; > 419: size_t os::Posix::_java_thread_min_stack_allowed = 72 * K; > 420: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 72 * K; Those are slightly larger than their x86_64 counter parts. Are they conservative/aggressive values? How did we arrive at those? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 652: > 650: > 651: void os::setup_fpu() { > 652: } Is there really nothing to do here, or does still need to be implemented? A clarification comment here would help/. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Fri Feb 5 05:03:53 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 5 Feb 2021 05:03:53 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:09:58 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363: > >> 361: address pc = os::Posix::ucontext_get_pc(uc); >> 362: >> 363: if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means > > Is this TODO going to be resolved by this port? Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 374: > >> 372: >> 373: last_addr = (address) -1; >> 374: } else if (pc == addr && uc->context_esr == 0x8200000f) { //TODO: figure out what this value means > > Is this TODO going to be resolved by this port? Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From fguallini at openjdk.java.net Fri Feb 5 05:25:42 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 5 Feb 2021 05:25:42 GMT Subject: Integrated: 8163498: Many long-running security libs tests In-Reply-To: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> References: <0BL9nMhNHaRxctGKUvfJ3IHOM0koFKvVXaUXx96Tpoo=.fe94c440-4084-42c5-aa0d-3e32890482de@github.com> Message-ID: On Wed, 3 Feb 2021 13:29:54 GMT, Fernando Guallini wrote: > The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg > sun/security/provider/DSA/SupportedDSAParamGen.java > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java > > sun/security/rsa/SignatureTest.java is now using a fake generator since its objective is to test signature not key generation itself. In addition, it was generating and verifying the same key twice, with same modulus and exponent. That redundancy is removed. This speeds up the execution from ~54s to ~25s on average This pull request has now been integrated. Changeset: d2bd4992 Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/d2bd4992 Stats: 285 lines in 8 files changed: 259 ins; 9 del; 17 mod 8163498: Many long-running security libs tests Reviewed-by: rhalade, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/2381 From djelinski1 at gmail.com Fri Feb 5 07:42:40 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Fri, 5 Feb 2021 08:42:40 +0100 Subject: JSSE reference guide issue Message-ID: Hi all, What's the right spot to report documentation issues? I've been reading the JSSE reference guide and noticed that in section "Resuming Session Without Server-Side State" (https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810) it says "This feature is not enabled by default", which appears to be a leftover from Java 13. Also the note about TLS 1.3 in the same section isn't entirely clear to me. What does it mean when the docs say "the contents of stateless tickets, in particular, the contents of a NewSessionTicket message, depend on the value of jdk.tls.server.enableSessionTicketExtension"? How exactly does the contents change and why should I care? Regards, Daniel From ihse at openjdk.java.net Fri Feb 5 09:51:54 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Feb 2021 09:51:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > make/autoconf/flags.m4 line 140: > >> 138: else >> 139: MACOSX_VERSION_MIN=10.12.0 >> 140: fi > > Not something that needs to be addressed here, but these changes > illustrate that our collective use of macOSX/MACOSX/MacOSX names > are tied to the fact that the macOS major version number was at 10 > for a very long time. > > @magicus - Do we have an RFE to rename MACOSX or are we sticking > with it and evolving our interpretation of the 'X' from '10' to */splat/asterik? @dcubed-ojdk There is no RFE to renaming "macosx" to "macos". I'm not sure it should be done. We can't follow all marketing trends (Apple recently renamed iOS to iPadOS for the iPad; we can't keep adapting to such schemes). Personally, I like the new name without the "x", but we had already spent some time trying to find and fix all (or at least, most) instances of "osx" in the code, that I don't really think it's worth the effort. If you can drill up enough enthusiasm for such a project, and get any objections down to minimum, I can help implementing it. But I won't be spearheading it. > make/common/NativeCompilation.gmk line 1178: > >> 1176: endif >> 1177: # This only works if the openjdk_codesign identity is present on the system. Let >> 1178: # silently fail otherwise. > > Might want to add a comment here: > # The '-f' option will replace an existing signature if one exists. We're not really in the habit of adding comments for various command line options. Normally, you can check these with "man" if you are uncertain. If they do something surprising, sure, but here it's more of a "it's needed on aarch64 to work at all", so I don't think a comment will be anything but added clutter. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Fri Feb 5 09:51:52 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 5 Feb 2021 09:51:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 23:05:56 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > I reviewed bsd_aarch64.cpp digging bit deeper and left some comments. > > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. > > I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment. Got it, OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Fri Feb 5 10:00:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Feb 2021 10:00:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Fri Feb 5 10:00:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Feb 2021 10:00:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 09:49:11 GMT, Andrew Haley wrote: >> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments. > >> > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. >> >> I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment. > > Got it, OK. > This doesn't seem to be an issue anymore, After P.Race have finished with JDK-8257852, Macarm port can be build without extra ld flags. @VladimirKempik I agree. That concludes the build issues with this PR. So from a build perspective, this is now good to go. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coffeys at openjdk.java.net Fri Feb 5 10:18:41 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 5 Feb 2021 10:18:41 GMT Subject: RFR: 8257497: Key identifier compliance issue In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 23:06:30 GMT, Hai-May Chao wrote: > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From fguallini at openjdk.java.net Fri Feb 5 10:48:00 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 5 Feb 2021 10:48:00 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2] In-Reply-To: References: Message-ID: > The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: > sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java > javax/net/ssl/TLSCommon/TLSTest.java > sun/security/ssl/CipherSuite/SupportedGroups.java > > > javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8241372' of github.com:fguallini/jdk into 8241372 - remove not needed bug id from tests, run with preferIPv4Stack ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2405/files - new: https://git.openjdk.java.net/jdk/pull/2405/files/2a20a45d..779c3fbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=00-01 Stats: 9 lines in 4 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405 PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Fri Feb 5 10:48:02 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 5 Feb 2021 10:48:02 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 14:50:24 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch '8241372' of github.com:fguallini/jdk into 8241372 >> - remove not needed bug id from tests, run with preferIPv4Stack > > test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 29: > >> 27: /* >> 28: * @test >> 29: * @bug 4416068 4478803 4479736 8241372 > > Here and in the other tests: > If a fix is a test bug and only contains test changes, we usually don't add the bug id to the modified tests. Instead we add the label `noreg-self` to the JBS issue. The bug ids in the tests files are supposed to identify *source changes* that can be verified by running the test. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Fri Feb 5 10:51:42 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 5 Feb 2021 10:51:42 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 15:11:39 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch '8241372' of github.com:fguallini/jdk into 8241372 >> - remove not needed bug id from tests, run with preferIPv4Stack > > test/jdk/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java line 90: > >> 88: (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); >> 89: InetSocketAddress socketAddress = >> 90: new InetSocketAddress(InetAddress.getLoopbackAddress(), serverPort); > > The client is using 127.0.0.1. InetAddress.getLoopbackAddress() might return ::1 (IPv6 loopback) on certain configurations. > Two possibility: > 1. run this test with -Djava.net.preferIPv4Stack to force usage of IPv4, but trivially pass if IPv4 is not available on the machine (see IPSupport in the test library) > 2. use InetAddress.getLoopbackAddress().getHostAddress() on the client side instead of "127.0.0.1" > > If you choose 2. you may want to add an additional @run the test with -Djava.net.preferIPv6Address to verify that it works with IPv6 - as there are several ways to represent the IPv6 loopback as a string Applied the first suggestion since, it is using 127.0.0.1 for verification later in the test. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From dfuchs at openjdk.java.net Fri Feb 5 11:26:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 5 Feb 2021 11:26:44 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 10:48:00 GMT, Fernando Guallini wrote: >> The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: >> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java >> javax/net/ssl/TLSCommon/TLSTest.java >> sun/security/ssl/CipherSuite/SupportedGroups.java >> >> >> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. > > Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8241372' of github.com:fguallini/jdk into 8241372 > - remove not needed bug id from tests, run with preferIPv4Stack The new changes look goo to me. Please wait to get approval from someone from security-dev before pushing. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2405 From akozlov at openjdk.java.net Fri Feb 5 12:29:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 12:29:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 09:57:54 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > Marked as reviewed by ihse (Reviewer). > I haven't got a MacOS AArch64 system right now. Is it possible to > enable W^X in Linux in order to kick the tyres? I've just got rid of asserts that fired on Linux sometime :) As for W^X like on macOS, I vaguely remember working with a Linux system with one-way transition W->X, probably provided by SELinux. But I don't think it allowed per-thread W^X state. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 5 13:01:05 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 13:01:05 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v11] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Cleanup SA changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/80827176..8652d21d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=09-10 Stats: 11 lines in 1 file changed: 3 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 5 13:01:06 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 13:01:06 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:48:50 GMT, Chris Plummer wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702: > >> 700: primitiveArray = (*env)->GetLongArrayElements(env, registerArray, NULL); >> 701: >> 702: #undef REG_INDEX > > I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed since it seems to just get #define'd back to the same value. We've merged two implementations of SA, this change slipped in. I've cleaned this up. Thanks for noticing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From sean.mullan at oracle.com Fri Feb 5 14:03:04 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 Feb 2021 09:03:04 -0500 Subject: JSSE reference guide issue In-Reply-To: References: Message-ID: If you have a JBS account, you can file a bug in the docs/guides category. However, I have also forwarded your email to our internal docs engineer, so we will follow-up on it. Thanks, Sean On 2/5/21 2:42 AM, Daniel Jeli?ski wrote: > Hi all, > What's the right spot to report documentation issues? > > I've been reading the JSSE reference guide and noticed that in section > "Resuming Session Without Server-Side State" > (https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810) > it says "This feature is not enabled by default", which appears to be > a leftover from Java 13. > > Also the note about TLS 1.3 in the same section isn't entirely clear > to me. What does it mean when the docs say "the contents of stateless > tickets, in particular, the contents of a NewSessionTicket message, > depend on the value of jdk.tls.server.enableSessionTicketExtension"? > How exactly does the contents change and why should I care? > Regards, > Daniel > From sean.coffey at oracle.com Fri Feb 5 14:40:03 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Feb 2021 14:40:03 +0000 Subject: JSSE reference guide issue In-Reply-To: References: Message-ID: Another option for reporting is to use the https://bugreport.java.com portal. Component = documentation. regards, Sean. On 05/02/2021 14:03, Sean Mullan wrote: > If you have a JBS account, you can file a bug in the docs/guides > category. > > However, I have also forwarded your email to our internal docs > engineer, so we will follow-up on it. > > Thanks, > Sean > > On 2/5/21 2:42 AM, Daniel Jeli?ski wrote: >> Hi all, >> What's the right spot to report documentation issues? >> >> I've been reading the JSSE reference guide and noticed that in section >> "Resuming Session Without Server-Side State" >> (https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810) >> >> it says "This feature is not enabled by default", which appears to be >> a leftover from Java 13. >> >> Also the note about TLS 1.3 in the same section isn't entirely clear >> to me. What does it mean when the docs say "the contents of stateless >> tickets, in particular, the contents of a NewSessionTicket message, >> depend on the value of jdk.tls.server.enableSessionTicketExtension"? >> How exactly does the contents change and why should I care? >> Regards, >> Daniel >> From daniel.daugherty at oracle.com Fri Feb 5 15:05:25 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 5 Feb 2021 10:05:25 -0500 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <18c74331-6056-405f-1207-e62787f34830@oracle.com> On 2/5/21 4:51 AM, Magnus Ihse Bursie wrote: > On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote: > >>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> support macos_aarch64 in hsdis >> make/autoconf/flags.m4 line 140: >> >>> 138: else >>> 139: MACOSX_VERSION_MIN=10.12.0 >>> 140: fi >> Not something that needs to be addressed here, but these changes >> illustrate that our collective use of macOSX/MACOSX/MacOSX names >> are tied to the fact that the macOS major version number was at 10 >> for a very long time. >> >> @magicus - Do we have an RFE to rename MACOSX or are we sticking >> with it and evolving our interpretation of the 'X' from '10' to */splat/asterik? > @dcubed-ojdk There is no RFE to renaming "macosx" to "macos". I'm not sure it should be done. We can't follow all marketing trends (Apple recently renamed iOS to iPadOS for the iPad; we can't keep adapting to such schemes). Personally, I like the new name without the "x", but we had already spent some time trying to find and fix all (or at least, most) instances of "osx" in the code, that I don't really think it's worth the effort. > > If you can drill up enough enthusiasm for such a project, and get any objections down to minimum, I can help implementing it. But I won't be spearheading it. > >> make/common/NativeCompilation.gmk line 1178: >> >>> 1176: endif >>> 1177: # This only works if the openjdk_codesign identity is present on the system. Let >>> 1178: # silently fail otherwise. >> Might want to add a comment here: >> # The '-f' option will replace an existing signature if one exists. > We're not really in the habit of adding comments for various command line options. Normally, you can check these with "man" if you are uncertain. If they do something surprising, sure, but here it's more of a "it's needed on aarch64 to work at all", so I don't think a comment will be anything but added clutter. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 @magicus - I'm good with both of these answers. I personally like 'macosx'. Dan From gziemski at openjdk.java.net Fri Feb 5 15:47:52 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 5 Feb 2021 15:47:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <1WBui88c5lauE5a6N6u6iqV93EDULATd6jx-VTi7ctY=.4fc4b9e2-1e6d-4ff4-9693-27cdbb06e7ef@github.com> On Fri, 5 Feb 2021 12:26:27 GMT, Anton Kozlov wrote: >> Marked as reviewed by ihse (Reviewer). > >> I haven't got a MacOS AArch64 system right now. Is it possible to >> enable W^X in Linux in order to kick the tyres? > > I've just got rid of asserts that fired on Linux sometime :) As for W^X like on macOS, I vaguely remember working with a Linux system with one-way transition W->X, probably provided by SELinux. But I don't think it allowed per-thread W^X state. > _Mailing list message from [daniel.daugherty at oracle.com](mailto:daniel.daugherty at oracle.com) on [security-dev](mailto:security-dev at openjdk.java.net):_ > > On 2/5/21 4:51 AM, Magnus Ihse Bursie wrote: > > @magicus - I'm good with both of these answers. I personally like 'macosx'. > > Dan It's no longer `macosx`, it's just `macos` now - see https://en.wikipedia.org/wiki/MacOS ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 5 16:07:09 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 16:07:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Update signal handler part for debugger ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/8652d21d..0d0e9baf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=10-11 Stats: 16 lines in 1 file changed: 5 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 5 16:17:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 16:17:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 23:29:30 GMT, Gerard Ziemski wrote: >> using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks >> >> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64: >> https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524 >> and aarch64: >> https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323 >> (What happened with the formatting here, ugh?) >> >> Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that? > > So it should be: > > #if defined(__APPLE__) > // lldb (gdb) installs both standard BSD signal handlers, and mach exception > // handlers. By replacing the existing task exception handler, we disable lldb's mach > // exception handling, while leaving the standard BSD signal handlers functional. > // > // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking > // EXC_MASK_ARITHMETIC needed by all architectures for div by 0 checking > // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization > kern_return_t kr; > kr = task_set_exception_ports(mach_task_self(), > EXC_MASK_BAD_ACCESS | EXC_MASK_ARITHMETIC > AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION), > MACH_PORT_NULL, > EXCEPTION_STATE_IDENTITY, > MACHINE_THREAD_STATE); > > assert(kr == KERN_SUCCESS, "could not set mach task signal handler"); > #endif Thanks! I've updated the PR with this code, with extra indentation of `AARCH64_ONLY(...)` line, since this is continuation of the first parameter. I'll fix the formatting in os_bsd_arch64.cpp along other changes to `bsd_aarch64` directory ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From djelinski1 at gmail.com Fri Feb 5 16:31:07 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Fri, 5 Feb 2021 17:31:07 +0100 Subject: JSSE reference guide issue In-Reply-To: References: Message-ID: Thanks! I didn't think of checking the bug report page. Will keep it in mind. Regards, Daniel pt., 5 lut 2021 o 15:40 Se?n Coffey napisa?(a): > > Another option for reporting is to use the https://bugreport.java.com > portal. Component = documentation. > > regards, > Sean. > > On 05/02/2021 14:03, Sean Mullan wrote: > > If you have a JBS account, you can file a bug in the docs/guides > > category. > > > > However, I have also forwarded your email to our internal docs > > engineer, so we will follow-up on it. > > > > Thanks, > > Sean > > > > On 2/5/21 2:42 AM, Daniel Jeli?ski wrote: > >> Hi all, > >> What's the right spot to report documentation issues? > >> > >> I've been reading the JSSE reference guide and noticed that in section > >> "Resuming Session Without Server-Side State" > >> (https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810) > >> > >> it says "This feature is not enabled by default", which appears to be > >> a leftover from Java 13. > >> > >> Also the note about TLS 1.3 in the same section isn't entirely clear > >> to me. What does it mean when the docs say "the contents of stateless > >> tickets, in particular, the contents of a NewSessionTicket message, > >> depend on the value of jdk.tls.server.enableSessionTicketExtension"? > >> How exactly does the contents change and why should I care? > >> Regards, > >> Daniel > >> From valeriep at openjdk.java.net Fri Feb 5 16:37:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 5 Feb 2021 16:37:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v6] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 18:40:02 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > drbg > > only in patch2: > unchanged: src/java.base/share/classes/sun/security/provider/CtrDrbg.java line 507: > 505: System.arraycopy(out, 0, result, pos, len); > 506: Arrays.fill(out, (byte)0); > 507: } No need to handle encryption output? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From akozlov at openjdk.java.net Fri Feb 5 17:23:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 17:23:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:35:51 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93: > >> 91: CPU_MARVELL = 'V', >> 92: CPU_INTEL = 'i', >> 93: CPU_APPLE = 'a', > > The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined? They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rhalade at openjdk.java.net Fri Feb 5 17:49:44 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 5 Feb 2021 17:49:44 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 14:55:39 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch '8241372' of github.com:fguallini/jdk into 8241372 >> - remove not needed bug id from tests, run with preferIPv4Stack > > test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145: > >> 143: // The server side may have closed the socket. >> 144: System.out.println("Client SSLException:"); >> 145: ssle.printStackTrace(System.out); > > If security / TLS experts agree that this is OK, then it is OK for me. Not being an expert, I'd be concerned that catching plain SSLException might be too wide and that this might hide errors. In that case, and if the error is intermittent, one possibility could be to respin the test in case of SSLException (do client side and server side again) and fail if the second attempts fails too. You can use getCause() to examine reason for SSLException. ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From hchao at openjdk.java.net Fri Feb 5 19:49:41 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 5 Feb 2021 19:49:41 GMT Subject: RFR: 8257497: Key identifier compliance issue In-Reply-To: References: Message-ID: <5wZQxSpW9CWNf2d6JQpvjh09VldBi6l_OTjlNRRJq3M=.22c0c544-ef2c-4067-b9b1-58aaee8e2758@github.com> On Fri, 5 Feb 2021 10:16:14 GMT, Sean Coffey wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. > > Marked as reviewed by coffeys (Reviewer). @coffeys Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From fguallini at openjdk.java.net Fri Feb 5 20:48:56 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 5 Feb 2021 20:48:56 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3] In-Reply-To: References: Message-ID: > The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: > sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java > javax/net/ssl/TLSCommon/TLSTest.java > sun/security/ssl/CipherSuite/SupportedGroups.java > > > javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: narrow down connection reset handling ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2405/files - new: https://git.openjdk.java.net/jdk/pull/2405/files/779c3fbf..382a389a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=01-02 Stats: 23 lines in 1 file changed: 12 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405 PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Fri Feb 5 20:51:42 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 5 Feb 2021 20:51:42 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 17:45:45 GMT, Rajan Halade wrote: >> test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145: >> >>> 143: // The server side may have closed the socket. >>> 144: System.out.println("Client SSLException:"); >>> 145: ssle.printStackTrace(System.out); >> >> If security / TLS experts agree that this is OK, then it is OK for me. Not being an expert, I'd be concerned that catching plain SSLException might be too wide and that this might hide errors. In that case, and if the error is intermittent, one possibility could be to respin the test in case of SSLException (do client side and server side again) and fail if the second attempts fails too. > > You can use getCause() to examine reason for SSLException. Sure. Narrowed down SSLException handling by using getCause() in last commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From mullan at openjdk.java.net Fri Feb 5 21:56:45 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 5 Feb 2021 21:56:45 GMT Subject: RFR: 8257497: Key identifier compliance issue In-Reply-To: References: Message-ID: <_uJpv1_Jmg5nVUQh9Jr8K_F_l-htXHv-O51axatE8EI=.75055b2b-c4cb-48a5-a110-7b827601d10c@github.com> On Mon, 1 Feb 2021 23:06:30 GMT, Hai-May Chao wrote: > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. I think it would be useful to add a test that checks that `keytool` now creates the AKID from the issuing CA's SKID. `keytool -ext` should be able to create a certificate with your own AKID, but you need to specify the OID and a hex-encoded string for the value. Check with @wangweij but I think you can probably enhance an existing test. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From weijun at openjdk.java.net Fri Feb 5 22:35:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 5 Feb 2021 22:35:41 GMT Subject: RFR: 8257497: Key identifier compliance issue In-Reply-To: <_uJpv1_Jmg5nVUQh9Jr8K_F_l-htXHv-O51axatE8EI=.75055b2b-c4cb-48a5-a110-7b827601d10c@github.com> References: <_uJpv1_Jmg5nVUQh9Jr8K_F_l-htXHv-O51axatE8EI=.75055b2b-c4cb-48a5-a110-7b827601d10c@github.com> Message-ID: On Fri, 5 Feb 2021 21:54:19 GMT, Sean Mullan wrote: > I think it would be useful to add a test that checks that `keytool` now creates the AKID from the issuing CA's SKID. `keytool -ext` should be able to create a certificate with your own AKID, but you need to specify the OID and a hex-encoded string for the value. Check with @wangweij but I think you can probably enhance an existing test. Unfortunately, SKID and AKID are added after all other extensions, therefore it will overwrite any SKID or AKID you explicitly provided. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From weijun at openjdk.java.net Sat Feb 6 14:11:03 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 6 Feb 2021 14:11:03 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v7] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: TLS key generators ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/3a074f7d..b55c035d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=05-06 Stats: 42 lines in 6 files changed: 30 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Sat Feb 6 14:40:04 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 6 Feb 2021 14:40:04 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: materials ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/b55c035d..2241bf8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=06-07 Stats: 110 lines in 1 file changed: 48 ins; 31 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Sat Feb 6 17:10:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 6 Feb 2021 17:10:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v6] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 16:34:29 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> drbg >> >> only in patch2: >> unchanged: > > src/java.base/share/classes/sun/security/provider/CtrDrbg.java line 507: > >> 505: System.arraycopy(out, 0, result, pos, len); >> 506: Arrays.fill(out, (byte)0); >> 507: } > > No need to handle encryption output? `out` contains same bytes as the output, and the output is often directly used as key materials. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun.wang at oracle.com Sun Feb 7 03:42:23 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Sun, 7 Feb 2021 03:42:23 +0000 Subject: Module jdk.jartool should provide jarsigner tool In-Reply-To: <00c18610-5351-6b34-9583-fd555a275d25@oracle.com> References: <00c18610-5351-6b34-9583-fd555a275d25@oracle.com> Message-ID: <7DBC87D5-495C-44AE-AD41-0FF4CAD140CA@oracle.com> We considered this before but thought jarsigner has too many options, and the password prompt thing is certainly a pain. Also the verification part are all based on public APIs and only the signing part is worth investigating. Finally we produce the JarSigner API in the jdk.security.jarsigner package in the jdk.jartool module, and move most signing code in jarsigner there. It?s certainly much more programmer-friendly than the jarsigner tool. ?Max > On Feb 4, 2021, at 5:36 AM, Alan Bateman wrote: > > On 04/02/2021 07:38, Christian Stein wrote: >> Module jdk.jartoo already provides java.util.spi.ToolProvider with >> sun.tools.jar.JarToolProvider. [0] >> >> Is there a reason why it does provide a JarSignerToolProvider allowing >> `jarsigner` to be run in-process? Perhaps too many System.exit() calls >> in sun/security/tools/jarsigner/Main.java? >> >> > cc'ing security-dev as that is where the jarsigner tool is maintained. > > This may have come up in JDK 9 but I can't find any mails in the archives. Yes, it would need a bit of refactoring so that the System.exit is only called when invoked via the launcher/main method. There are also CLI options that prompt for a password that may not be suitable for programmatic use. I'm sure Max or others on security-dev will have more to say on this. > > -Alan From goetz.lindenmaier at sap.com Mon Feb 8 13:18:17 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Feb 2021 13:18:17 +0000 Subject: [11u] RFR: 8244683: A TSA server used by tests In-Reply-To: References: Message-ID: Hi Martin, Thanks for downporting this. Nice documentation of the changes! Looks good. Best regards, Goetz. From: Doerr, Martin Sent: Tuesday, February 2, 2021 9:28 PM To: security-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8244683: A TSA server used by tests Hi, JDK-8244683 is backported to 11.0.11-oracle. I'd like to backport it for parity. It doesn't apply cleanly. TimestampCheck.java: - The parts which get removed contain minor differences (see [1]) - Resolution: Take new version. TsaHandler.java and TsaSigner.java: - New code contains usages of KnownOIDs which don't exist in 11u. - Resolution: Translate them (see [2]) TsaSigner.java: - New code uses ObjectIdentifier.of - Resolution: Change back to "new ObjectIdentifier" according to [1] - Uses HexPrinter (for debug code) which doesn't exist in 11u. - Resolution: Use HexDumpEncoder instead: System.out.println(new HexDumpEncoder().encode(bytes)); An additional testfix is needed: https://bugs.openjdk.java.net/browse/JDK-8246709 which applies cleanly except that it needs an import change (see [3]). That change is not included in the webrev. I just want to push 11u backport of 8244683 together with 8246709 (including [3]) together. Bug: https://bugs.openjdk.java.net/browse/JDK-8244683 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/56bda3e6d148 11u backport: http://cr.openjdk.java.net/~mdoerr/8244683_TSA_11u/webrev.00/ Please review. Best regards, Martin [1] diff JDK11u:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java JDK16:TimestampCheck_before_8244683.java 65a66 > * 8242151 137c138 < ObjectIdentifier policyId = new ObjectIdentifier(defaultPolicyId); --- > ObjectIdentifier policyId = ObjectIdentifier.of(defaultPolicyId); 161c162 < policyId = new ObjectIdentifier(defaultPolicyId); --- > policyId = ObjectIdentifier.of(defaultPolicyId); 233c234 < ContentInfo contentInfo = new ContentInfo(new ObjectIdentifier( --- > ContentInfo contentInfo = new ContentInfo(ObjectIdentifier.of( [2] KnownOIDs Translation: https://github.com/openjdk/jdk/commit/080b3b83ebffe5149fbc9ac48e921fb51e9c3c63#diff-e6d5bd6b166be4737084473fcf55b0f101a710263c899c19b0df2a702c89a30e [3] diff JDK16:TSA_testfix_orig.patch resolved_JDK11u:8246709_TSA.patch < import jdk.test.lib.process.OutputAnalyzer; --- > import jdk.testlibrary.OutputAnalyzer; -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.java.net Mon Feb 8 14:06:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 8 Feb 2021 14:06:55 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes in Apache Santuario src/java.management/share/classes/javax/management/loading/MLet.java line 1147: > 1145: .toFile(); > 1146: file.deleteOnExit(); > 1147: Files.copy(is, file.toPath()); One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code). The code that follows checks if the file exists, this will always be true when Files.copy succeeds. src/java.base/share/classes/sun/net/www/MimeLauncher.java line 2: > 1: /* > 2: * Copyright (c) 1994, 2020, Oracle and/or its affiliates. All rights reserved. Is MimeEntry.launch still used? I'm wondering if the MimeLauncher can be deleted. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From weijun at openjdk.java.net Mon Feb 8 14:42:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 8 Feb 2021 14:42:44 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes in Apache Santuario The other security-related code changes look good to me. src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49: > 47: throws IOException > 48: { > 49: return is.readAllBytes(); This is also from Apache Santuario. It's better to keep it unchanged. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From jboes at openjdk.java.net Mon Feb 8 16:21:56 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 8 Feb 2021 16:21:56 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v7] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 08:19:08 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov 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. src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29: > 27: > 28: import java.io.ByteArrayInputStream; > 29: import java.io.IOException; The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From jboes at openjdk.java.net Mon Feb 8 16:42:42 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 8 Feb 2021 16:42:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 14:40:16 GMT, Weijun Wang wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > The other security-related code changes look good to me. I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:50:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:50:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 14:01:34 GMT, Alan Bateman wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > src/java.management/share/classes/javax/management/loading/MLet.java line 1147: > >> 1145: .toFile(); >> 1146: file.deleteOnExit(); >> 1147: Files.copy(is, file.toPath()); > > One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code). > > The code that follows checks if the file exists, this will always be true when Files.copy succeeds. fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:54:47 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:54:47 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v7] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 16:19:17 GMT, Julia Boes wrote: >> Andrey Turbanov 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. > > src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29: > >> 27: >> 28: import java.io.ByteArrayInputStream; >> 29: import java.io.IOException; > > The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable. done ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:54:48 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:54:48 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 14:38:52 GMT, Weijun Wang wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49: > >> 47: throws IOException >> 48: { >> 49: return is.readAllBytes(); > > This is also from Apache Santuario. It's better to keep it unchanged. reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:58:01 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:58:01 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo fix review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/94e99817..6a8a3ae6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07-08 Stats: 29 lines in 10 files changed: 16 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+471021+marschall at openjdk.java.net Mon Feb 8 21:21:44 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 8 Feb 2021 21:21:44 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > fix review comments src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230: > 228: // Copy the entire input stream into an InputStream that does > 229: // support mark > 230: is = new ByteArrayInputStream(is.readAllBytes()); I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do: PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From rhalade at openjdk.java.net Mon Feb 8 21:31:56 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 8 Feb 2021 21:31:56 GMT Subject: RFR: 8225081: Remove Telia Company CA certificate expiring in April 2021 Message-ID: Removed "Sonera Class2 CA" CA certificate from Telia Company that will expire in April 2021. Release Note: https://bugs.openjdk.java.net/browse/JDK-8261361 ------------- Commit messages: - 8225081: Remove Telia Company CA certificate expiring in April 2021 Changes: https://git.openjdk.java.net/jdk/pull/2464/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2464&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225081 Stats: 33 lines in 2 files changed: 0 ins; 30 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2464.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2464/head:pull/2464 PR: https://git.openjdk.java.net/jdk/pull/2464 From mullan at openjdk.java.net Mon Feb 8 22:00:57 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 8 Feb 2021 22:00:57 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures Message-ID: Please review this change to disable XML signatures that use SHA-1 based digest or signature algorithms. SHA-1 is weak and is not a recommended algorithm for digital signatures. This will improve out of the box security by restricting XML signatures that use SHA-1 algorithms. CSR: https://bugs.openjdk.java.net/browse/JDK-8261246 Release Note: https://bugs.openjdk.java.net/browse/JDK-8261364 ------------- Commit messages: - Remove extra whitespace. - Merge - Initial revision. Changes: https://git.openjdk.java.net/jdk/pull/2463/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2463&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259709 Stats: 55 lines in 5 files changed: 50 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2463.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2463/head:pull/2463 PR: https://git.openjdk.java.net/jdk/pull/2463 From rhalade at openjdk.java.net Tue Feb 9 00:51:41 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 9 Feb 2021 00:51:41 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 20:46:41 GMT, Sean Mullan wrote: > Please review this change to disable XML signatures that use SHA-1 based digest or signature algorithms. SHA-1 is weak and is not a recommended algorithm for digital signatures. This will improve out of the box security by restricting XML signatures that use SHA-1 algorithms. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8261246 > Release Note: https://bugs.openjdk.java.net/browse/JDK-8261364 Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2463 From github.com+30433125+djelinski at openjdk.java.net Tue Feb 9 08:46:44 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Tue, 9 Feb 2021 08:46:44 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> Message-ID: On Thu, 4 Feb 2021 20:45:55 GMT, djelinski wrote: >> Thank you for the comment. The big picture is more clear to me now. >> >>> Example 2: >>> Old implementation will get: >>> |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16| >>> >>> New implementation will get: >>> |K=5, exp=12|K=7, exp=14|K=1, exp=8(expired)|K=9, exp=16| >> >> K=3 is not expired yet, but get removed, while K=1 is kept. This behavior change may cause more overall performance hurt than improving the cache put/get performance. For example, it need to grab the value remotely. A full handshake or OCSP status grabbing could counteract all the performance gain with the cache update. >> >>> All calls to put() remove expired items from the front of the queue, and never perform a full scan. get() calls shuffle the queue, moving the accessed item to the back. Compare this to original code where put() only removed expired items when the cache overflowed, and scanned the entire cache. >> >> I think the idea that put() remove expired items from the front of the queue is good. I was wondering if it is an option to have the get() method that removed expired items until the 1st un-expired item, without scan the full queue and change the order of the queue. But there is still an issue that the SoftReference may have clear an item, which may be still valid. >> >> In general, I think the get() performance is more important than put() method, as get() is called more frequently. So we should try to keep the cache small if possible. >> >>>> increase the size to some big scales, like 2M and 20M >>> >>> Can do. Do you think it makes sense to also benchmark the scenario where GC kicks in and collects soft references? >> >> In the update, the SoftReference.clear() get removed. I'm not sure of the impact of the enqueued objects any longer. In theory, it could improve the memory use, which could counteract the performance gain in some situation. >> >>> Also, what do you think about the changes done in Do not invalidate objects before GC 5859a03 commit? >> >> See above, it is a concern to me that the soft reference cannot be cleared with this update. >> >>> How do I file a CSR? >> >> Could you edit the bug: https://bugs.openjdk.java.net/browse/JDK-8259886? In the more drop down menu, there is a "Create CSR" option. You can do it if we have an agreement about the solution and impact. > > Thanks for your review! Some comments below. >> A full handshake or OCSP status grabbing could counteract all the performance gain with the cache update. > > Yes, but that's unlikely. Note that K=3 is before K=1 in the queue only because 3 wasn't used since 1 was last used. This means that either K=3 is used less frequently than K=1, or that all cached items are in active use. In the former case we don't lose much by dropping K=3 (granted, there's nothing to offset that). In the latter we are dealing with full cache at all times, which means that most `put()`s would scan the queue, and we will gain a lot by finishing faster. >> get() [..] without [..] change the order of the queue > > If we do that, frequently used entries will be evicted at the same age as never used ones. This means we will have to recompute (full handshake/fresh OCSP) both the frequently used and the infrequently used entries. It's better to recompute only the infrequently used ones, and reuse the frequently used as long as possible - we will do less work that way. > That's probably the reason why a `LinkedHashMap` with `accessOrder=true` was chosen as the backing store implementation originally. >> get() performance is more important [..] so we should try to keep the cache small if possible > > I don't see the link; could you explain? >> In the update, the SoftReference.clear() get removed. I'm not sure of the impact of the enqueued objects any longer. In theory, it could improve the memory use, which could counteract the performance gain in some situation. > > That's the best part: no objects ever get enqueued! We only called `clear()` right before losing the last reference to `SoftCacheEntry` (which is the `SoftReference`). When GC collects the `SoftReference`, it does not enqueue anything. GC only enqueues the `SoftReference` when it collects the referenced object (session / OCSP response) without collecting the `SoftReference` (cache entry) itself. > This is [documented behavior](https://docs.oracle.com/javase/7/docs/api/java/lang/ref/package-summary.html): _If a registered reference becomes unreachable itself, then it will never be enqueued._ >> Could you edit the bug > > I'd need an account on the bug tracker first. So, how do we want to proceed here? Is the proposed solution acceptable? If not, what needs to change? if yes, what do I need to do next? ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From stefank at openjdk.java.net Tue Feb 9 09:34:38 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 9 Feb 2021 09:34:38 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: References: Message-ID: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Update signal handler part for debugger Thanks for cleaning out WXWriteFromExecSetter. src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 52: > 50: > 51: int BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) { > 52: // Enable WXWrite: the function is called direclty from nmethod_entry_barrier direclty -> directly src/hotspot/share/runtime/threadWXSetters.hpp line 28: > 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP > 27: > 28: #include "runtime/thread.inline.hpp" This breaks against our convention to forbid inline.hpp files from being included from being included from .hpp files. You need to rework this by either moving the implementation to a .cpp file, or convert this file into an .inline.hpp See the Source Files section in: https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html src/hotspot/share/runtime/thread.hpp line 848: > 846: void init_wx(); > 847: WXMode enable_wx(WXMode new_state); > 848: #endif // __APPLE__ && AARCH64 Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions. src/hotspot/share/runtime/thread.cpp line 2515: > 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) { > 2514: // Enable WXWrite: called directly from interpreter native wrapper. > 2515: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread)); FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version: ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) { MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {} void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp) With that said, I'm fine with taking this discussion as a follow-up. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+471021+marschall at openjdk.java.net Tue Feb 9 11:42:34 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 9 Feb 2021 11:42:34 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com> On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > fix review comments src/java.base/share/classes/java/util/jar/JarInputStream.java line 93: > 91: if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) { > 92: man = new Manifest(); > 93: byte[] bytes = new BufferedInputStream(this).readAllBytes(); I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7. In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From anders.rundgren.net at gmail.com Tue Feb 9 17:12:10 2021 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 9 Feb 2021 18:12:10 +0100 Subject: Keytool: PathLen:2147483647 In-Reply-To: References: Message-ID: <4179beeb-f03f-9855-6bed-567b47852596@gmail.com> Since the JDK bug report tool does not include "keytool" I posted this here. I believe I saw this a decade ago but it still looks like a bug, albeit a very minor one :) SEQUENCE { OBJECT IDENTIFIER basicConstraints (2.5.29.19) BOOLEAN true OCTET STRING, encapsulates { SEQUENCE { BOOLEAN true } } } I don't understand where 2147483647 come from... Shouldn't it rather be "PathLen:unconstrained"? keytool -printcert -v -file cacert.pem Github's cacert gives this result. -----BEGIN CERTIFICATE----- MIIDxTCCAq2gAwIBAgIQAqxcJmoLQJuPC3nyrkYldzANBgkqhkiG9w0BAQUFADBs MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j ZSBFViBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowbDEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTErMCkGA1UEAxMiRGlnaUNlcnQgSGlnaCBBc3N1cmFuY2Ug RVYgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbM5XPm +9S75S0tMqbf5YE/yc0lSbZxKsPVlDRnogocsF9ppkCxxLeyj9CYpKlBWTrT3JTW PNt0OKRKzE0lgvdKpVMSOO7zSW1xkX5jtqumX8OkhPhPYlG++MXs2ziS4wblCJEM xChBVfvLWokVfnHoNb9Ncgk9vjo4UFt3MRuNs8ckRZqnrG0AFFoEt7oT61EKmEFB Ik5lYYeBQVCmeVyJ3hlKV9Uu5l0cUyx+mM0aBhakaHPQNAQTXKFx01p8VdteZOE3 hzBWBOURtCmAEvF5OYiiAhF8J2a3iLd48soKqDirCmTCv2ZdlYTBoSUeh10aUAsg EsxBu24LUTi4S8sCAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFLE+w2kD+L9HAdSYJhoIAu9jZCvDMB8GA1UdIwQYMBaA FLE+w2kD+L9HAdSYJhoIAu9jZCvDMA0GCSqGSIb3DQEBBQUAA4IBAQAcGgaX3Nec nzyIZgYIVyHbIUf4KmeqvxgydkAQV8GK83rZEWWONfqe/EW1ntlMMUu4kehDLI6z eM7b41N5cdblIZQB2lWHmiRk9opmzN6cN82oNLFpmyPInngiK3BD41VHMWEZ71jF hS9OMPagMRYjyOfiZRYzy78aG6A9+MpeizGLYAiJLQwGXFK3xPkKmNEVX58Svnw2 Yzi9RKR/5CYrCsSXaQ3pjOLAEFe4yHYSkVXySGnYvCoCWw9E1CAx2/S6cCZdkGCe vEsXCS+0yx5DaMkHJ8HSXPfqIbloEpw8nL+e/IBcm2PN7EeqJSdnoDfzAIJ9VNep +OkuE6N36B9K -----END CERTIFICATE----- Anders From mullan at openjdk.java.net Tue Feb 9 17:41:38 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 9 Feb 2021 17:41:38 GMT Subject: RFR: 8225081: Remove Telia Company CA certificate expiring in April 2021 In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 21:26:21 GMT, Rajan Halade wrote: > Removed "Sonera Class2 CA" CA certificate from Telia Company that will expire in April 2021. > > Release Note: https://bugs.openjdk.java.net/browse/JDK-8261361 Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2464 From rhalade at openjdk.java.net Tue Feb 9 17:59:38 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 9 Feb 2021 17:59:38 GMT Subject: Integrated: 8225081: Remove Telia Company CA certificate expiring in April 2021 In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 21:26:21 GMT, Rajan Halade wrote: > Removed "Sonera Class2 CA" CA certificate from Telia Company that will expire in April 2021. > > Release Note: https://bugs.openjdk.java.net/browse/JDK-8261361 This pull request has now been integrated. Changeset: ef7ee3f4 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/ef7ee3f4 Stats: 33 lines in 2 files changed: 0 ins; 30 del; 3 mod 8225081: Remove Telia Company CA certificate expiring in April 2021 Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2464 From jamil.j.nimeh at oracle.com Tue Feb 9 18:36:30 2021 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 9 Feb 2021 10:36:30 -0800 Subject: RFR review of draft CSR JDK-8261456: KeyAgreement spec update on multi-party key exchange support Message-ID: <392b44b1-6fb3-c504-672e-cb5739458db9@oracle.com> Hello all, I'm looking for a review on a minor spec clarification for the KeyAgreement API.? This change adds an additional sentence to the existing introduction to the KeyAgreement spec allowing 3 or more party exchanges to be optional unless required by the underlying specification.? It makes no changes to the API which still supports an arbitrary number of participants. I did have difficulty finding an official, valid link to PKCS#3. I can find the spec from a few different sites, but they didn't look like the official source.? I've put RFC 2631 in there are a placeholder, but it describes the X9.42 variant.? I'll keep looking for the official PKCS#3 link, but if anyone knows it off-hand please throw it my way and I'll add it. Thanks, --Jamil https://bugs.openjdk.java.net/browse/JDK-8261456 From ascarpino at openjdk.java.net Tue Feb 9 19:59:54 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 9 Feb 2021 19:59:54 GMT Subject: RFR: 8261462: GCM ByteBuffer decryption problems Message-ID: Hi, I need a review of these two simple fixes. One just sets the input bytebuffer position to the limit upon completion of decryption. The second calls the CipherCore method to clear the state from the previous operation. Thanks Tony ------------- Commit messages: - Add test & revert error message - Fixes Changes: https://git.openjdk.java.net/jdk/pull/2487/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2487&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261462 Stats: 154 lines in 3 files changed: 152 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2487.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2487/head:pull/2487 PR: https://git.openjdk.java.net/jdk/pull/2487 From weijun.wang at oracle.com Tue Feb 9 20:58:12 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Tue, 9 Feb 2021 20:58:12 +0000 Subject: Keytool: PathLen:2147483647 In-Reply-To: <4179beeb-f03f-9855-6bed-567b47852596@gmail.com> References: <4179beeb-f03f-9855-6bed-567b47852596@gmail.com> Message-ID: <9A2A132E-DF6C-46AC-A41E-ED586D81FD28@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8261472 filed. Thanks, Max > On Feb 9, 2021, at 12:12 PM, Anders Rundgren wrote: > > Since the JDK bug report tool does not include "keytool" I posted this here. > I believe I saw this a decade ago but it still looks like a bug, albeit a very minor one :) > > SEQUENCE { > OBJECT IDENTIFIER basicConstraints (2.5.29.19) > BOOLEAN true > OCTET STRING, encapsulates { > SEQUENCE { > BOOLEAN true > } > } > } > > I don't understand where 2147483647 come from... > Shouldn't it rather be "PathLen:unconstrained"? > > keytool -printcert -v -file cacert.pem > > Github's cacert gives this result. > > -----BEGIN CERTIFICATE----- > MIIDxTCCAq2gAwIBAgIQAqxcJmoLQJuPC3nyrkYldzANBgkqhkiG9w0BAQUFADBs > MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 > d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j > ZSBFViBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowbDEL > MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 > LmRpZ2ljZXJ0LmNvbTErMCkGA1UEAxMiRGlnaUNlcnQgSGlnaCBBc3N1cmFuY2Ug > RVYgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbM5XPm > +9S75S0tMqbf5YE/yc0lSbZxKsPVlDRnogocsF9ppkCxxLeyj9CYpKlBWTrT3JTW > PNt0OKRKzE0lgvdKpVMSOO7zSW1xkX5jtqumX8OkhPhPYlG++MXs2ziS4wblCJEM > xChBVfvLWokVfnHoNb9Ncgk9vjo4UFt3MRuNs8ckRZqnrG0AFFoEt7oT61EKmEFB > Ik5lYYeBQVCmeVyJ3hlKV9Uu5l0cUyx+mM0aBhakaHPQNAQTXKFx01p8VdteZOE3 > hzBWBOURtCmAEvF5OYiiAhF8J2a3iLd48soKqDirCmTCv2ZdlYTBoSUeh10aUAsg > EsxBu24LUTi4S8sCAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF > MAMBAf8wHQYDVR0OBBYEFLE+w2kD+L9HAdSYJhoIAu9jZCvDMB8GA1UdIwQYMBaA > FLE+w2kD+L9HAdSYJhoIAu9jZCvDMA0GCSqGSIb3DQEBBQUAA4IBAQAcGgaX3Nec > nzyIZgYIVyHbIUf4KmeqvxgydkAQV8GK83rZEWWONfqe/EW1ntlMMUu4kehDLI6z > eM7b41N5cdblIZQB2lWHmiRk9opmzN6cN82oNLFpmyPInngiK3BD41VHMWEZ71jF > hS9OMPagMRYjyOfiZRYzy78aG6A9+MpeizGLYAiJLQwGXFK3xPkKmNEVX58Svnw2 > Yzi9RKR/5CYrCsSXaQ3pjOLAEFe4yHYSkVXySGnYvCoCWw9E1CAx2/S6cCZdkGCe > vEsXCS+0yx5DaMkHJ8HSXPfqIbloEpw8nL+e/IBcm2PN7EeqJSdnoDfzAIJ9VNep > +OkuE6N36B9K > -----END CERTIFICATE----- > > Anders From weijun at openjdk.java.net Tue Feb 9 21:06:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 9 Feb 2021 21:06:38 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 20:46:41 GMT, Sean Mullan wrote: > Please review this change to disable XML signatures that use SHA-1 based digest or signature algorithms. SHA-1 is weak and is not a recommended algorithm for digital signatures. This will improve out of the box security by restricting XML signatures that use SHA-1 algorithms. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8261246 > Release Note: https://bugs.openjdk.java.net/browse/JDK-8261364 Change looks good. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2463 From sean.mullan at oracle.com Tue Feb 9 21:07:54 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 9 Feb 2021 16:07:54 -0500 Subject: RFR review of draft CSR JDK-8261456: KeyAgreement spec update on multi-party key exchange support In-Reply-To: <392b44b1-6fb3-c504-672e-cb5739458db9@oracle.com> References: <392b44b1-6fb3-c504-672e-cb5739458db9@oracle.com> Message-ID: Looks good to me. --Sean On 2/9/21 1:36 PM, Jamil Nimeh wrote: > Hello all, > > I'm looking for a review on a minor spec clarification for the > KeyAgreement API.? This change adds an additional sentence to the > existing introduction to the KeyAgreement spec allowing 3 or more party > exchanges to be optional unless required by the underlying > specification.? It makes no changes to the API which still supports an > arbitrary number of participants. > > I did have difficulty finding an official, valid link to PKCS#3. I can > find the spec from a few different sites, but they didn't look like the > official source.? I've put RFC 2631 in there are a placeholder, but it > describes the X9.42 variant.? I'll keep looking for the official PKCS#3 > link, but if anyone knows it off-hand please throw it my way and I'll > add it. > > Thanks, > > --Jamil > > https://bugs.openjdk.java.net/browse/JDK-8261456 > > From xuelei at openjdk.java.net Wed Feb 10 00:47:38 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 10 Feb 2021 00:47:38 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> Message-ID: On Thu, 4 Feb 2021 20:45:55 GMT, djelinski wrote: > Thanks for your review! Some comments below. > > > A full handshake or OCSP status grabbing could counteract all the performance gain with the cache update. > > Yes, but that's unlikely. Note that K=3 is before K=1 in the queue only because 3 wasn't used since 1 was last used. This means that either K=3 is used less frequently than K=1, or that all cached items are in active use. In the former case we don't lose much by dropping K=3 (granted, there's nothing to offset that). In the latter we are dealing with full cache at all times, which means that most `put()`s would scan the queue, and we will gain a lot by finishing faster. I may think it differently. It may be hard to know the future frequency of an cached item based on the past behaviors. For the above case, I'm not sure that K=3 is used less frequently than K=1. Maybe, next few seconds, K=1 could be more frequently. I would like a solution to following the timeout specification: keep the newer items if possible. > > > get() [..] without [..] change the order of the queue > > If we do that, frequently used entries will be evicted at the same age as never used ones. This means we will have to recompute (full handshake/fresh OCSP) both the frequently used and the infrequently used entries. It's better to recompute only the infrequently used ones, and reuse the frequently used as long as possible - we will do less work that way. > That's probably the reason why a `LinkedHashMap` with `accessOrder=true` was chosen as the backing store implementation originally. > See above. It may be true for some case to determine the frequency, but Cache is a general class and we may want to be more careful about if we are really be able to determine the frequency within the Cache implementation. > > get() performance is more important [..] so we should try to keep the cache small if possible > > I don't see the link; could you explain? > link? Did you mean the link to get() method? It is a method in the Cache class. > > In the update, the SoftReference.clear() get removed. I'm not sure of the impact of the enqueued objects any longer. In theory, it could improve the memory use, which could counteract the performance gain in some situation. > > That's the best part: no objects ever get enqueued! We only called `clear()` right before losing the last reference to `SoftCacheEntry` (which is the `SoftReference`). When GC collects the `SoftReference`, it does not enqueue anything. GC only enqueues the `SoftReference` when it collects the referenced object (session / OCSP response) without collecting the `SoftReference` (cache entry) itself. > This is [documented behavior](https://docs.oracle.com/javase/7/docs/api/java/lang/ref/package-summary.html): _If a registered reference becomes unreachable itself, then it will never be enqueued._ > I need more time for this section. > > Could you edit the bug > > I'd need an account on the bug tracker first. Okay. No worries, I will help you if we could get an agreement about the update. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From xuelei at openjdk.java.net Wed Feb 10 00:51:39 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 10 Feb 2021 00:51:39 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> Message-ID: On Tue, 9 Feb 2021 08:44:28 GMT, djelinski wrote: > So, how do we want to proceed here? Is the proposed solution acceptable? If not, what needs to change? if yes, what do I need to do next? For me, it is a pretty good solution, but I have some concerns. I appreciate if you would like to read my comment and see if we could have an agreement. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From weijun at openjdk.java.net Wed Feb 10 01:29:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 10 Feb 2021 01:29:43 GMT Subject: RFR: 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur Message-ID: <9-DfPaZic-YwrYzGqTup_SUnPc7H9TEVWx17PIfUUPI=.e81e227e-7b79-489f-be1e-b173820056a4@github.com> Accept macOS 11.x as well. No new regression test. This can be approved by running the existing test test/sun/security/krb5/config/native/TestDynamicStore.java on Big Sur. ------------- Commit messages: - 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur Changes: https://git.openjdk.java.net/jdk/pull/2492/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261481 Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2492/head:pull/2492 PR: https://git.openjdk.java.net/jdk/pull/2492 From weijun at openjdk.java.net Wed Feb 10 01:43:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 10 Feb 2021 01:43:54 GMT Subject: RFR: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint Message-ID: Print out "no limit" instead. This is the words RFC 5280 uses: "Where pathLenConstraint does not appear, no limit is imposed". No regression test. Trivial. ------------- Commit messages: - 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint Changes: https://git.openjdk.java.net/jdk/pull/2493/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2493&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261472 Stats: 11 lines in 1 file changed: 8 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2493.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2493/head:pull/2493 PR: https://git.openjdk.java.net/jdk/pull/2493 From jnimeh at openjdk.java.net Wed Feb 10 01:54:43 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Wed, 10 Feb 2021 01:54:43 GMT Subject: RFR: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 01:39:15 GMT, Weijun Wang wrote: > Print out "no limit" instead. This is the words RFC 5280 uses: "Where pathLenConstraint does not appear, no limit is imposed". > > No regression test. Trivial. Looks fine to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2493 From weijun at openjdk.java.net Wed Feb 10 02:02:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 10 Feb 2021 02:02:38 GMT Subject: Integrated: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 01:39:15 GMT, Weijun Wang wrote: > Print out "no limit" instead. This is the words RFC 5280 uses: "Where pathLenConstraint does not appear, no limit is imposed". > > No regression test. Trivial. This pull request has now been integrated. Changeset: 4619f372 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/4619f372 Stats: 11 lines in 1 file changed: 8 ins; 1 del; 2 mod 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint Reviewed-by: jnimeh ------------- PR: https://git.openjdk.java.net/jdk/pull/2493 From mstjohns at comcast.net Wed Feb 10 05:53:38 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 10 Feb 2021 00:53:38 -0500 Subject: Integrated: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint In-Reply-To: References: Message-ID: <6ec9012a-b2be-0c0d-5231-03c6ced0bfe7@comcast.net> On 2/9/2021 9:02 PM, Weijun Wang wrote: > On Wed, 10 Feb 2021 01:39:15 GMT, Weijun Wang wrote: > >> Print out "no limit" instead. This is the words RFC 5280 uses: "Where pathLenConstraint does not appear, no limit is imposed". >> >> No regression test. Trivial. > This pull request has now been integrated. > > Changeset: 4619f372 > Author: Weijun Wang > URL: https://git.openjdk.java.net/jdk/commit/4619f372 > Stats: 11 lines in 1 file changed: 8 ins; 1 del; 2 mod > > 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint > > Reviewed-by: jnimeh > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2493 Sorry - not quite right, it's not quite that trivial a fix. The definition for BasicConstraints is > BasicConstraints ::= SEQUENCE { > cA BOOLEAN DEFAULT FALSE, > pathLenConstraint INTEGER (0..MAX) OPTIONAL } If pathLenConstraint is not present, then the path length is infinite.?? The flag value for that looks like it was encoded as both any negative number (and set to -1 to start) and Integer.MAX_VALUE.? I'm not quite sure why it was done that way, but there's a problem doing that - actually a bunch of them. You really ought to get the same encoding coming and going (e.g. creating an object from DER should encode back to the exact same DER).? The current code does not do that. 1) It's not valid to encode or decode pathLenConstraint in the DER as a negative number.?? This isn't a problem for encoding, but the BasicConstraintsException(Boolean critical, Object value) needs a value check after line 157 to make sure that the decoded pathLengthConstraint field is positive - i'd throw an IOException on failure.??? I'd also change line 149 to just return - the initial value of pathLen is -1 and that's an appropriate flag for a missing field. 2) I'm not sure why the set/get methods were added.? I think it was to provide access for the PathValidation stuff? Given that they are present, I'd insert a line after line 222 (set) : "if (pathLen < 0) pathLen = -1;" // treat any negative value as unconstrained path length 3) And since the only place pathLen is available externally is in the get method, I'd change line 237 to "return (pathLen < 0) ? Integer.MAX_VALUE : Integer.valueOf(pathLen);"?? I think this is more correct than returning -1. 4) And to fix the problem that led to this discussion, change line 176 to 'pathLenAsString = " unconstrained"' and delete lines 177-178.? E.g. there's no such thing as undefined here - both a negative number and MAX_VALUE mean unconstrained length in the previous version of the code. 5) One more - in the other constructor, change line 108 to "this.pathLen = (len < 0 || len == Integer.MAX_VALUE) ? -1 : len;" 6) *sigh* Delete lines 197-201.? I have no idea why they are overriding the specified value of critical based on whether ca is true or not, but it's wrong.??? Conversely, the call to the constructor at line 95 is correct. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.java.net Wed Feb 10 12:26:38 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 10 Feb 2021 12:26:38 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3] In-Reply-To: References: Message-ID: <15CFhSSlCaeuuHOeZH8erI7GCWCNy3WTac7hzbVWMhQ=.d32e1c8c-e283-490f-933c-b0c80c80a447@github.com> On Fri, 5 Feb 2021 20:48:56 GMT, Fernando Guallini wrote: >> The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: >> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java >> javax/net/ssl/TLSCommon/TLSTest.java >> sun/security/ssl/CipherSuite/SupportedGroups.java >> >> >> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > narrow down connection reset handling test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 142: > 140: if ("Connection reset".equals(ssle.getCause().getMessage())) { > 141: System.out.println("Client SSLException:"); > 142: ssle.printStackTrace(System.out); An SSLException doesn't necessarily have a nested `cause` - so you could get a NPE here. I would suggest moving that code to a `private boolean isConnectionReset(SSLException ssle)` method, and possibly checking the type of the `cause` exception as well. I'm guessing it should be a `SocketException`? If you check the type then it will also exclude the case were the cause is null and avoid the NPE. Additional note: as a general rule, relying on exception message is fragile. But since we don't have a specific subtype for "Connection reset" it's probably the best we can do. ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From github.com+7693005+jarviscraft at openjdk.java.net Wed Feb 10 14:10:39 2021 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Wed, 10 Feb 2021 14:10:39 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Thu, 7 Jan 2021 17:09:14 GMT, Claes Redestad wrote: >> Hi Claes, >> Would flattening the state of MD5 bring any further improvements? >> https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083 > >> Hi Claes, >> Would flattening the state of MD5 bring any further improvements? >> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) > > I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > > > @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From redestad at openjdk.java.net Wed Feb 10 14:47:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 10 Feb 2021 14:47:39 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > >> >> >> @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! FWIW, I ended up doing two related improvements: - #1855 - which reduced overheads of constructing MD5, SHA1, SHA2, SHA5 `MessageDigest` objects, and slightly improving digest performance - #1933 - reducing cost of `MessageDigest.getInstance` in general by better internal caching of `Constructor` objects, among other things. With this there's now no extra allocations when looking up something that has been looked up before. Together these enhancements bring the overheads of `UUID.nameUUIDFromBytes` down close to what you can get from cloning from a `ThreadLocal` `MD5` object as suggested here. Taking the ambient overheads of `ThreadLocal`s into account I'd say it's not worth adding this cache, and would suggest withdrawing this PR and closing the RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From weijun at openjdk.java.net Wed Feb 10 14:47:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 10 Feb 2021 14:47:40 GMT Subject: RFR: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 01:52:21 GMT, Jamil Nimeh wrote: >> Print out "no limit" instead. This is the words RFC 5280 uses: "Where pathLenConstraint does not appear, no limit is imposed". >> >> No regression test. Trivial. > > Looks fine to me. > Sorry - not quite right, it's not quite that trivial a fix. Thanks for all the points. I've filed https://bugs.openjdk.java.net/browse/JDK-8261513, which will be non-trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/2493 From mbalao at openjdk.java.net Wed Feb 10 15:10:50 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 10 Feb 2021 15:10:50 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Message-ID: Hi, I'd like to propose a fix for JDK-8261355 [1]. The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. No regressions observed in jdk/sun/security/pkcs11. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 ------------- Commit messages: - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Changes: https://git.openjdk.java.net/jdk/pull/2510/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2510&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261355 Stats: 180 lines in 2 files changed: 105 ins; 27 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/2510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2510/head:pull/2510 PR: https://git.openjdk.java.net/jdk/pull/2510 From chegar at openjdk.java.net Wed Feb 10 15:53:54 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 10 Feb 2021 15:53:54 GMT Subject: RFR: 8261160: Add a deserialization JFR event Message-ID: This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. ------------- Commit messages: - minor cleanup; all tests passing - Unconditionally fire a deser event regardless of filter, and add test - commit 2 - commit 1 Changes: https://git.openjdk.java.net/jdk/pull/2479/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261160 Stats: 516 lines in 12 files changed: 496 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Wed Feb 10 16:09:42 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 10 Feb 2021 16:09:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. The logging in ObjectInputStream remains conditional on whether a filter is installed, which that seems reasonable since the logging is filter specific, while the JRF event is not (but both carry effectively the same information). The new jdk.Deserialization event uses a String to carry the filterStatus value. The value could be represented by its enum ordinal, but then the tool consuming the event would need to map that back to its string value to be meaningful. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From coffeys at openjdk.java.net Wed Feb 10 16:16:40 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 10 Feb 2021 16:16:40 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Marked as reviewed by coffeys (Reviewer). test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java line 50: > 48: * -Dexpected-jdk.serialFilter=java.** GlobalFilterTest > 49: * @run testng/othervm/policy=security.policy GlobalFilterTest > 50: * @run testng/othervm/policy=security.policy You may want to add a "@requires vm.hasJFR" condition to this test ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From jnimeh at openjdk.java.net Wed Feb 10 16:38:45 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Wed, 10 Feb 2021 16:38:45 GMT Subject: RFR: 8248223: KeyAgreement spec update on multi-party key exchange support Message-ID: This is a spec-only change that clarifies the requirement on KeyAgreement implementations for multi-party support where there are 3 or more parties involved. This change states that 3+ party support is implementation-specific unless the underlying specification for that algorithm requires support for 3 or more parties. Bug: https://bugs.openjdk.java.net/browse/JDK-8248223 CSR: https://bugs.openjdk.java.net/browse/JDK-8261456 ------------- Commit messages: - 8248223: KeyAgreement spec update on multi-party key exchange support Changes: https://git.openjdk.java.net/jdk/pull/2512/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2512&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248223 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2512/head:pull/2512 PR: https://git.openjdk.java.net/jdk/pull/2512 From xuelei at openjdk.java.net Wed Feb 10 16:51:37 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 10 Feb 2021 16:51:37 GMT Subject: RFR: 8248223: KeyAgreement spec update on multi-party key exchange support In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 16:33:54 GMT, Jamil Nimeh wrote: > This is a spec-only change that clarifies the requirement on KeyAgreement implementations for multi-party support where there are 3 or more parties involved. This change states that 3+ party support is implementation-specific unless the underlying specification for that algorithm requires support for 3 or more parties. > Bug: https://bugs.openjdk.java.net/browse/JDK-8248223 > CSR: https://bugs.openjdk.java.net/browse/JDK-8261456 Don't you want to add a "/csr" label? ------------- PR: https://git.openjdk.java.net/jdk/pull/2512 From github.com+30433125+djelinski at openjdk.java.net Wed Feb 10 19:22:36 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Wed, 10 Feb 2021 19:22:36 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> Message-ID: On Wed, 10 Feb 2021 00:44:57 GMT, Xue-Lei Andrew Fan wrote: > I may think it differently. It may be hard to know the future frequency of an cached item based on the past behaviors. For the above case, I'm not sure that K=3 is used less frequently than K=1. Maybe, next few seconds, K=1 could be more frequently. I agree that such prediction might not be 100% accurate. But, quick google search reveals that there are [many](https://www.usenix.org/system/files/hotstorage20_paper_eytan.pdf) [articles](https://link.springer.com/article/10.1007/PL00009255) that claim that LRU caches offer better hit rates than FIFO, especially for in-memory caches. > I would like a solution to following the timeout specification: keep the newer items if possible. That's a trivial change; all we need to do is change `true` to `false` [here](https://github.com/openjdk/jdk/blob/abe0e238bd25adb1ddd2b655613899bfa063cd85/src/java.base/share/classes/sun/security/util/Cache.java#L268). But, as stated above, LRU is better than FIFO, so I wouldn't want to do that. I could keep LRU and add another linked list that would store items in the order of their expiration dates; then we could quickly scan that list for expired items. Note: the order of expiration dates is not necessarily the order of insertion, because 1) `System.currentTimeMillis()` is not monotonic - it can move back when something changes the system time, 2) the expiration date is calculated at insertion time, so if someone changes the timeout on a non-empty cache, new items may have shorter expiration time than old ones. So, I'd either need to address that first (change `currentTimeMillis` to `nanoTime` and store creation time instead of expiration time), or use insertion sort for adding items (which would get very slow if either of the above mentioned situations happened). Let me know your thoughts. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From rriggs at openjdk.java.net Wed Feb 10 20:32:43 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 10 Feb 2021 20:32:43 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From dfuchs at openjdk.java.net Wed Feb 10 21:00:41 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 10 Feb 2021 21:00:41 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 35: > 33: > 34: @Category({"Java Development Kit", "Serialization"}) > 35: @Label("Deserialization events") This seems to differ from the format of other event labels defined in this package, e.g: @Label("Process Start") @Label("File Read") ... What would you think of changing it to one of: @Label("Deserialization") @Label("Deserialized Object") ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From hchao at openjdk.java.net Wed Feb 10 21:52:01 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 10 Feb 2021 21:52:01 GMT Subject: RFR: 8257497: Key identifier compliance issue [v2] In-Reply-To: References: Message-ID: <71P3cmsTvgjxiCW6Xf4rgCDNLb6WMRgGZrkmppx022I=.3d57405d-cdc7-473c-a1f8-850d03a3e8f4@github.com> > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Test case added and not overriding -ext fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2343/files - new: https://git.openjdk.java.net/jdk/pull/2343/files/88cae5cc..567c2004 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=00-01 Stats: 111 lines in 2 files changed: 92 ins; 19 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2343/head:pull/2343 PR: https://git.openjdk.java.net/jdk/pull/2343 From weijun at openjdk.java.net Wed Feb 10 22:44:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 10 Feb 2021 22:44:39 GMT Subject: RFR: 8257497: Key identifier compliance issue [v2] In-Reply-To: <71P3cmsTvgjxiCW6Xf4rgCDNLb6WMRgGZrkmppx022I=.3d57405d-cdc7-473c-a1f8-850d03a3e8f4@github.com> References: <71P3cmsTvgjxiCW6Xf4rgCDNLb6WMRgGZrkmppx022I=.3d57405d-cdc7-473c-a1f8-850d03a3e8f4@github.com> Message-ID: <6vM9zNzPTLmkO11I_9v5MVHK87Bph7fvi9KbFNs-oys=.fa468a98-7f9c-4834-9ff6-c9610f521ee2@github.com> On Wed, 10 Feb 2021 21:52:01 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Test case added and not overriding -ext fix test/jdk/sun/security/tools/keytool/CheckCertAKID.java line 69: > 67: .shouldContain("0000: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15") > 68: .shouldContain("0010: 16 17 18 19") > 69: .shouldHaveExitValue(0); Or you can directly read the certificate and look at its extensions using some API. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From hchao at openjdk.java.net Wed Feb 10 23:10:41 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 10 Feb 2021 23:10:41 GMT Subject: RFR: 8257497: Key identifier compliance issue [v2] In-Reply-To: <6vM9zNzPTLmkO11I_9v5MVHK87Bph7fvi9KbFNs-oys=.fa468a98-7f9c-4834-9ff6-c9610f521ee2@github.com> References: <71P3cmsTvgjxiCW6Xf4rgCDNLb6WMRgGZrkmppx022I=.3d57405d-cdc7-473c-a1f8-850d03a3e8f4@github.com> <6vM9zNzPTLmkO11I_9v5MVHK87Bph7fvi9KbFNs-oys=.fa468a98-7f9c-4834-9ff6-c9610f521ee2@github.com> Message-ID: <33QBq6C78hM0GILTx7FLH8PgXLnjROzVmkS0WkBi-zk=.b292f1d7-c6ef-4805-b087-da4465b86f54@github.com> On Wed, 10 Feb 2021 22:41:26 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Test case added and not overriding -ext fix > > test/jdk/sun/security/tools/keytool/CheckCertAKID.java line 69: > >> 67: .shouldContain("0000: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15") >> 68: .shouldContain("0010: 16 17 18 19") >> 69: .shouldHaveExitValue(0); > > Or you can directly read the certificate and look at its extensions using some API. The current method serves the need to verify the accuracy of the AKID for this PR, and it looks straightforward to perceive I think. The API such as cert.getExtensionValue(KnownOIDs.AuthorityKeyID.value()), and new DerValue to getOctetString() could also be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From weijun at openjdk.java.net Wed Feb 10 23:28:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 10 Feb 2021 23:28:39 GMT Subject: RFR: 8257497: Key identifier compliance issue [v2] In-Reply-To: <33QBq6C78hM0GILTx7FLH8PgXLnjROzVmkS0WkBi-zk=.b292f1d7-c6ef-4805-b087-da4465b86f54@github.com> References: <71P3cmsTvgjxiCW6Xf4rgCDNLb6WMRgGZrkmppx022I=.3d57405d-cdc7-473c-a1f8-850d03a3e8f4@github.com> <6vM9zNzPTLmkO11I_9v5MVHK87Bph7fvi9KbFNs-oys=.fa468a98-7f9c-4834-9ff6-c9610f521ee2@github.com> <33QBq6C78hM0GILTx7FLH8PgXLnjROzVmkS0WkBi-zk=.b292f1d7-c6ef-4805-b087-da4465b86f54@github.com> Message-ID: On Wed, 10 Feb 2021 23:07:51 GMT, Hai-May Chao wrote: >> test/jdk/sun/security/tools/keytool/CheckCertAKID.java line 69: >> >>> 67: .shouldContain("0000: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15") >>> 68: .shouldContain("0010: 16 17 18 19") >>> 69: .shouldHaveExitValue(0); >> >> Or you can directly read the certificate and look at its extensions using some API. > > The current method serves the need to verify the accuracy of the AKID for this PR, and it looks straightforward to perceive I think. The API such as cert.getExtensionValue(KnownOIDs.AuthorityKeyID.value()), and new DerValue to getOctetString() could also be used. The 3 `shouldContain` lines cannot prove they appear in that order. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From clanger at openjdk.java.net Wed Feb 10 23:33:45 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 10 Feb 2021 23:33:45 GMT Subject: RFR: 8261534: Test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java fails on platforms where no nsslib artifacts are defined Message-ID: <7r1bBHy5TWz4xlHX0TX_YeeS6DQVmeM9rFKrit18fsI=.6d7c49c1-d6e3-42d8-afda-b1c0546d2611@github.com> Fix exception in test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java: java.security.AccessControlException: access denied ("java.security.SecurityPermission" "removeProvider.SUN") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) at java.base/java.lang.SecurityManager.checkSecurityAccess(SecurityManager.java:1521) at java.base/java.security.Security.check(Security.java:832) at java.base/java.security.Security.removeProvider(Security.java:444) at IllegalPackageAccess.main(IllegalPackageAccess.java:81) at PKCS11Test.premain(PKCS11Test.java:171) at PKCS11Test.testNSS(PKCS11Test.java:568) at PKCS11Test.main(PKCS11Test.java:207) at IllegalPackageAccess.main(IllegalPackageAccess.java:69) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Root cause is that the test materializes and installs a policy by [obtaining the current policy](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L46). At the time it [tries to remove a provider](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L80), the materialized policy is used for an access check, due to some intricacies of the [java.security.Policy implementation](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/src/java.base/share/classes/java/security/Policy.java#L293). This policy does not allow the removal of a provider. On platforms where the test runs through [PKCS11Test::fetchNssLib](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/PKCS11Test.java#L859), the default policy is reset which makes the test work. But if we don't pass there, the test fails. The fix is to unconditionally call Policy.setPolicy(null); in IllegalPackageAccess before installing MyPolicy. ------------- Commit messages: - JDK-8261534 Changes: https://git.openjdk.java.net/jdk/pull/2518/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2518&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261534 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2518/head:pull/2518 PR: https://git.openjdk.java.net/jdk/pull/2518 From jjiang at openjdk.java.net Thu Feb 11 00:15:50 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 11 Feb 2021 00:15:50 GMT Subject: RFR: JDK-8261510: Use RFC numbers rather than protocol or draft names in sun.security.ssl.SSLExtension Message-ID: This is a simple cleanup for sun.security.ssl.SSLExtension. It converts protocol or draft names to RFC numbers correspondingly. It also removes a trailing space in extension token_binding, and move signature_algorithms_cert to RFC 8446 extension group. ------------- Commit messages: - JDK-8261510 Changes: https://git.openjdk.java.net/jdk/pull/2517/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2517&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261510 Stats: 46 lines in 1 file changed: 19 ins; 22 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2517.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2517/head:pull/2517 PR: https://git.openjdk.java.net/jdk/pull/2517 From hchao at openjdk.java.net Thu Feb 11 01:01:56 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 11 Feb 2021 01:01:56 GMT Subject: RFR: 8257497: Key identifier compliance issue [v3] In-Reply-To: References: Message-ID: > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: API used to get AKID ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2343/files - new: https://git.openjdk.java.net/jdk/pull/2343/files/567c2004..2f5199ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=01-02 Stats: 36 lines in 1 file changed: 30 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2343/head:pull/2343 PR: https://git.openjdk.java.net/jdk/pull/2343 From hchao at openjdk.java.net Thu Feb 11 01:13:38 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 11 Feb 2021 01:13:38 GMT Subject: RFR: 8257497: Key identifier compliance issue [v2] In-Reply-To: References: <71P3cmsTvgjxiCW6Xf4rgCDNLb6WMRgGZrkmppx022I=.3d57405d-cdc7-473c-a1f8-850d03a3e8f4@github.com> <6vM9zNzPTLmkO11I_9v5MVHK87Bph7fvi9KbFNs-oys=.fa468a98-7f9c-4834-9ff6-c9610f521ee2@github.com> <33QBq6C78hM0GILTx7FLH8PgXLnjROzVmkS0WkBi-zk=.b292f1d7-c6ef-4805-b087-da4465b86f54@github.com> Message-ID: On Wed, 10 Feb 2021 23:25:45 GMT, Weijun Wang wrote: >> The current method serves the need to verify the accuracy of the AKID for this PR, and it looks straightforward to perceive I think. The API such as cert.getExtensionValue(KnownOIDs.AuthorityKeyID.value()), and new DerValue to getOctetString() could also be used. > > The 3 `shouldContain` lines cannot prove they appear in that order. These lines are from the output of the keytool -printcert command. If there may be a problem with the ordering, it would be worth the effort to look into -printcert. I've changed to use APIs to ease the ordering concern. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From xuelei at openjdk.java.net Thu Feb 11 01:17:40 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 11 Feb 2021 01:17:40 GMT Subject: RFR: JDK-8261510: Use RFC numbers rather than protocol or draft names in sun.security.ssl.SSLExtension In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 21:22:03 GMT, John Jiang wrote: > This is a simple cleanup for sun.security.ssl.SSLExtension. > It converts protocol or draft names to RFC numbers correspondingly. > It also removes a trailing space in extension token_binding, and move signature_algorithms_cert to RFC 8446 extension group. src/java.base/share/classes/sun/security/ssl/SSLExtension.java line 482: > 480: RenegoInfoExtension.rniStringizer), > 481: > 482: // RFC 8446 PSK extension must be last What do you think if using "TLS 1.3 (RFC 8446)"? ------------- PR: https://git.openjdk.java.net/jdk/pull/2517 From jjiang at openjdk.java.net Thu Feb 11 01:54:53 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 11 Feb 2021 01:54:53 GMT Subject: RFR: JDK-8261510: Use RFC numbers rather than protocol or draft names in sun.security.ssl.SSLExtension [v2] In-Reply-To: References: Message-ID: > This is a simple cleanup for sun.security.ssl.SSLExtension. > It converts protocol or draft names to RFC numbers correspondingly. > It also removes a trailing space in extension token_binding, and move signature_algorithms_cert to RFC 8446 extension group. John Jiang has updated the pull request incrementally with one additional commit since the last revision: Addressed Xuelei's comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2517/files - new: https://git.openjdk.java.net/jdk/pull/2517/files/7209b2b7..84f131c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2517&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2517&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2517.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2517/head:pull/2517 PR: https://git.openjdk.java.net/jdk/pull/2517 From wetmore at openjdk.java.net Thu Feb 11 02:40:41 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 11 Feb 2021 02:40:41 GMT Subject: RFR: JDK-8261510: Use RFC numbers rather than protocol or draft names in sun.security.ssl.SSLExtension [v2] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 01:54:53 GMT, John Jiang wrote: >> This is a simple cleanup for sun.security.ssl.SSLExtension. >> It converts protocol or draft names to RFC numbers correspondingly. >> It also removes a trailing space in extension token_binding, and move signature_algorithms_cert to RFC 8446 extension group. > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > Addressed Xuelei's comment I agree with previous suggestion, but could you do throughout the file? Having something like either: // extension defined in RFC 7301 (ALPN) // extension defined in ALPN (RFC 7301) throughout this file is encouraged and appreciated. Having the RFC #/short name of the document would be a lot more readable, rather than having to look up the RFC for a synopsis. e.g. // extensions defined in RFC 8472 -> // extensions defined in Token Binding Protocol Negotiation (RFC 8472) or // extensions defined in RFC 8472 (Token Binding Protocol Negotiation) I noticed the previous comment for TLS1.3 wasn't fully addressed (line 314). ------------- PR: https://git.openjdk.java.net/jdk/pull/2517 From egahlin at openjdk.java.net Thu Feb 11 07:02:41 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 11 Feb 2021 07:02:41 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. src/java.base/share/classes/java/io/ObjectInputStream.java line 1366: > 1364: DeserializationEvent event = new DeserializationEvent(); > 1365: if (event.shouldCommit()) { > 1366: event.filterStatus = status == null ? "n/a" : status.name(); We use null for missing value, so no need to have "n/a" src/java.base/share/classes/java/io/ObjectInputStream.java line 1372: > 1370: event.depth = depth; > 1371: event.bytesRead = bytesRead; > 1372: event.exception = Objects.toString(ex, "n/a"); You may want to change the name of the field to "exceptionMessage" to make it clear it's the message, not the class. src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 45: > 43: > 44: @Label ("Class") > 45: public String clazz; We typically use "type" when referring to a class. src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 45: > 43: > 44: @Label ("Class") > 45: public String clazz; Is it possible to make the field of type Class? src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 51: > 49: > 50: @Label ("Reference count") > 51: public long totalObjectRefs; "Reference count" sounds a bit like resource counter? Is that the case? If not, perhaps "Object References" is better. We tried to avoid abbreviations. How about naming the field "totalObjectReferences" or just "objectReferences"? ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From jjiang at openjdk.java.net Thu Feb 11 10:10:58 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 11 Feb 2021 10:10:58 GMT Subject: RFR: JDK-8261510: Use RFC numbers and protocol titles in sun.security.ssl.SSLExtension comments [v3] In-Reply-To: References: Message-ID: > This is a simple cleanup for sun.security.ssl.SSLExtension. > The comments for the extension groups would use the RFC numbers and the protocol titles correspondingly. > It also removes a trailing space in extension token_binding, and move signature_algorithms and signature_algorithms_cert to RFC 8446 extension group. John Jiang has updated the pull request incrementally with one additional commit since the last revision: A extension group comment uses both of RFC number and protocol title ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2517/files - new: https://git.openjdk.java.net/jdk/pull/2517/files/84f131c0..f948498d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2517&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2517&range=01-02 Stats: 63 lines in 1 file changed: 21 ins; 21 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2517.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2517/head:pull/2517 PR: https://git.openjdk.java.net/jdk/pull/2517 From fguallini at openjdk.java.net Thu Feb 11 12:08:54 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 11 Feb 2021 12:08:54 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v4] In-Reply-To: References: Message-ID: > The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: > sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java > javax/net/ssl/TLSCommon/TLSTest.java > sun/security/ssl/CipherSuite/SupportedGroups.java > > > javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: check exception type ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2405/files - new: https://git.openjdk.java.net/jdk/pull/2405/files/382a389a..8acf751a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=02-03 Stats: 16 lines in 1 file changed: 12 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405 PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Thu Feb 11 12:11:41 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 11 Feb 2021 12:11:41 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3] In-Reply-To: <15CFhSSlCaeuuHOeZH8erI7GCWCNy3WTac7hzbVWMhQ=.d32e1c8c-e283-490f-933c-b0c80c80a447@github.com> References: <15CFhSSlCaeuuHOeZH8erI7GCWCNy3WTac7hzbVWMhQ=.d32e1c8c-e283-490f-933c-b0c80c80a447@github.com> Message-ID: <6MOc5jSzvQyfwEAZynNv410JBPhmz52u-kqWkF_DE4Y=.81604ab0-24f2-4724-a40b-209c4cb22a45@github.com> On Wed, 10 Feb 2021 12:24:15 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> narrow down connection reset handling > > test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 142: > >> 140: if ("Connection reset".equals(ssle.getCause().getMessage())) { >> 141: System.out.println("Client SSLException:"); >> 142: ssle.printStackTrace(System.out); > > An SSLException doesn't necessarily have a nested `cause` - so you could get a NPE here. > I would suggest moving that code to a `private boolean isConnectionReset(SSLException ssle)` method, and possibly checking the type of the `cause` exception as well. I'm guessing it should be a `SocketException`? > If you check the type then it will also exclude the case where the cause is null and avoid the NPE. > Additional note: as a general rule, relying on exception message is fragile. But since we don't have a specific subtype for "Connection reset" it's probably the best we can do. Yes, added the verification to check if it is instanceof SocketException ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From dfuchs at openjdk.java.net Thu Feb 11 12:21:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Feb 2021 12:21:44 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v4] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 12:08:54 GMT, Fernando Guallini wrote: >> The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: >> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java >> javax/net/ssl/TLSCommon/TLSTest.java >> sun/security/ssl/CipherSuite/SupportedGroups.java >> >> >> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > check exception type test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 155: > 153: && "Connection reset".equals(cause.getMessage())) { > 154: System.out.println("Client SSLException:"); > 155: ssle.printStackTrace(System.out); Sorry for nit picking - but I would keep that tracing in the catch clause above. } catch (SSLException ssle) { if (isConnectionReset(ssle)) { System.out.println("Client SSLException:"); ssle.printStackTrace(System.out); } else { failTest(ssle, "Client got UNEXPECTED SSLException:"); } } ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Thu Feb 11 12:39:54 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 11 Feb 2021 12:39:54 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v5] In-Reply-To: References: Message-ID: > The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: > sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java > javax/net/ssl/TLSCommon/TLSTest.java > sun/security/ssl/CipherSuite/SupportedGroups.java > > > javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: refactor isConnectionReset method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2405/files - new: https://git.openjdk.java.net/jdk/pull/2405/files/8acf751a..aa0e1468 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=03-04 Stats: 11 lines in 1 file changed: 3 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405 PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Thu Feb 11 12:45:40 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 11 Feb 2021 12:45:40 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v4] In-Reply-To: References: Message-ID: <9NpnHV_wfLxiSHpzCjQ9VZumXuhm2oPybMinVUeXniQ=.22b18b0a-8085-4490-8329-acbd32e53699@github.com> On Thu, 11 Feb 2021 12:17:41 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> check exception type > > test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 155: > >> 153: && "Connection reset".equals(cause.getMessage())) { >> 154: System.out.println("Client SSLException:"); >> 155: ssle.printStackTrace(System.out); > > Sorry for nit picking - but I would keep that tracing in the catch clause above. > > } catch (SSLException ssle) { > if (isConnectionReset(ssle)) { > System.out.println("Client SSLException:"); > ssle.printStackTrace(System.out); > } else { > failTest(ssle, "Client got UNEXPECTED SSLException:"); > } > } > ``` That is perfectly fine. It does make it a bit more legible. ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From rriggs at openjdk.java.net Thu Feb 11 14:29:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 14:29:46 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> References: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> Message-ID: On Wed, 10 Feb 2021 20:30:02 GMT, Roger Riggs wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Marked as reviewed by rriggs (Reviewer). As proposed, events are only created if there is a serialFilter in effect (and enabled by JFR configuration). Being able to create the events without a serialFilter in effect would be useful for monitoring, especially if it could be controlled by a separate JFR configuration option. (always, never, serial-filter , etc.) ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 14:59:11 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 14:59:11 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v2] In-Reply-To: References: Message-ID: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/ca0bcf44..8ecf63ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=00-01 Stats: 124 lines in 5 files changed: 76 ins; 2 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 15:08:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:08:40 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v2] In-Reply-To: References: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> Message-ID: On Thu, 11 Feb 2021 14:27:19 GMT, Roger Riggs wrote: >> Marked as reviewed by rriggs (Reviewer). > > As proposed, events are only created if there is a serialFilter in effect (and enabled by JFR configuration). > Being able to create the events without a serialFilter in effect would be useful for monitoring, especially if it could be controlled by a separate JFR configuration option. (always, never, serial-filter , etc.) I updated the PR and addressed all comments so far. Specifically: @RogerRiggs The generation of the event is independent of whether the filter is set or not. I also added a piece of state to determine if a filter is set or not. I think it could be useful to analyse all Deserialisation events to, say, ensure that there are none operating without a filter ( and the `filterStatus` state is ambitious in the `null` case ). @coffeys I would like GlobalFilterTest to run regardless of whether or not the jfr module is present, but of course running the test with jfr enabled is desirable too, so I added a separate at test tag for that case. @egahlin Excellent suggestions on the naming, etc. I adopted all. And added a test to ensure that the creation and generation of the event does not inadvertently trigger class initialization if the filter rejects the attempt ( thanks @dfuch ) @dfuch Thanks for the improved label suggestion, it is now merged in. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From dfuchs at openjdk.java.net Thu Feb 11 15:26:42 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Feb 2021 15:26:42 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v5] In-Reply-To: References: Message-ID: <3OfRI2Q29X3Zra_8ubotNq3K_SwxE_Hd0uVPIpozVhc=.008c9bc0-c854-497f-97fa-f380baafc147@github.com> On Thu, 11 Feb 2021 12:39:54 GMT, Fernando Guallini wrote: >> The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: >> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java >> javax/net/ssl/TLSCommon/TLSTest.java >> sun/security/ssl/CipherSuite/SupportedGroups.java >> >> >> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > refactor isConnectionReset method LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2405 From chegar at openjdk.java.net Thu Feb 11 15:28:07 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:28:07 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Fix failing test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/8ecf63ce..5737ee7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From coffeys at openjdk.java.net Thu Feb 11 15:47:40 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 11 Feb 2021 15:47:40 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: <1OfJdorvNMIRynW7A8A16UwuPC2qQbvA0VgYHIplhPQ=.2063d3c0-532d-49d4-9748-2e4d31df6c45@github.com> On Thu, 11 Feb 2021 15:28:07 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing test Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From dfuchs at openjdk.java.net Thu Feb 11 15:53:07 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Feb 2021 15:53:07 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:28:07 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing test src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 42: > 40: > 41: @Label("Filter configured") > 42: public boolean filterConfigured; Should that be "Filter Configured" for consistency? ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 15:53:06 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:53:06 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Filter **C**onfigured ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/5737ee7c..d764f75f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 15:53:08 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:53:08 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:45:33 GMT, Daniel Fuchs wrote: >> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing test > > src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 42: > >> 40: >> 41: @Label("Filter configured") >> 42: public boolean filterConfigured; > > Should that be "Filter Configured" for consistency? Good catch. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From wetmore at openjdk.java.net Thu Feb 11 15:56:38 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 11 Feb 2021 15:56:38 GMT Subject: RFR: JDK-8261510: Use RFC numbers and protocol titles in sun.security.ssl.SSLExtension comments [v3] In-Reply-To: References: Message-ID: <_1-RpqIv_BG5Fdi-_Ml2cwPEyhySaifnygVsqwDVxDI=.aa835bd4-ae4a-4141-9b60-2f5b78c7ee05@github.com> On Thu, 11 Feb 2021 10:10:58 GMT, John Jiang wrote: >> This is a simple cleanup for sun.security.ssl.SSLExtension. >> The comments for the extension groups would use the RFC numbers and the protocol titles correspondingly. >> It also removes a trailing space in extension token_binding, and move signature_algorithms and signature_algorithms_cert to RFC 8446 extension group. > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > A extension group comment uses both of RFC number and protocol title Looks good, thanks. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2517 From jlaskey at openjdk.java.net Thu Feb 11 16:02:03 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 11 Feb 2021 16:02:03 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Added table of available algorithms. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/1c17ad35..f1e3699d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=15-16 Stats: 181 lines in 3 files changed: 140 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From dfuchs at openjdk.java.net Thu Feb 11 16:04:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Feb 2021 16:04:44 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:53:06 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Filter **C**onfigured LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2479 From rriggs at openjdk.java.net Thu Feb 11 16:04:45 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 16:04:45 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:53:06 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Filter **C**onfigured Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From xuelei at openjdk.java.net Thu Feb 11 16:27:41 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 11 Feb 2021 16:27:41 GMT Subject: RFR: JDK-8261510: Use RFC numbers and protocol titles in sun.security.ssl.SSLExtension comments [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 10:10:58 GMT, John Jiang wrote: >> This is a simple cleanup for sun.security.ssl.SSLExtension. >> The comments for the extension groups would use the RFC numbers and the protocol titles correspondingly. >> It also removes a trailing space in extension token_binding, and move signature_algorithms and signature_algorithms_cert to RFC 8446 extension group. > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > A extension group comment uses both of RFC number and protocol title Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2517 From jjiang at openjdk.java.net Thu Feb 11 18:28:41 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 11 Feb 2021 18:28:41 GMT Subject: Integrated: JDK-8261510: Use RFC numbers and protocol titles in sun.security.ssl.SSLExtension comments In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 21:22:03 GMT, John Jiang wrote: > This is a simple cleanup for sun.security.ssl.SSLExtension. > The comments for the extension groups would use the RFC numbers and the protocol titles correspondingly. > It also removes a trailing space in extension token_binding, and move signature_algorithms and signature_algorithms_cert to RFC 8446 extension group. This pull request has now been integrated. Changeset: f4cfd758 Author: John Jiang URL: https://git.openjdk.java.net/jdk/commit/f4cfd758 Stats: 105 lines in 1 file changed: 40 ins; 43 del; 22 mod 8261510: Use RFC numbers and protocol titles in sun.security.ssl.SSLExtension comments Reviewed-by: wetmore, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/2517 From weijun at openjdk.java.net Thu Feb 11 19:52:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 11 Feb 2021 19:52:43 GMT Subject: RFR: 8257497: Key identifier compliance issue [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 01:01:56 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > API used to get AKID src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1482: > 1480: byte[] signerSubjectKeyIdExt = ((X509Certificate)signerCert).getExtensionValue( > 1481: KnownOIDs.SubjectKeyID.value()); > 1482: How about pass in the `KeyIdentifier` instead of `PublicKey akey` into the createV3Extensions method? And you can calculated with X509CertImpl impl; if (signerCert instanceof X509CertImpl) { impl = (X509CertImpl) signerCert; } else { impl = new X509CertImpl(signerCert.getEncoded()); } impl.getSubjectKeyId(); ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From sean.mullan at oracle.com Thu Feb 11 21:05:59 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Feb 2021 16:05:59 -0500 Subject: Integrated: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint In-Reply-To: <6ec9012a-b2be-0c0d-5231-03c6ced0bfe7@comcast.net> References: <6ec9012a-b2be-0c0d-5231-03c6ced0bfe7@comcast.net> Message-ID: <6c7b9c16-1b6e-4fe2-77d8-f18000d42af0@oracle.com> Michael, Thanks for the comments - a couple of observations of mine below -- On 2/10/21 12:53 AM, Michael StJohns wrote: > On 2/9/2021 9:02 PM, Weijun Wang wrote: >> On Wed, 10 Feb 2021 01:39:15 GMT, Weijun Wang wrote: >> >>> Print out "no limit" instead. This is the words RFC 5280 uses: "Where pathLenConstraint does not appear, no limit is imposed". >>> >>> No regression test. Trivial. >> This pull request has now been integrated. >> >> Changeset: 4619f372 >> Author: Weijun Wang >> URL:https://git.openjdk.java.net/jdk/commit/4619f372 >> Stats: 11 lines in 1 file changed: 8 ins; 1 del; 2 mod >> >> 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint >> >> Reviewed-by: jnimeh >> >> ------------- >> >> PR:https://git.openjdk.java.net/jdk/pull/2493 > > > Sorry - not quite right, it's not quite that trivial a fix. > > The definition for BasicConstraints is > >> BasicConstraints ::= SEQUENCE { >> cA BOOLEAN DEFAULT FALSE, >> pathLenConstraint INTEGER (0..MAX) OPTIONAL } > > If pathLenConstraint is not present, then the path length is infinite. > The flag value for that looks like it was encoded as both any negative > number (and set to -1 to start) and Integer.MAX_VALUE.? I'm not quite > sure why it was done that way, but there's a problem doing that - > actually a bunch of them. > > You really ought to get the same encoding coming and going (e.g. > creating an object from DER should encode back to the exact same DER). > The current code does not do that. > > 1) It's not valid to encode or decode pathLenConstraint in the DER as a > negative number.?? This isn't a problem for encoding, but the > BasicConstraintsException(Boolean critical, Object value) needs a value > check after line 157 to make sure that the decoded pathLengthConstraint > field is positive - i'd throw an IOException on failure. I agree. >??? I'd also > change line 149 to just return - the initial value of pathLen is -1 and > that's an appropriate flag for a missing field. Some of this is due to the API for X509Certificate.getBasicConstraints(), and this code tries to return values that comply with that API. That API returns an integer which is specified as: "the value of pathLenConstraint if the BasicConstraints extension is present in the certificate and the subject of the certificate is a CA, otherwise -1. If the subject of the certificate is a CA and pathLenConstraint does not appear, Integer.MAX_VALUE is returned to indicate that there is no limit to the allowed length of the certification path." We need to be careful that for any changes we make, we still comply with the API. > 2) I'm not sure why the set/get methods were added.? I think it was to > provide access for the PathValidation stuff? Given that they are > present, I'd insert a line after line 222 (set) : "if (pathLen < 0) > pathLen = -1;" // treat any negative value as unconstrained path length In this case, I would throw an Exception. If the pathLenConstraint is unconstrained, it should not call this method at all. The internal X509 classes have set/get/delete methods dating back to the original design. > 3) And since the only place pathLen is available externally is in the > get method, I'd change line 237 to "return (pathLen < 0) ? > Integer.MAX_VALUE : Integer.valueOf(pathLen);"?? I think this is more > correct than returning -1. I think it is better to ensure that in this class, pathLen is never < 0, and maybe create an extra boolean flag to indicate if there is a pathLenConstraint field, or alternatively use an Integer object where null means there is no field. I think a lot of these issues are due to the fact that in this class -1 can mean either a bad value, or an unconstrained length. > 4) And to fix the problem that led to this discussion, change line 176 > to 'pathLenAsString = " unconstrained"' and delete lines 177-178.? E.g. > there's no such thing as undefined here - both a negative number and > MAX_VALUE mean unconstrained length in the previous version of the code. > > 5) One more - in the other constructor, change line 108 to "this.pathLen > = (len < 0 || len == Integer.MAX_VALUE) ? -1 : len;" > > 6) *sigh* Delete lines 197-201.? I have no idea why they are overriding > the specified value of critical based on whether ca is true or not, but > it's wrong.??? Conversely, the call to the constructor at line 95 is > correct. That does seem a little weird. --Sean From hchao at openjdk.java.net Thu Feb 11 22:14:01 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 11 Feb 2021 22:14:01 GMT Subject: RFR: 8257497: Key identifier compliance issue [v4] In-Reply-To: References: Message-ID: > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: passing in KeyIdentifier to createV3Extensions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2343/files - new: https://git.openjdk.java.net/jdk/pull/2343/files/2f5199ca..ddac63f4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=02-03 Stats: 18 lines in 2 files changed: 6 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2343/head:pull/2343 PR: https://git.openjdk.java.net/jdk/pull/2343 From hchao at openjdk.java.net Thu Feb 11 22:14:03 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 11 Feb 2021 22:14:03 GMT Subject: RFR: 8257497: Key identifier compliance issue [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 19:48:23 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> API used to get AKID > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1482: > >> 1480: byte[] signerSubjectKeyIdExt = ((X509Certificate)signerCert).getExtensionValue( >> 1481: KnownOIDs.SubjectKeyID.value()); >> 1482: > > How about pass in the `KeyIdentifier` instead of `PublicKey akey` into the createV3Extensions method? And you can calculated with > X509CertImpl impl; > if (signerCert instanceof X509CertImpl) { > impl = (X509CertImpl) signerCert; > } else { > impl = new X509CertImpl(signerCert.getEncoded()); > } > impl.getSubjectKeyId(); Changed as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From mbaesken at openjdk.java.net Fri Feb 12 08:54:45 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 12 Feb 2021 08:54:45 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 Message-ID: There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. Sonar reports : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG Potential leak of memory pointed to by 'newBuf' I adjusted the early return and added freeing memory . Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? ------------- Commit messages: - JDK-8261601 Changes: https://git.openjdk.java.net/jdk/pull/2540/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2540&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261601 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2540/head:pull/2540 PR: https://git.openjdk.java.net/jdk/pull/2540 From clanger at openjdk.java.net Fri Feb 12 10:02:40 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 12 Feb 2021 10:02:40 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. > > Sonar reports : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG > > Potential leak of memory pointed to by 'newBuf' > I adjusted the early return and added freeing memory . > > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? LGTM ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2540 From dfuchs at openjdk.java.net Fri Feb 12 10:43:42 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 12 Feb 2021 10:43:42 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. > > Sonar reports : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG > > Potential leak of memory pointed to by 'newBuf' > I adjusted the early return and added freeing memory . > > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2540 From dfuchs at openjdk.java.net Fri Feb 12 10:54:38 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 12 Feb 2021 10:54:38 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. > > Sonar reports : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG > > Potential leak of memory pointed to by 'newBuf' > I adjusted the early return and added freeing memory . > > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? @MBaesken did you run the jdk_sctp tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/2540 From mbaesken at openjdk.java.net Fri Feb 12 11:07:38 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 12 Feb 2021 11:07:38 GMT Subject: RFR: 8261534: Test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java fails on platforms where no nsslib artifacts are defined In-Reply-To: <7r1bBHy5TWz4xlHX0TX_YeeS6DQVmeM9rFKrit18fsI=.6d7c49c1-d6e3-42d8-afda-b1c0546d2611@github.com> References: <7r1bBHy5TWz4xlHX0TX_YeeS6DQVmeM9rFKrit18fsI=.6d7c49c1-d6e3-42d8-afda-b1c0546d2611@github.com> Message-ID: On Wed, 10 Feb 2021 23:29:14 GMT, Christoph Langer wrote: > Fix exception in test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java: > > java.security.AccessControlException: access denied ("java.security.SecurityPermission" "removeProvider.SUN") > at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) > at java.base/java.lang.SecurityManager.checkSecurityAccess(SecurityManager.java:1521) > at java.base/java.security.Security.check(Security.java:832) > at java.base/java.security.Security.removeProvider(Security.java:444) > at IllegalPackageAccess.main(IllegalPackageAccess.java:81) > at PKCS11Test.premain(PKCS11Test.java:171) > at PKCS11Test.testNSS(PKCS11Test.java:568) > at PKCS11Test.main(PKCS11Test.java:207) > at IllegalPackageAccess.main(IllegalPackageAccess.java:69) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > Root cause is that the test materializes and installs a policy by [obtaining the current policy](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L46). At the time it [tries to remove a provider](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L80), the materialized policy is used for an access check, due to some intricacies of the [java.security.Policy implementation](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/src/java.base/share/classes/java/security/Policy.java#L293). This policy does not allow the removal of a provider. > On platforms where the test runs through [PKCS11Test::fetchNssLib](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/PKCS11Test.java#L859), the default policy is reset which makes the test work. But if we don't pass there, the test fails. > > The fix is to unconditionally call Policy.setPolicy(null); in IllegalPackageAccess before installing MyPolicy. LGTM ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2518 From mbaesken at openjdk.java.net Fri Feb 12 11:15:44 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 12 Feb 2021 11:15:44 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. > > Sonar reports : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG > > Potential leak of memory pointed to by 'newBuf' > I adjusted the early return and added freeing memory . > > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? > @MBaesken did you run the jdk_sctp tests? Hi, the com/sun/nio/sctp jtreg tests passed on linux x86_64. I'll put it into our internal build/test queue to see over night what it does on all the platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/2540 From mbaesken at openjdk.java.net Fri Feb 12 11:20:39 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 12 Feb 2021 11:20:39 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: >Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated >memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the >CHECK_NULL , is there some deallocation missing there too ? hi, any comments on this ? See SctpChannelImpl.c [SctpChannelImpl.c ](https://github.com/openjdk/jdk/blob/master/src/jdk.sctp/unix/native/libsctp/SctpChannelImpl.c#L222) the malloc there is followed by a few early returns, where is the memory freed is these cases ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2540 From vkempik at openjdk.java.net Fri Feb 12 11:45:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 11:45:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com> References: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com> Message-ID: On Thu, 4 Feb 2021 21:59:02 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194: > >> 192: // may get turned off by -fomit-frame-pointer. >> 193: frame os::get_sender_for_C_frame(frame* fr) { >> 194: return frame(fr->link(), fr->link(), fr->sender_pc()); > > Why is it > > return frame(fr->link(), fr->link(), fr->sender_pc()); > > and not > > return frame(fr->sender_sp(), fr->link(), fr->sender_pc()); > > like in the bsd-x86 counter part? bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things from bsd_x86 You think the bsd-x86 is better here ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 12 12:07:52 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 12:07:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:07:15 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195: > >> 193: frame os::get_sender_for_C_frame(frame* fr) { >> 194: return frame(fr->link(), fr->link(), fr->sender_pc()); >> 195: } > > Is this file going to be built by GCC or just macOS compilers? there is no support for compiling java with gcc on macos since about jdk11, only clang. considering this and the absence of gcc for macos_m1, the answer is - just macOS compilers. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 12 12:25:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 12:25:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 22:54:42 GMT, Gerard Ziemski wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363: >> >>> 361: address pc = os::Posix::ucontext_get_pc(uc); >>> 362: >>> 363: if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means >> >> Is this TODO going to be resolved by this port? > > Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds. @lewurm could you comment here please ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 12 12:25:48 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 12:25:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:12:07 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: > >> 433: // | |\ Java thread created by VM does not have glibc >> 434: // | glibc guard page | - guard, attached Java thread usually has >> 435: // | |/ 1 glibc guard page. > > Is this code going to be built by GCC (with glibc) or will only > macOS compilers and libraries be used? only macos comiplers ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From fweimer at openjdk.java.net Fri Feb 12 12:42:48 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Fri, 12 Feb 2021 12:42:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 12:22:44 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: >> >>> 433: // | |\ Java thread created by VM does not have glibc >>> 434: // | glibc guard page | - guard, attached Java thread usually has >>> 435: // | |/ 1 glibc guard page. >> >> Is this code going to be built by GCC (with glibc) or will only >> macOS compilers and libraries be used? > > only macos comiplers The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard region independently of page size, otherwise `-fstack-clash-protection` is not reliable. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 12 13:35:48 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 13:35:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:14:42 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486: > >> 484: } >> 485: } >> 486: } > > This appears to be a mix for Mavericks (10.9) and 10.12 > work arounds. Is this code needed by this project? I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround Gerard, 8020753 was originally your fix, do you know if it still needed on intel-mac ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 12 13:46:09 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Feb 2021 13:46:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v13] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/0d0e9baf..ad4e4c65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 12 13:50:49 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Feb 2021 13:50:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 09:11:50 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: >> >>> 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); >>> 322: >>> 323: str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset())); >> >> I don't think this switch from `JavaThread::saved_fp_address_offset()` >> to `JavaFrameAnchor::saved_fp_address_offset()` is correct since >> `rthread` is still used and is a JavaThread*. The new code will give you: >> >> `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor >> >> The old code gave you: >> >> `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread >> >> Those are not the same things. > > I agree, I don't understand why this change was made. Wow, this is scary. I don't understand how I've merged JDK-8257882 like this. I've reviewed cpu/aarch64 changes again, there is nothing suspicious besides this. Thank you very much for catching, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From mullan at openjdk.java.net Fri Feb 12 13:54:39 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 12 Feb 2021 13:54:39 GMT Subject: RFR: 8248223: KeyAgreement spec update on multi-party key exchange support In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 16:33:54 GMT, Jamil Nimeh wrote: > This is a spec-only change that clarifies the requirement on KeyAgreement implementations for multi-party support where there are 3 or more parties involved. This change states that 3+ party support is implementation-specific unless the underlying specification for that algorithm requires support for 3 or more parties. > Bug: https://bugs.openjdk.java.net/browse/JDK-8248223 > CSR: https://bugs.openjdk.java.net/browse/JDK-8261456 Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2512 From vkempik at openjdk.java.net Fri Feb 12 14:07:51 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 14:07:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:08:14 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 221: > >> 219: assert(sig == info->si_signo, "bad siginfo"); >> 220: } >> 221: */ > > Should this code be deleted? From here and from where it was copied > from if it is also commented out there... Thanks, will fix in bsd_aarch64 soon, as for bsd_x86 I've filled new bug and pr - https://github.com/openjdk/jdk/pull/2547 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Fri Feb 12 14:52:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 12 Feb 2021 14:52:42 GMT Subject: RFR: 8257497: Key identifier compliance issue [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 22:10:55 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1482: >> >>> 1480: byte[] signerSubjectKeyIdExt = ((X509Certificate)signerCert).getExtensionValue( >>> 1481: KnownOIDs.SubjectKeyID.value()); >>> 1482: >> >> How about pass in the `KeyIdentifier` instead of `PublicKey akey` into the createV3Extensions method? And you can calculated with >> X509CertImpl impl; >> if (signerCert instanceof X509CertImpl) { >> impl = (X509CertImpl) signerCert; >> } else { >> impl = new X509CertImpl(signerCert.getEncoded()); >> } >> impl.getSubjectKeyId(); > > Changed as suggested. Sorry, I should have been more verbose on my suggestion. I was thinking about passing in **_only_** the `KeyIdentifier` and _**not**_ `akey`. After all both of them are for the same purpose and it's clear to consolidate to only one. If the cert has an SKID then use it, otherwise calculate one using `new KeyIdentifier(akey)`. All these are done inside the `doGenCert)()` method. The `createV3Extensions` just add an AKID if the parameter is not null. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From mullan at openjdk.java.net Fri Feb 12 14:55:41 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 12 Feb 2021 14:55:41 GMT Subject: RFR: 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur In-Reply-To: <9-DfPaZic-YwrYzGqTup_SUnPc7H9TEVWx17PIfUUPI=.e81e227e-7b79-489f-be1e-b173820056a4@github.com> References: <9-DfPaZic-YwrYzGqTup_SUnPc7H9TEVWx17PIfUUPI=.e81e227e-7b79-489f-be1e-b173820056a4@github.com> Message-ID: On Wed, 10 Feb 2021 01:23:29 GMT, Weijun Wang wrote: > Accept macOS 11.x as well. > > No new regression test. This can be approved by running the existing test test/sun/security/krb5/config/native/TestDynamicStore.java on Big Sur. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2492 From weijun at openjdk.java.net Fri Feb 12 15:00:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 12 Feb 2021 15:00:41 GMT Subject: Integrated: 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur In-Reply-To: <9-DfPaZic-YwrYzGqTup_SUnPc7H9TEVWx17PIfUUPI=.e81e227e-7b79-489f-be1e-b173820056a4@github.com> References: <9-DfPaZic-YwrYzGqTup_SUnPc7H9TEVWx17PIfUUPI=.e81e227e-7b79-489f-be1e-b173820056a4@github.com> Message-ID: On Wed, 10 Feb 2021 01:23:29 GMT, Weijun Wang wrote: > Accept macOS 11.x as well. > > No new regression test. This can be approved by running the existing test test/sun/security/krb5/config/native/TestDynamicStore.java on Big Sur. This pull request has now been integrated. Changeset: 59b8d595 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/59b8d595 Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2492 From vkempik at openjdk.java.net Fri Feb 12 15:25:54 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 15:25:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com> On Thu, 4 Feb 2021 22:49:23 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297: > >> 295: stub = SharedRuntime::handle_unsafe_access(thread, next_pc); >> 296: } >> 297: } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) { > > Can we add a comment here describing what this case means? this arm64 specific part came as is from linux_aarch64 and I can't add any meaning comments here. > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302: > >> 300: const uint64_t *detail_msg_ptr >> 301: = (uint64_t*)(pc + NativeInstruction::instruction_size); >> 302: const char *detail_msg = (const char *)*detail_msg_ptr; > > Where is `detail_msg` used? Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in report_and_die But became unused on bsd_arm64. I agree this needs to be removed > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403: > >> 401: } >> 402: >> 403: return false; // Mute compiler > > Is this comment needed? this part came as is from linux_aarch64 as well and was supposed to mean something there. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Fri Feb 12 15:28:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 12 Feb 2021 15:28:54 GMT Subject: RFR: 8259535: ECDSA SignatureValue do not always have the specified length Message-ID: The code change fixes the ECDSA XML signature length issue. It should only happened when there is no P1363 ECDSA support, which is not true when SunEC is used. Technically, if a PrivateKey is not of ECPrivateKey the bug will still show up, and in this case we can actually look into the OID/parameter of the ASN.1 encoding and do further evaluation, but I think this is not worth doing. Please advise me if you think differently. ------------- Commit messages: - 8259535: ECDSA SignatureValue do not always have the specified length Changes: https://git.openjdk.java.net/jdk/pull/2550/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2550&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259535 Stats: 227 lines in 4 files changed: 216 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2550.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2550/head:pull/2550 PR: https://git.openjdk.java.net/jdk/pull/2550 From bpb at openjdk.java.net Fri Feb 12 16:15:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 16:15:39 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. > > Sonar reports : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG > > Potential leak of memory pointed to by 'newBuf' > I adjusted the early return and added freeing memory . > > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? This change looks fine. I don't know about handleSendFailed(). ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2540 From chegar at openjdk.java.net Fri Feb 12 16:26:09 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 12 Feb 2021 16:26:09 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: References: Message-ID: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Split exception into type and message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/d764f75f..8cb8f75e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=03-04 Stats: 48 lines in 4 files changed: 34 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Fri Feb 12 16:26:10 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 12 Feb 2021 16:26:10 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:09 GMT, Roger Riggs wrote: >> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: >> >> Filter **C**onfigured > > Marked as reviewed by rriggs (Reviewer). Speaking to Erik offline, he suggested to split the `exceptionMessage` into `exceptionType` and `exceptionMessage` ( since the code was somewhat overloading the existing Sting field by using toString to force the exception class name and message into a single sting ). While the exceptionXXX field should rarely be non-null, they add very little overhead. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From rriggs at openjdk.java.net Fri Feb 12 16:40:42 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 12 Feb 2021 16:40:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From coffeys at openjdk.java.net Fri Feb 12 16:52:42 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 12 Feb 2021 16:52:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From dfuchs at openjdk.java.net Fri Feb 12 16:58:42 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 12 Feb 2021 16:58:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From egahlin at openjdk.java.net Fri Feb 12 17:03:47 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 12 Feb 2021 17:03:47 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Fri Feb 12 17:38:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 12 Feb 2021 17:38:40 GMT Subject: Integrated: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. This pull request has now been integrated. Changeset: 3dc6f52a Author: Chris Hegarty URL: https://git.openjdk.java.net/jdk/commit/3dc6f52a Stats: 620 lines in 12 files changed: 598 ins; 5 del; 17 mod 8261160: Add a deserialization JFR event Co-authored-by: Sean Coffey Co-authored-by: Chris Hegarty Reviewed-by: coffeys, rriggs, dfuchs, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From mbalao at openjdk.java.net Fri Feb 12 19:13:39 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 12 Feb 2021 19:13:39 GMT Subject: RFR: 8261534: Test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java fails on platforms where no nsslib artifacts are defined In-Reply-To: References: <7r1bBHy5TWz4xlHX0TX_YeeS6DQVmeM9rFKrit18fsI=.6d7c49c1-d6e3-42d8-afda-b1c0546d2611@github.com> Message-ID: On Fri, 12 Feb 2021 11:05:22 GMT, Matthias Baesken wrote: >> Fix exception in test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java: >> >> java.security.AccessControlException: access denied ("java.security.SecurityPermission" "removeProvider.SUN") >> at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) >> at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) >> at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) >> at java.base/java.lang.SecurityManager.checkSecurityAccess(SecurityManager.java:1521) >> at java.base/java.security.Security.check(Security.java:832) >> at java.base/java.security.Security.removeProvider(Security.java:444) >> at IllegalPackageAccess.main(IllegalPackageAccess.java:81) >> at PKCS11Test.premain(PKCS11Test.java:171) >> at PKCS11Test.testNSS(PKCS11Test.java:568) >> at PKCS11Test.main(PKCS11Test.java:207) >> at IllegalPackageAccess.main(IllegalPackageAccess.java:69) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> Root cause is that the test materializes and installs a policy by [obtaining the current policy](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L46). At the time it [tries to remove a provider](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L80), the materialized policy is used for an access check, due to some intricacies of the [java.security.Policy implementation](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/src/java.base/share/classes/java/security/Policy.java#L293). This policy does not allow the removal of a provider. >> On platforms where the test runs through [PKCS11Test::fetchNssLib](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/PKCS11Test.java#L859), the default policy is reset which makes the test work. But if we don't pass there, the test fails. >> >> The fix is to unconditionally call Policy.setPolicy(null); in IllegalPackageAccess before installing MyPolicy. > > LGTM I'm not a JDK main line reviewer but the proposed fix looks good to me as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/2518 From alanb at openjdk.java.net Fri Feb 12 19:33:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 12 Feb 2021 19:33:40 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > >> >> >> @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! @JarvisCraft Can you re-run your benchmarks in light of the changes that @cl4es pointed out in the previous comment? We think this PR can be closed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From hchao at openjdk.java.net Fri Feb 12 20:42:03 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 12 Feb 2021 20:42:03 GMT Subject: RFR: 8257497: Key identifier compliance issue [v5] In-Reply-To: References: Message-ID: <5h7yVK3O-WOeqmurzg5yRIj_I-xJLJ8iRbMl6UD5eu4=.6e0caf2c-4680-4dc8-befb-ed90bd954c90@github.com> > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Reduced one param to createV3Extensions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2343/files - new: https://git.openjdk.java.net/jdk/pull/2343/files/ddac63f4..4bd7e45c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=03-04 Stats: 43 lines in 2 files changed: 19 ins; 14 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2343/head:pull/2343 PR: https://git.openjdk.java.net/jdk/pull/2343 From hchao at openjdk.java.net Fri Feb 12 20:42:03 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 12 Feb 2021 20:42:03 GMT Subject: RFR: 8257497: Key identifier compliance issue [v3] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 14:49:17 GMT, Weijun Wang wrote: >> Changed as suggested. > > Sorry, I should have been more verbose on my suggestion. I was thinking about passing in **_only_** the `KeyIdentifier` and _**not**_ `akey`. After all both of them are for the same purpose and it's clear to consolidate to only one. If the cert has an SKID then use it, otherwise calculate one using `new KeyIdentifier(akey)`. All these are done inside the `doGenCert)()` method. The `createV3Extensions` just add an AKID if the parameter is not null. Updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From clanger at openjdk.java.net Fri Feb 12 21:01:37 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 12 Feb 2021 21:01:37 GMT Subject: RFR: 8261534: Test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java fails on platforms where no nsslib artifacts are defined In-Reply-To: References: <7r1bBHy5TWz4xlHX0TX_YeeS6DQVmeM9rFKrit18fsI=.6d7c49c1-d6e3-42d8-afda-b1c0546d2611@github.com> Message-ID: On Fri, 12 Feb 2021 19:10:36 GMT, Martin Balao wrote: >> LGTM > > I'm not a JDK main line reviewer but the proposed fix looks good to me as well. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/2518 From clanger at openjdk.java.net Fri Feb 12 21:01:39 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 12 Feb 2021 21:01:39 GMT Subject: Integrated: 8261534: Test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java fails on platforms where no nsslib artifacts are defined In-Reply-To: <7r1bBHy5TWz4xlHX0TX_YeeS6DQVmeM9rFKrit18fsI=.6d7c49c1-d6e3-42d8-afda-b1c0546d2611@github.com> References: <7r1bBHy5TWz4xlHX0TX_YeeS6DQVmeM9rFKrit18fsI=.6d7c49c1-d6e3-42d8-afda-b1c0546d2611@github.com> Message-ID: <2XN22yel0D0WbtPg0Rv4R76Z-N8LQetp8DASH9_vnrk=.0b611540-aebb-48aa-9e50-ba32b8936482@github.com> On Wed, 10 Feb 2021 23:29:14 GMT, Christoph Langer wrote: > Fix exception in test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java: > > java.security.AccessControlException: access denied ("java.security.SecurityPermission" "removeProvider.SUN") > at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) > at java.base/java.lang.SecurityManager.checkSecurityAccess(SecurityManager.java:1521) > at java.base/java.security.Security.check(Security.java:832) > at java.base/java.security.Security.removeProvider(Security.java:444) > at IllegalPackageAccess.main(IllegalPackageAccess.java:81) > at PKCS11Test.premain(PKCS11Test.java:171) > at PKCS11Test.testNSS(PKCS11Test.java:568) > at PKCS11Test.main(PKCS11Test.java:207) > at IllegalPackageAccess.main(IllegalPackageAccess.java:69) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > Root cause is that the test materializes and installs a policy by [obtaining the current policy](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L46). At the time it [tries to remove a provider](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java#L80), the materialized policy is used for an access check, due to some intricacies of the [java.security.Policy implementation](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/src/java.base/share/classes/java/security/Policy.java#L293). This policy does not allow the removal of a provider. > On platforms where the test runs through [PKCS11Test::fetchNssLib](https://github.com/openjdk/jdk/blob/4be2173478bd1e84946bd903b350ce466bddb36b/test/jdk/sun/security/pkcs11/PKCS11Test.java#L859), the default policy is reset which makes the test work. But if we don't pass there, the test fails. > > The fix is to unconditionally call Policy.setPolicy(null); in IllegalPackageAccess before installing MyPolicy. This pull request has now been integrated. Changeset: dc46aa85 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/dc46aa85 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8261534: Test sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java fails on platforms where no nsslib artifacts are defined Reviewed-by: mbaesken ------------- PR: https://git.openjdk.java.net/jdk/pull/2518 From weijun at openjdk.java.net Fri Feb 12 21:04:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 12 Feb 2021 21:04:41 GMT Subject: RFR: 8257497: Key identifier compliance issue [v5] In-Reply-To: <5h7yVK3O-WOeqmurzg5yRIj_I-xJLJ8iRbMl6UD5eu4=.6e0caf2c-4680-4dc8-befb-ed90bd954c90@github.com> References: <5h7yVK3O-WOeqmurzg5yRIj_I-xJLJ8iRbMl6UD5eu4=.6e0caf2c-4680-4dc8-befb-ed90bd954c90@github.com> Message-ID: <66qyDNAoE82S-j3yxER_HA3U6wJTkOKC4Mu1mmwru-s=.99d14195-9677-458c-a85a-ed7b69a19248@github.com> On Fri, 12 Feb 2021 20:42:03 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Reduced one param to createV3Extensions LGTM. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2343 From hchao at openjdk.java.net Fri Feb 12 21:07:41 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 12 Feb 2021 21:07:41 GMT Subject: RFR: 8257497: Key identifier compliance issue [v5] In-Reply-To: <66qyDNAoE82S-j3yxER_HA3U6wJTkOKC4Mu1mmwru-s=.99d14195-9677-458c-a85a-ed7b69a19248@github.com> References: <5h7yVK3O-WOeqmurzg5yRIj_I-xJLJ8iRbMl6UD5eu4=.6e0caf2c-4680-4dc8-befb-ed90bd954c90@github.com> <66qyDNAoE82S-j3yxER_HA3U6wJTkOKC4Mu1mmwru-s=.99d14195-9677-458c-a85a-ed7b69a19248@github.com> Message-ID: On Fri, 12 Feb 2021 21:01:48 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduced one param to createV3Extensions > > LGTM. Thanks for the review, Max! ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:09:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:09:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> Message-ID: On Fri, 12 Feb 2021 21:03:04 GMT, Andrey Turbanov wrote: >> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. >> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk > > I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33) > and checked tier2 and tier3. > What I got: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > >> jtreg:test/jdk:tier2 3698 3690 6 2 << > >> jtreg:test/langtools:tier2 12 11 1 0 << > jtreg:test/jaxp:tier2 450 450 0 0 > ============================== > TEST FAILURE > > > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > >> jtreg:test/jdk:tier3 1190 1188 2 0 << > jtreg:test/langtools:tier3 0 0 0 0 > jtreg:test/jaxp:tier3 0 0 0 0 > ============================== > TEST FAILURE > > > Failed tests: > > tier2: > java/io/File/GetXSpace.java Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > java/net/MulticastSocket/MulticastAddresses.java Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. > java/net/MulticastSocket/SetLoopbackMode.java Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information > java/nio/file/Files/CopyAndMove.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected > java/security/AccessController/DoPrivAccompliceTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr > tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > > sun/security/tools/jarsigner/TimestampCheck.java Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details > sun/security/tools/keytool/DefaultOptions.java Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details > > jdk/jshell/ToolBasicTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > tier3: > sanity/client/SwingSet/src/SwingSet2DemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > sanity/client/SwingSet/src/ColorChooserDemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 Then I tried to run tests separately: ## java/io/File/GetXSpace.java make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" STDERR: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) at java.base/java.io.File.toPath(File.java:2316) at GetXSpace.compare(GetXSpace.java:219) at GetXSpace.testDF(GetXSpace.java:394) at GetXSpace.main(GetXSpace.java:428) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.nio.file.InvalidPathException JavaTest Message: shutting down test STDOUT: --- Testing df C:/Programs/cygwin64 350809332 172573816 178235516 50% / D: 3702215676 2812548988 889666688 76% /cygdrive/d E: 3906885628 3544182676 362702952 91% /cygdrive/e F: 250057724 240917056 9140668 97% /cygdrive/f SecurityManager = null C:/Programs/cygwin64: df total= 359228755968 free = 0 usable = 182513168384 getX total= 359228755968 free = 182513168384 usable = 182513168384 :: df total= 3791068852224 free = 0 usable = 911018688512 getX total= 0 free = 0 usable = 0 TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : -------------------------------------------------- https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:09:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:09:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> Message-ID: On Fri, 12 Feb 2021 21:04:54 GMT, Andrey Turbanov wrote: >> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33) >> and checked tier2 and tier3. >> What I got: >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> >> jtreg:test/jdk:tier2 3698 3690 6 2 << >> >> jtreg:test/langtools:tier2 12 11 1 0 << >> jtreg:test/jaxp:tier2 450 450 0 0 >> ============================== >> TEST FAILURE >> >> >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> >> jtreg:test/jdk:tier3 1190 1188 2 0 << >> jtreg:test/langtools:tier3 0 0 0 0 >> jtreg:test/jaxp:tier3 0 0 0 0 >> ============================== >> TEST FAILURE >> >> >> Failed tests: >> >> tier2: >> java/io/File/GetXSpace.java Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> java/net/MulticastSocket/MulticastAddresses.java Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. >> java/net/MulticastSocket/SetLoopbackMode.java Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information >> java/nio/file/Files/CopyAndMove.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> java/security/AccessController/DoPrivAccompliceTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr >> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> >> sun/security/tools/jarsigner/TimestampCheck.java Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details >> sun/security/tools/keytool/DefaultOptions.java Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details >> >> jdk/jshell/ToolBasicTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 >> >> tier3: >> sanity/client/SwingSet/src/SwingSet2DemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 >> sanity/client/SwingSet/src/ColorChooserDemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > Then I tried to run tests separately: > ## java/io/File/GetXSpace.java > > > make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" > > STDERR: > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) > at java.base/java.io.File.toPath(File.java:2316) > at GetXSpace.compare(GetXSpace.java:219) > at GetXSpace.testDF(GetXSpace.java:394) > at GetXSpace.main(GetXSpace.java:428) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.nio.file.InvalidPathException > JavaTest Message: shutting down test > > STDOUT: > --- Testing df > C:/Programs/cygwin64 350809332 172573816 178235516 50% / > D: 3702215676 2812548988 889666688 76% /cygdrive/d > E: 3906885628 3544182676 362702952 91% /cygdrive/e > F: 250057724 240917056 9140668 97% /cygdrive/f > > > SecurityManager = null > C:/Programs/cygwin64: > df total= 359228755968 free = 0 usable = 182513168384 > getX total= 359228755968 free = 182513168384 usable = 182513168384 > :: > df total= 3791068852224 free = 0 usable = 911018688512 > getX total= 0 free = 0 usable = 0 > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > -------------------------------------------------- > > > https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output. ## java/net/MulticastSocket/MulticastAddresses.java make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" STDOUT: Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /129.1.1.1 joinGroup(InetAddress) Passed: Not a multicast address Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Failed: No route to host: no further information Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /0:0:0:0:0:0:0:1 joinGroup(InetAddress) Passed: Not a multicast address Test: /0:0:0:0:0:0:8101:101 joinGroup(InetAddress) Passed: Not a multicast address Test: /fe80:0:0:0:a00:20ff:fee5:bc02 joinGroup(InetAddress) Passed: Not a multicast address STDERR: java.lang.Exception: 1 test(s) failed - see log file. at MulticastAddresses.runTest(MulticastAddresses.java:93) at MulticastAddresses.main(MulticastAddresses.java:138) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.Exception JavaTest Message: shutting down test TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. I connected debbuger and got this stack trace: java.net.NoRouteToHostException: No route to host: no further information at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) at java.base/sun.nio.ch.Net.join6(Net.java:734) at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) at MulticastAddresses.runTest(MulticastAddresses.java:56) at MulticastAddresses.main(MulticastAddresses.java:138) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) Not sure what actual cause. Will investigate further. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:09:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:09:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: Message-ID: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> On Mon, 8 Feb 2021 16:39:55 GMT, Julia Boes wrote: >> The other security-related code changes look good to me. > > I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. > As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33) and checked tier2 and tier3. What I got: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier2 3698 3690 6 2 << >> jtreg:test/langtools:tier2 12 11 1 0 << jtreg:test/jaxp:tier2 450 450 0 0 ============================== TEST FAILURE ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier3 1190 1188 2 0 << jtreg:test/langtools:tier3 0 0 0 0 jtreg:test/jaxp:tier3 0 0 0 0 ============================== TEST FAILURE Failed tests: tier2: java/io/File/GetXSpace.java Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : java/net/MulticastSocket/MulticastAddresses.java Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. java/net/MulticastSocket/SetLoopbackMode.java Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information java/nio/file/Files/CopyAndMove.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected java/security/AccessController/DoPrivAccompliceTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS sun/security/tools/jarsigner/TimestampCheck.java Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details sun/security/tools/keytool/DefaultOptions.java Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details jdk/jshell/ToolBasicTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 tier3: sanity/client/SwingSet/src/SwingSet2DemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 sanity/client/SwingSet/src/ColorChooserDemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:14:40 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:14:40 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> Message-ID: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> On Fri, 12 Feb 2021 21:06:24 GMT, Andrey Turbanov wrote: >> Then I tried to run tests separately: >> ## java/io/File/GetXSpace.java >> >> >> make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" >> >> STDERR: >> java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) >> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) >> at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) >> at java.base/java.io.File.toPath(File.java:2316) >> at GetXSpace.compare(GetXSpace.java:219) >> at GetXSpace.testDF(GetXSpace.java:394) >> at GetXSpace.main(GetXSpace.java:428) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.nio.file.InvalidPathException >> JavaTest Message: shutting down test >> >> STDOUT: >> --- Testing df >> C:/Programs/cygwin64 350809332 172573816 178235516 50% / >> D: 3702215676 2812548988 889666688 76% /cygdrive/d >> E: 3906885628 3544182676 362702952 91% /cygdrive/e >> F: 250057724 240917056 9140668 97% /cygdrive/f >> >> >> SecurityManager = null >> C:/Programs/cygwin64: >> df total= 359228755968 free = 0 usable = 182513168384 >> getX total= 359228755968 free = 182513168384 usable = 182513168384 >> :: >> df total= 3791068852224 free = 0 usable = 911018688512 >> getX total= 0 free = 0 usable = 0 >> >> TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> -------------------------------------------------- >> >> >> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output. > > ## java/net/MulticastSocket/MulticastAddresses.java > > make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" > > STDOUT: > Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /129.1.1.1 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Failed: No route to host: no further information > Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /0:0:0:0:0:0:0:1 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /0:0:0:0:0:0:8101:101 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /fe80:0:0:0:a00:20ff:fee5:bc02 > joinGroup(InetAddress) > Passed: Not a multicast address > STDERR: > java.lang.Exception: 1 test(s) failed - see log file. > at MulticastAddresses.runTest(MulticastAddresses.java:93) > at MulticastAddresses.main(MulticastAddresses.java:138) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.Exception > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. > > > I connected debbuger and got this stack trace: > > java.net.NoRouteToHostException: No route to host: no further information > at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) > at java.base/sun.nio.ch.Net.join6(Net.java:734) > at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) > at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) > at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) > at MulticastAddresses.runTest(MulticastAddresses.java:56) > at MulticastAddresses.main(MulticastAddresses.java:138) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > Not sure what actual cause. Will investigate further. ## java/net/MulticastSocket/SetLoopbackMode.java make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java" STDOUT: IPv6 can be used Default network interface: null Test will use multicast group: /ff01:0:0:0:0:0:0:1 NetworkInterface.getByInetAddress(grp): null STDERR: java.net.NoRouteToHostException: No route to host: no further information at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) at java.base/sun.nio.ch.Net.join6(Net.java:734) at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) at SetLoopbackMode.main(SetLoopbackMode.java:132) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information Cause looks similar to `MulticastAddresses`: virtualbox network interface: Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Failed: No route to host: no further information Will investigate futher. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:34:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:34:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 21:12:14 GMT, Andrey Turbanov wrote: >> ## java/net/MulticastSocket/MulticastAddresses.java >> >> make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" >> >> STDOUT: >> Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /129.1.1.1 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Failed: No route to host: no further information >> Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /0:0:0:0:0:0:0:1 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /0:0:0:0:0:0:8101:101 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /fe80:0:0:0:a00:20ff:fee5:bc02 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> STDERR: >> java.lang.Exception: 1 test(s) failed - see log file. >> at MulticastAddresses.runTest(MulticastAddresses.java:93) >> at MulticastAddresses.main(MulticastAddresses.java:138) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.lang.Exception >> JavaTest Message: shutting down test >> >> >> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. >> >> >> I connected debbuger and got this stack trace: >> >> java.net.NoRouteToHostException: No route to host: no further information >> at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) >> at java.base/sun.nio.ch.Net.join6(Net.java:734) >> at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) >> at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) >> at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) >> at MulticastAddresses.runTest(MulticastAddresses.java:56) >> at MulticastAddresses.main(MulticastAddresses.java:138) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> Not sure what actual cause. Will investigate further. > > ## java/net/MulticastSocket/SetLoopbackMode.java > > make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java" > > > STDOUT: > IPv6 can be used > Default network interface: null > > Test will use multicast group: /ff01:0:0:0:0:0:0:1 > NetworkInterface.getByInetAddress(grp): null > STDERR: > java.net.NoRouteToHostException: No route to host: no further information > at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) > at java.base/sun.nio.ch.Net.join6(Net.java:734) > at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) > at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) > at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) > at SetLoopbackMode.main(SetLoopbackMode.java:132) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information > > Cause looks similar to `MulticastAddresses`: virtualbox network interface: > Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Failed: No route to host: no further information > Will investigate futher. ## java/nio/file/Files/CopyAndMove.java make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java" STDOUT: Seed from RandomFactory = 704532001916725417L STDERR: dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS) dir2: .\name1900089232270637553 (NTFS) java.lang.RuntimeException: AtomicMoveNotSupportedException expected at CopyAndMove.testMove(CopyAndMove.java:369) at CopyAndMove.main(CopyAndMove.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected Checked in debugger: Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)" Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)" sameDevice = false https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:55:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:55:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 21:32:04 GMT, Andrey Turbanov wrote: >> ## java/net/MulticastSocket/SetLoopbackMode.java >> >> make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java" >> >> >> STDOUT: >> IPv6 can be used >> Default network interface: null >> >> Test will use multicast group: /ff01:0:0:0:0:0:0:1 >> NetworkInterface.getByInetAddress(grp): null >> STDERR: >> java.net.NoRouteToHostException: No route to host: no further information >> at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) >> at java.base/sun.nio.ch.Net.join6(Net.java:734) >> at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) >> at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) >> at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) >> at SetLoopbackMode.main(SetLoopbackMode.java:132) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information >> >> Cause looks similar to `MulticastAddresses`: virtualbox network interface: >> Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Failed: No route to host: no further information >> Will investigate futher. > > ## java/nio/file/Files/CopyAndMove.java > > make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java" > > STDOUT: > Seed from RandomFactory = 704532001916725417L > STDERR: > dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS) > dir2: .\name1900089232270637553 (NTFS) > java.lang.RuntimeException: AtomicMoveNotSupportedException expected > at CopyAndMove.testMove(CopyAndMove.java:369) > at CopyAndMove.main(CopyAndMove.java:74) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected > > Checked in debugger: > > Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)" > Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)" > sameDevice = false > > https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test. ## java/security/AccessController/DoPrivAccompliceTest.java make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java" STDOUT: Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712 [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712 [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712 Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log' [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712 [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712 Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560 [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560 [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560 Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log' [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 STDERR: stdout: []; stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152) at java.base/java.lang.System.getProperty(System.java:833) at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at DoPrivAccomplice.go(DoPrivAccomplice.java:30) at DoPrivTest.main(DoPrivTest.java:29) ] exitValue = 1 java.lang.RuntimeException: 'user' found in stderr at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256) at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr Looks like test is not ready for username `user`, which I use locally. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 22:15:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 22:15:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 21:53:13 GMT, Andrey Turbanov wrote: >> ## java/nio/file/Files/CopyAndMove.java >> >> make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java" >> >> STDOUT: >> Seed from RandomFactory = 704532001916725417L >> STDERR: >> dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS) >> dir2: .\name1900089232270637553 (NTFS) >> java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> at CopyAndMove.testMove(CopyAndMove.java:369) >> at CopyAndMove.main(CopyAndMove.java:74) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> >> Checked in debugger: >> >> Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)" >> Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)" >> sameDevice = false >> >> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test. > > ## java/security/AccessController/DoPrivAccompliceTest.java > > make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java" > > STDOUT: > Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar > > Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar > Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar > > Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar > Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar > Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] > [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712 > [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712 > [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712 > Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log' > [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712 > [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712 > Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar > Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] > [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560 > [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560 > [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560 > Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log' > [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 > [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 > [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 > [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 > STDERR: > stdout: []; > stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read") > at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) > at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152) > at java.base/java.lang.System.getProperty(System.java:833) > at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) > at DoPrivAccomplice.go(DoPrivAccomplice.java:30) > at DoPrivTest.main(DoPrivTest.java:29) > ] > exitValue = 1 > > java.lang.RuntimeException: 'user' found in stderr > > at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256) > at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr > > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr > > Looks like test is not ready for username `user`, which I use locally. ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java" STDOUT: [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]... [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)] [00:56:54.682] Create: UnicodeArgsTest.test8246042(true) [00:56:54.684] Create: UnicodeArgsTest.test8246042(false) [00:56:54.688] [ RUN ] UnicodeArgsTest.test8246042(false) [00:56:54.693] TRACE: Test string code points: [0x00e9] [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... [00:56:55.996] TRACE: exec: Done. Exit code: 0 [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)... [00:56:56.188] TRACE: exec: Done. Exit code: 0 [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)... [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output [00:57:07.680] Command: jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instrume nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files [00:57:07.680] Output: WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign [00:57:07.681] Returned: 0 [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224". [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). [00:57:07.746] Succeeded in building Windows Application Image package [00:57:07.748] TRACE: exec: Done. Exit code: 0 [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml) [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file [00:57:07.780] TRACE: Clearing PATH in environment [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]... hello: Environment supports a display hello: Environment supports a desktop [0x0065] jpackage test application args.length: 1 e hello: Output file: [appOutput.txt] [00:57:09.302] TRACE: exec: Done. Exit code: 0 [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application) [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1) [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file [00:57:09.308] [ FAILED ] UnicodeArgsTest.test8246042(false); checks=15 [00:57:09.310] [ RUN ] UnicodeArgsTest.test8246042(true) [00:57:09.312] TRACE: Test string code points: [0x00e9] [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... [00:57:09.658] TRACE: exec: Done. Exit code: 0 [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)... [00:57:09.667] TRACE: exec: Done. Exit code: 0 [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)... [00:57:09.670] jpackage argument list: [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose] [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output [00:57:18.770] Command: jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrume nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files [00:57:18.770] Output: WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign [00:57:18.770] Returned: 0 [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275". [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). [00:57:18.787] Succeeded in building Windows Application Image package [00:57:18.788] TRACE: exec: Done. Exit code: 0 [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml) [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file [00:57:18.808] TRACE: Clearing PATH in environment [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]... hello: Environment supports a display hello: Environment supports a desktop [0x0065] jpackage test application args.length: 1 e hello: Output file: [appOutput.txt] [00:57:20.327] TRACE: exec: Done. Exit code: 0 [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application) [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1) [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file [00:57:20.331] [ FAILED ] UnicodeArgsTest.test8246042(true); checks=15 [00:57:20.332] [==========] 2 tests ran [00:57:20.333] [ PASSED ] 0 tests [00:57:20.334] [ FAILED ] 2 tests, listed below [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070] [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11] [00:57:20.336] 2 FAILED TESTS STDERR: java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file at jdk.jpackage.test.TKit.error(TKit.java:293) at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.TKit.runTests(TKit.java:136) at jdk.jpackage.test.Main.runTests(Main.java:79) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.Main.main(Main.java:75) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file at jdk.jpackage.test.TKit.error(TKit.java:293) at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.TKit.runTests(TKit.java:136) at jdk.jpackage.test.Main.runTests(Main.java:79) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.Main.main(Main.java:75) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.Main.main(Main.java:75) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: java.lang.RuntimeException: 2 FAILED TESTS at jdk.jpackage.test.Main.reportSummary(Main.java:130) at jdk.jpackage.test.Main.runTests(Main.java:90) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) ... 8 more JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS Oh. This one is tricky. Will investigate later. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From ascarpino at openjdk.java.net Sat Feb 13 03:05:02 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Sat, 13 Feb 2021 03:05:02 GMT Subject: RFR: 8261462: GCM ByteBuffer decryption problems [v2] In-Reply-To: References: Message-ID: > Hi, > > I need a review of these two simple fixes. One just sets the input bytebuffer position to the limit upon completion of decryption. The second calls the CipherCore method to clear the state from the previous operation. > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: add gcmincrementdirect4 fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2487/files - new: https://git.openjdk.java.net/jdk/pull/2487/files/274a0c67..b9aa4914 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2487&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2487&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2487.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2487/head:pull/2487 PR: https://git.openjdk.java.net/jdk/pull/2487 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 10:23:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 10:23:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 22:12:29 GMT, Andrey Turbanov wrote: >> ## java/security/AccessController/DoPrivAccompliceTest.java >> >> make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java" >> >> STDOUT: >> Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar >> >> Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar >> Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar >> >> Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar >> Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar >> Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\ windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] >> [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712 >> [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712 >> [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712 >> Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log' >> [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712 >> [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712 >> Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar >> Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\ windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] >> [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560 >> [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560 >> [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560 >> Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log' >> [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 >> [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 >> [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 >> [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 >> STDERR: >> stdout: []; >> stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read") >> at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) >> at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) >> at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) >> at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152) >> at java.base/java.lang.System.getProperty(System.java:833) >> at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) >> at DoPrivAccomplice.go(DoPrivAccomplice.java:30) >> at DoPrivTest.main(DoPrivTest.java:29) >> ] >> exitValue = 1 >> >> java.lang.RuntimeException: 'user' found in stderr >> >> at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256) >> at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr >> >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr >> >> Looks like test is not ready for username `user`, which I use locally. > > ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java > > make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java" > > STDOUT: > [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]... > [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)] > [00:56:54.682] Create: UnicodeArgsTest.test8246042(true) > [00:56:54.684] Create: UnicodeArgsTest.test8246042(false) > [00:56:54.688] [ RUN ] UnicodeArgsTest.test8246042(false) > [00:56:54.693] TRACE: Test string code points: [0x00e9] > [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... > [00:56:55.996] TRACE: exec: Done. Exit code: 0 > [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code > [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)... > [00:56:56.188] TRACE: exec: Done. Exit code: 0 > [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code > [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)... > [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output > [00:57:07.680] Command: > jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instru ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files > [00:57:07.680] Output: > WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign > > [00:57:07.681] Returned: 0 > > [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). > [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224". > [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). > [00:57:07.746] Succeeded in building Windows Application Image package > [00:57:07.748] TRACE: exec: Done. Exit code: 0 > [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code > [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package > [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml) > [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists > [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory > [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists > [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file > [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable > [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists > [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file > [00:57:07.780] TRACE: Clearing PATH in environment > [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]... > hello: Environment supports a display > hello: Environment supports a desktop > [0x0065] > jpackage test application > args.length: 1 > e > hello: Output file: [appOutput.txt] > [00:57:09.302] TRACE: exec: Done. Exit code: 0 > [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code > [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists > [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file > [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file > [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application) > [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1) > [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file > [00:57:09.308] [ FAILED ] UnicodeArgsTest.test8246042(false); checks=15 > [00:57:09.310] [ RUN ] UnicodeArgsTest.test8246042(true) > [00:57:09.312] TRACE: Test string code points: [0x00e9] > [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... > [00:57:09.658] TRACE: exec: Done. Exit code: 0 > [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code > [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)... > [00:57:09.667] TRACE: exec: Done. Exit code: 0 > [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code > [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)... > [00:57:09.670] > jpackage argument list: > [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose] > > [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output > [00:57:18.770] Command: > jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instru ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files > [00:57:18.770] Output: > WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign > > [00:57:18.770] Returned: 0 > > [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). > [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275". > [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). > [00:57:18.787] Succeeded in building Windows Application Image package > [00:57:18.788] TRACE: exec: Done. Exit code: 0 > [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code > [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package > [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml) > [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists > [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory > [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists > [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file > [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable > [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists > [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file > [00:57:18.808] TRACE: Clearing PATH in environment > [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]... > hello: Environment supports a display > hello: Environment supports a desktop > [0x0065] > jpackage test application > args.length: 1 > e > hello: Output file: [appOutput.txt] > [00:57:20.327] TRACE: exec: Done. Exit code: 0 > [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code > [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists > [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file > [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file > [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application) > [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1) > [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file > [00:57:20.331] [ FAILED ] UnicodeArgsTest.test8246042(true); checks=15 > [00:57:20.332] [==========] 2 tests ran > [00:57:20.333] [ PASSED ] 0 tests > [00:57:20.334] [ FAILED ] 2 tests, listed below > [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070] > [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11] > [00:57:20.336] 2 FAILED TESTS > STDERR: > java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file > at jdk.jpackage.test.TKit.error(TKit.java:293) > at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) > at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) > at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) > at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) > at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) > at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) > at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.TKit.runTests(TKit.java:136) > at jdk.jpackage.test.Main.runTests(Main.java:79) > at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.Main.main(Main.java:75) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file > at jdk.jpackage.test.TKit.error(TKit.java:293) > at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) > at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) > at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) > at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) > at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) > at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) > at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.TKit.runTests(TKit.java:136) > at jdk.jpackage.test.Main.runTests(Main.java:79) > at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.Main.main(Main.java:75) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.Main.main(Main.java:75) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.RuntimeException: 2 FAILED TESTS > at jdk.jpackage.test.Main.reportSummary(Main.java:130) > at jdk.jpackage.test.Main.runTests(Main.java:90) > at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > ... 8 more > > JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > > Oh. This one is tricky. Will investigate later. This fours tests pass without problems, when I run them separately. ## sun/security/tools/jarsigner/TimestampCheck.java ## sun/security/tools/keytool/DefaultOptions.java ## sanity/client/SwingSet/src/ColorChooserDemoTest.java ## sanity/client/SwingSet/src/SwingSet2DemoTest.java make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" Building target 'test' in configuration 'windows-x86_64-server-release' Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' Passed: sun/security/tools/jarsigner/TimestampCheck.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' Passed: sun/security/tools/keytool/DefaultOptions.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java 1 1 0 0 jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java 1 1 0 0 jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java 1 1 0 0 jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java 1 1 0 0 ============================== TEST SUCCESS Finished building target 'test' in configuration 'windows-x86_64-server-release' ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 10:59:38 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 10:59:38 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Sat, 13 Feb 2021 10:20:29 GMT, Andrey Turbanov wrote: >> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java >> >> make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java" >> >> STDOUT: >> [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]... >> [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)] >> [00:56:54.682] Create: UnicodeArgsTest.test8246042(true) >> [00:56:54.684] Create: UnicodeArgsTest.test8246042(false) >> [00:56:54.688] [ RUN ] UnicodeArgsTest.test8246042(false) >> [00:56:54.693] TRACE: Test string code points: [0x00e9] >> [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... >> [00:56:55.996] TRACE: exec: Done. Exit code: 0 >> [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code >> [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)... >> [00:56:56.188] TRACE: exec: Done. Exit code: 0 >> [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code >> [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)... >> [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output >> [00:57:07.680] Command: >> jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instr ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files >> [00:57:07.680] Output: >> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign >> >> [00:57:07.681] Returned: 0 >> >> [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). >> [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224". >> [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). >> [00:57:07.746] Succeeded in building Windows Application Image package >> [00:57:07.748] TRACE: exec: Done. Exit code: 0 >> [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code >> [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package >> [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml) >> [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists >> [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory >> [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists >> [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file >> [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable >> [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists >> [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file >> [00:57:07.780] TRACE: Clearing PATH in environment >> [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]... >> hello: Environment supports a display >> hello: Environment supports a desktop >> [0x0065] >> jpackage test application >> args.length: 1 >> e >> hello: Output file: [appOutput.txt] >> [00:57:09.302] TRACE: exec: Done. Exit code: 0 >> [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code >> [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists >> [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file >> [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file >> [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application) >> [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1) >> [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file >> [00:57:09.308] [ FAILED ] UnicodeArgsTest.test8246042(false); checks=15 >> [00:57:09.310] [ RUN ] UnicodeArgsTest.test8246042(true) >> [00:57:09.312] TRACE: Test string code points: [0x00e9] >> [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... >> [00:57:09.658] TRACE: exec: Done. Exit code: 0 >> [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code >> [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)... >> [00:57:09.667] TRACE: exec: Done. Exit code: 0 >> [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code >> [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)... >> [00:57:09.670] >> jpackage argument list: >> [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose] >> >> [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output >> [00:57:18.770] Command: >> jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instr ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files >> [00:57:18.770] Output: >> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign >> >> [00:57:18.770] Returned: 0 >> >> [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). >> [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275". >> [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). >> [00:57:18.787] Succeeded in building Windows Application Image package >> [00:57:18.788] TRACE: exec: Done. Exit code: 0 >> [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code >> [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package >> [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml) >> [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists >> [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory >> [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists >> [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file >> [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable >> [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists >> [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file >> [00:57:18.808] TRACE: Clearing PATH in environment >> [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]... >> hello: Environment supports a display >> hello: Environment supports a desktop >> [0x0065] >> jpackage test application >> args.length: 1 >> e >> hello: Output file: [appOutput.txt] >> [00:57:20.327] TRACE: exec: Done. Exit code: 0 >> [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code >> [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists >> [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file >> [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file >> [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application) >> [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1) >> [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file >> [00:57:20.331] [ FAILED ] UnicodeArgsTest.test8246042(true); checks=15 >> [00:57:20.332] [==========] 2 tests ran >> [00:57:20.333] [ PASSED ] 0 tests >> [00:57:20.334] [ FAILED ] 2 tests, listed below >> [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070] >> [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11] >> [00:57:20.336] 2 FAILED TESTS >> STDERR: >> java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file >> at jdk.jpackage.test.TKit.error(TKit.java:293) >> at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) >> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) >> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) >> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) >> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) >> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) >> at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) >> at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) >> at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) >> at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) >> at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) >> at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) >> at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.TKit.runTests(TKit.java:136) >> at jdk.jpackage.test.Main.runTests(Main.java:79) >> at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.Main.main(Main.java:75) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file >> at jdk.jpackage.test.TKit.error(TKit.java:293) >> at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) >> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) >> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) >> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) >> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) >> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) >> at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) >> at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) >> at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) >> at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) >> at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) >> at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) >> at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.TKit.runTests(TKit.java:136) >> at jdk.jpackage.test.Main.runTests(Main.java:79) >> at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.Main.main(Main.java:75) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.Main.main(Main.java:75) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: java.lang.RuntimeException: 2 FAILED TESTS >> at jdk.jpackage.test.Main.reportSummary(Main.java:130) >> at jdk.jpackage.test.Main.runTests(Main.java:90) >> at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> ... 8 more >> >> JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> >> Oh. This one is tricky. Will investigate later. > > This fours tests pass without problems, when I run them separately. > > ## sun/security/tools/jarsigner/TimestampCheck.java > ## sun/security/tools/keytool/DefaultOptions.java > ## sanity/client/SwingSet/src/ColorChooserDemoTest.java > ## sanity/client/SwingSet/src/SwingSet2DemoTest.java > > make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" > > Building target 'test' in configuration 'windows-x86_64-server-release' > Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: > * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java > * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java > * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java > * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java > > Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' > Passed: sun/security/tools/jarsigner/TimestampCheck.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java > Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java > > Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' > Passed: sun/security/tools/keytool/DefaultOptions.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java > Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java > > Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' > Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java > Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java > > Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' > Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java > Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java > 1 1 0 0 > jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java > 1 1 0 0 > jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java > 1 1 0 0 > jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java > 1 1 0 0 > ============================== > TEST SUCCESS > > Finished building target 'test' in configuration 'windows-x86_64-server-release' ## jdk/jshell/ToolBasicTest.java make test TEST="jtreg:jdk/jshell/ToolBasicTest.java" STDOUT: [TestNG] Running: jdk/jshell/ToolBasicTest.java config ReplToolTesting.setUp(): success test ToolBasicTest.elideStartUpFromList(): success config ReplToolTesting.setUp(): success test ToolBasicTest.elideStartUpFromSave(): success config ReplToolTesting.setUp(): success test ToolBasicTest.test8142447(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testAddExports(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testBadClasspath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testBadModulePath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testBadSourceJarClasspath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testClasspathDirectory(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testClasspathJar(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testClasspathUserHomeExpansion(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testConstrainedUpdates(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testCtrlD(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testEnvInStartUp(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testFeedbackNegative(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testFeedbackNormal(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testFeedbackSilent(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testHistoryReference(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testIndent(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testInterrupt(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testLoadingFromArgs(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testModulePath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testModulePathUserHomeExpansion(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpen(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpenFileOverHttp(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpenLocalFileUrl(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpenResource(): failure java.lang.AssertionError: user output: printf("%4.2f", Math.PI). expected [3.14] but found [3,14] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:496) at org.testng.Assert.assertEquals(Assert.java:125) at org.testng.Assert.assertEquals(Assert.java:178) at ReplToolTesting.assertOutput(ReplToolTesting.java:529) at ReplToolTesting.assertCommand(ReplToolTesting.java:513) at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559) at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824) at java.base/java.io.PrintStream.write(PrintStream.java:536) at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253) at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294) at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242) at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321) at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325) at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159) at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248) at java.base/java.io.PrintWriter.flush(PrintWriter.java:396) at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174) at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) at ReplToolTesting.testRawRun(ReplToolTesting.java:313) at ReplToolTesting.testRaw(ReplToolTesting.java:296) at ReplToolTesting.test(ReplToolTesting.java:249) at ReplToolTesting.test(ReplToolTesting.java:233) at ReplToolTesting.test(ReplToolTesting.java:229) at ReplToolTesting.test(ReplToolTesting.java:225) at ToolBasicTest.testOpenResource(ToolBasicTest.java:555) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) config ReplToolTesting.setUp(): success test ToolBasicTest.testRedeclareVariableNoInit(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testRemoteExit(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testRerun(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testRerunIdRange(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testReset(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testSave(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStartRetain(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStartSave(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStartupFileOption(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStop(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testVarsWithNotActive(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testWarningUnchecked(): success =============================================== jdk/jshell/ToolBasicTest.java Total tests run: 38, Failures: 1, Skips: 0 =============================================== STDERR: java.io.EOFException at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398) at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381) at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113) at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277) at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99) at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160) at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943) at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139) at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) at ReplToolTesting.testRawRun(ReplToolTesting.java:313) at ReplToolTesting.testRaw(ReplToolTesting.java:296) at ReplToolTesting.test(ReplToolTesting.java:249) at ReplToolTesting.test(ReplToolTesting.java:233) at ReplToolTesting.test(ReplToolTesting.java:229) at ReplToolTesting.test(ReplToolTesting.java:225) at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) java.lang.Exception: failures: 1 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.Exception JavaTest Message: shutting down test TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 15:06:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 15:06:41 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Added table of available algorithms. src/java.base/share/classes/java/util/Random.java line 29: > 27: > 28: import java.io.*; > 29: import java.math.BigInteger; This import is not actually used ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 15:10:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 15:10:42 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Added table of available algorithms. src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 115: > 113: static final String BAD_BOUND = "bound must be positive"; > 114: static final String BAD_FLOATING_BOUND = "bound must be finite and positive"; > 115: static final String BAD_RANGE = "bound must be greater than origin"; Unused fields in Random class now can be cleaned up: `java.util.Random#BadRange`, `java.util.Random#BadSize` ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From alanb at openjdk.java.net Sat Feb 13 17:30:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 13 Feb 2021 17:30:39 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). ------------- PR: https://git.openjdk.java.net/jdk/pull/2540 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 21:34:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 21:34:42 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Added table of available algorithms. src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 149: > 147: */ > 148: public static void checkJumpDistance(double distance) { > 149: if (!(distance > 0.0 && distance < Float.POSITIVE_INFINITY I wounder if this usage of `Float.POSITIVE_INFINITY` intentional here? Looks a bit suspicious for comparison with `double` argument src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1548: > 1546: * @return a stream of (pseudo)randomly chosen {@code int} values > 1547: */ > 1548: Is `@Override` intentionally omitted? src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1943: > 1941: > 1942: // IllegalArgumentException messages > 1943: static final String BadLogDistance = "logDistance must be non-negative"; seems unused test/jdk/java/util/Random/RandomTestBsi1999.java line 227: > 225: static int checkRunStats(int[] stats) { > 226: int runFailure = 0; > 227: runFailure |= ((2267 <= stats[1]) || (stats[1] <= 2733)) ? 0 : 1; 1. confusing formatting. 2. This condition is always `true`. Looks like `&&` should be used instead of `||` ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From alanb at openjdk.java.net Mon Feb 15 11:49:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 15 Feb 2021 11:49:38 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov wrote: >> This fours tests pass without problems, when I run them separately. >> >> ## sun/security/tools/jarsigner/TimestampCheck.java >> ## sun/security/tools/keytool/DefaultOptions.java >> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java >> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java >> >> make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" >> >> Building target 'test' in configuration 'windows-x86_64-server-release' >> Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: >> * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> >> Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Passed: sun/security/tools/jarsigner/TimestampCheck.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> >> Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Passed: sun/security/tools/keytool/DefaultOptions.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> 1 1 0 0 >> jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> Finished building target 'test' in configuration 'windows-x86_64-server-release' > > ## jdk/jshell/ToolBasicTest.java > > make test TEST="jtreg:jdk/jshell/ToolBasicTest.java" > > STDOUT: > [TestNG] Running: > jdk/jshell/ToolBasicTest.java > > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromList(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.test8142447(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testAddExports(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadSourceJarClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathDirectory(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathJar(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testConstrainedUpdates(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testCtrlD(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testEnvInStartUp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNegative(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNormal(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackSilent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testHistoryReference(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testIndent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testInterrupt(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testLoadingFromArgs(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpen(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenFileOverHttp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenLocalFileUrl(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenResource(): failure > java.lang.AssertionError: user output: printf("%4.2f", Math.PI). > expected [3.14] but found [3,14] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at ReplToolTesting.assertOutput(ReplToolTesting.java:529) > at ReplToolTesting.assertCommand(ReplToolTesting.java:513) > at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559) > at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824) > at java.base/java.io.PrintStream.write(PrintStream.java:536) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294) > at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242) > at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321) > at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325) > at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159) > at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248) > at java.base/java.io.PrintWriter.flush(PrintWriter.java:396) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174) > at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) > at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testOpenResource(ToolBasicTest.java:555) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRedeclareVariableNoInit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRemoteExit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerun(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerunIdRange(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testReset(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartRetain(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartupFileOption(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStop(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testVarsWithNotActive(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testWarningUnchecked(): success > > =============================================== > jdk/jshell/ToolBasicTest.java > Total tests run: 38, Failures: 1, Skips: 0 > =============================================== > > STDERR: > java.io.EOFException > at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398) > at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381) > at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99) > at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.Exception: failures: 1 > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.Exception > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test. @turbanoff Can you run the tests in the en_US locale? I suspect some of these tests can't run in all locales. Also can you check your environment to ensure the file paths for F: are consistent (I suspect you have a mix of f: and F: in the environment). ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From burban at openjdk.java.net Mon Feb 15 16:24:48 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 15 Feb 2021 16:24:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 12:22:09 GMT, Vladimir Kempik wrote: >> Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. > > This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds. > @lewurm could you comment here please Those values can be observed in the debugger, but aren't documented or defined in header files. This mode was useful for the initial bootstrap of the platform (it helped with missing W^X transitions), but shouldn't be required anymore today. I'm fine with removing it altogether. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 17:34:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 17:34:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v14] In-Reply-To: References: Message-ID: <6SmGFRbH6_SgIW-aRpEIrRnfsv-BI2nmDUffhObbyu8=.e4979c82-2bfb-4932-b980-d261d7a55f74@github.com> > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Redo buildsys fix - ... and 63 more: https://git.openjdk.java.net/jdk/compare/40ae9937...4094f351 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=13 Stats: 3066 lines in 84 files changed: 2954 ins; 47 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 17:45:07 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 17:45:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits: - Pull/2200 (#5) * bsd_aarch64 cleanup * remove the actual attribute too * Refactor bailing out on nativeWrapper generation * rename c_call_conv_priv function - Merge branch 'master' into jdk-macos - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - ... and 65 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...a9452a4c ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=14 Stats: 3032 lines in 83 files changed: 2919 ins; 47 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 17:48:48 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 17:48:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15] In-Reply-To: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> References: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> Message-ID: On Sun, 31 Jan 2021 20:08:01 GMT, Vladimir Kempik wrote: >> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. > > Hello > Does this look like something in the right direction ? > > https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49 The latest merge with JDK-8261071 should resolve the issue. Please take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Feb 15 18:03:55 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 15 Feb 2021 18:03:55 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 18:44:48 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: >> >> - Merge branch 'master' into jdk-macos >> - Update copyright year for BsdAARCH64ThreadContext.java >> - Fix inclusing of StubRoutines header >> - Redo buildsys fix >> - Revert harfbuzz changes, disable warnings for it >> - Little adjustement of SlowSignatureHandler >> - Partially bring previous commit >> - Revert "Address feedback for signature generators" >> >> This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin >> - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: > >> 837: // The code unable to handle this, bailout. >> 838: return -1; >> 839: #endif > > This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention. Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Feb 15 18:03:51 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 15 Feb 2021 18:03:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:52:47 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810: > >> 808: #ifdef __APPLE__ >> 809: // Less-than word types are stored one after another. >> 810: // The code unable to handle this, bailout. > > Perhaps: // The code is unable to handle this so bailout. Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 18:03:56 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 18:03:56 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:08:41 GMT, Anton Kozlov wrote: > I'm going to do as much refactoring as needed before this patch under JDK-8261071 The recent merge resolves inconsitency between pass_byte/pass_short and other methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 18:10:09 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 18:10:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v16] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #6 from VladimirKempik/pull/2200 Fix typo in comments - Fix typo in comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/a9452a4c..419c2b1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From jboes at openjdk.java.net Mon Feb 15 18:18:39 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Feb 2021 18:18:39 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov wrote: >> This fours tests pass without problems, when I run them separately. >> >> ## sun/security/tools/jarsigner/TimestampCheck.java >> ## sun/security/tools/keytool/DefaultOptions.java >> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java >> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java >> >> make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" >> >> Building target 'test' in configuration 'windows-x86_64-server-release' >> Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: >> * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> >> Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Passed: sun/security/tools/jarsigner/TimestampCheck.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> >> Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Passed: sun/security/tools/keytool/DefaultOptions.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> 1 1 0 0 >> jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> Finished building target 'test' in configuration 'windows-x86_64-server-release' > > ## jdk/jshell/ToolBasicTest.java > > make test TEST="jtreg:jdk/jshell/ToolBasicTest.java" > > STDOUT: > [TestNG] Running: > jdk/jshell/ToolBasicTest.java > > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromList(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.test8142447(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testAddExports(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadSourceJarClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathDirectory(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathJar(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testConstrainedUpdates(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testCtrlD(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testEnvInStartUp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNegative(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNormal(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackSilent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testHistoryReference(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testIndent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testInterrupt(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testLoadingFromArgs(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpen(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenFileOverHttp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenLocalFileUrl(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenResource(): failure > java.lang.AssertionError: user output: printf("%4.2f", Math.PI). > expected [3.14] but found [3,14] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at ReplToolTesting.assertOutput(ReplToolTesting.java:529) > at ReplToolTesting.assertCommand(ReplToolTesting.java:513) > at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559) > at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824) > at java.base/java.io.PrintStream.write(PrintStream.java:536) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294) > at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242) > at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321) > at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325) > at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159) > at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248) > at java.base/java.io.PrintWriter.flush(PrintWriter.java:396) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174) > at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) > at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testOpenResource(ToolBasicTest.java:555) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRedeclareVariableNoInit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRemoteExit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerun(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerunIdRange(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testReset(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartRetain(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartupFileOption(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStop(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testVarsWithNotActive(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testWarningUnchecked(): success > > =============================================== > jdk/jshell/ToolBasicTest.java > Total tests run: 38, Failures: 1, Skips: 0 > =============================================== > > STDERR: > java.io.EOFException > at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398) > at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381) > at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99) > at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.Exception: failures: 1 > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.Exception > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test. Hi @turbanoff, I ran tier 1-3 in our build and test system and can't reproduce the errors, they seem to be specific to the environment, as Alan hinted at. I also ran the jdk_jfr tests, which came back all clear. On another note, let's drop the change in sun.net.www.MimeLauncher, it's a jdk-internal class that is no longer used and can likely be removed. I opened a separate issue for that: https://bugs.openjdk.java.net/browse/JDK-8261750. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From akozlov at openjdk.java.net Mon Feb 15 18:24:08 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 18:24:08 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v17] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - Removed unused variables ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/419c2b1a..90e244e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=15-16 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 15 18:33:00 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Feb 2021 18:33:00 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: References: Message-ID: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes from MimeLauncher ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6a8a3ae6..6614a10f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=08-09 Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From mcimadamore at openjdk.java.net Mon Feb 15 18:53:42 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 15 Feb 2021 18:53:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> References: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> Message-ID: On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes from MimeLauncher The changes to sjavac changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1853 From aph at openjdk.java.net Mon Feb 15 19:10:47 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 15 Feb 2021 19:10:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 18:00:50 GMT, Vladimir Kempik wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: >> >>> 837: // The code unable to handle this, bailout. >>> 838: return -1; >>> 839: #endif >> >> This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention. > > Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c. I don't understand why you think it's acceptable to bail in this case. Can you explain, please? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+7693005+jarviscraft at openjdk.java.net Mon Feb 15 19:22:41 2021 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Mon, 15 Feb 2021 19:22:41 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: <6Kww4QHiltSEaYOr-gkm0l9HIfIPfIwT7jEW50PxgsY=.5a2ee8ae-e2ab-4945-94b1-8b94ccad83bf@github.com> On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > >> >> >> @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! > @JarvisCraft Can you re-run your benchmarks in light of the changes that @cl4es pointed out in the previous comment? We think this PR can be closed. My apologies for the late reply, I'll try re-running these with the merged branch ASAP (the delay is due to me changing the workstation thus having some job to reconfigure the environment). ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From alanb at openjdk.java.net Mon Feb 15 19:25:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 15 Feb 2021 19:25:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> References: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> Message-ID: On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes from MimeLauncher src/java.management/share/classes/javax/management/loading/MLet.java line 1149: > 1147: file.deleteOnExit(); > 1148: Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING); > 1149: if (file.exists()) { You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 15 19:47:00 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Feb 2021 19:47:00 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo remove unnecessary file.exists() check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6614a10f..6e71e961 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=09-10 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 15 19:47:01 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Feb 2021 19:47:01 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: References: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> Message-ID: <7bSIORe_urCOaP-rcSwcaRkhFU0rymCRLOk5s3t3PF4=.c340769a-e407-44c1-8704-fc7ea5eb7411@github.com> On Mon, 15 Feb 2021 19:23:16 GMT, Alan Bateman wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes from MimeLauncher > > src/java.management/share/classes/javax/management/loading/MLet.java line 1149: > >> 1147: file.deleteOnExit(); >> 1148: Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING); >> 1149: if (file.exists()) { > > You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds. You are right. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From vkempik at openjdk.java.net Tue Feb 16 06:26:46 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 16 Feb 2021 06:26:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 19:07:40 GMT, Andrew Haley wrote: >> Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered > > This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c. > I don't understand why you think it's acceptable to bail in this case. Can you explain, please? it's for everything that uses less than 8 bytes on a stack( ints ( 4), shorts(2), bytes(1), floats(4)). currently native wrapper generation does not support such cases at all, it needs refactoring before this can be implemented. So when a method has more argument than can be placed in registers, we may have issues. So we just bailing out to interpreter in case when a smaller (<=4 b) type is going to be passed thru the stack. There was attempt to implement handling such cases but currently it requires some hacks (like using some vectors for non-specific task) - https://github.com/openjdk/aarch64-port/pull/3 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From alanb at openjdk.java.net Tue Feb 16 07:42:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Feb 2021 07:42:40 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > remove unnecessary file.exists() check Thanks for perceiving with this one. I think you've addressed all issues in the latest revision. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1853 From mbaesken at openjdk.java.net Tue Feb 16 08:45:40 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 16 Feb 2021 08:45:40 GMT Subject: Integrated: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. > > Sonar reports : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG > > Potential leak of memory pointed to by 'newBuf' > I adjusted the early return and added freeing memory . > > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? This pull request has now been integrated. Changeset: cdc874d4 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/cdc874d4 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 Reviewed-by: clanger, dfuchs, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/2540 From alanb at openjdk.java.net Tue Feb 16 08:45:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Feb 2021 08:45:39 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: References: Message-ID: <7E0Hd5FKbUwTglHpp288NGPFa1mB94Vc-NZPVpV2BIw=.daa92406-037d-4b97-8050-d1f1aa9aa41c@github.com> On Sat, 13 Feb 2021 17:27:47 GMT, Alan Bateman wrote: >> There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. >> >> Sonar reports : >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG >> >> Potential leak of memory pointed to by 'newBuf' >> I adjusted the early return and added freeing memory . >> >> >> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? > >> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? > > Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). I see this has been integrated but the fix is incomplete. Are you planning to create a follow-on issue for the issues that I pointed out above? ------------- PR: https://git.openjdk.java.net/jdk/pull/2540 From mbaesken at openjdk.java.net Tue Feb 16 08:52:39 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 16 Feb 2021 08:52:39 GMT Subject: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 In-Reply-To: <7E0Hd5FKbUwTglHpp288NGPFa1mB94Vc-NZPVpV2BIw=.daa92406-037d-4b97-8050-d1f1aa9aa41c@github.com> References: <7E0Hd5FKbUwTglHpp288NGPFa1mB94Vc-NZPVpV2BIw=.daa92406-037d-4b97-8050-d1f1aa9aa41c@github.com> Message-ID: On Tue, 16 Feb 2021 08:42:42 GMT, Alan Bateman wrote: > I see this has been integrated but the fix is incomplete. Are you planning to create a follow-on issue for the issues that I pointed out above? Hi Alan, thanks about your comment to my question about handleSendFailed . I opened a follow-on for this : https://bugs.openjdk.java.net/browse/JDK-8261791 Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/2540 From mbaesken at openjdk.java.net Tue Feb 16 12:31:46 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 16 Feb 2021 12:31:46 GMT Subject: RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks Message-ID: In another bug this question from m was answered by Alan Bateman : -------------------------------- Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? -------------------------------- Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). -------------------------------- So I added freeing of the malloced memory to handleSendFailed . Please review ! Thanks, Matthias ------------- Commit messages: - JDK-8261791 Changes: https://git.openjdk.java.net/jdk/pull/2586/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2586&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261791 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2586/head:pull/2586 PR: https://git.openjdk.java.net/jdk/pull/2586 From jlaskey at openjdk.java.net Tue Feb 16 14:06:56 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 16 Feb 2021 14:06:56 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 15:03:53 GMT, Andrey Turbanov wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Added table of available algorithms. > > src/java.base/share/classes/java/util/Random.java line 29: > >> 27: >> 28: import java.io.*; >> 29: import java.math.BigInteger; > > This import is not actually used good > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 115: > >> 113: static final String BAD_BOUND = "bound must be positive"; >> 114: static final String BAD_FLOATING_BOUND = "bound must be finite and positive"; >> 115: static final String BAD_RANGE = "bound must be greater than origin"; > > Unused fields in Random class now can be cleaned up: `java.util.Random#BadRange`, `java.util.Random#BadSize` Good > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 149: > >> 147: */ >> 148: public static void checkJumpDistance(double distance) { >> 149: if (!(distance > 0.0 && distance < Float.POSITIVE_INFINITY > > I wounder if this usage of `Float.POSITIVE_INFINITY` intentional here? Looks a bit suspicious for comparison with `double` argument Turns out the method is no longer used. > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1548: > >> 1546: * @return a stream of (pseudo)randomly chosen {@code int} values >> 1547: */ >> 1548: > > Is `@Override` intentionally omitted? The interface method is a default method, so not technically an override. > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1943: > >> 1941: >> 1942: // IllegalArgumentException messages >> 1943: static final String BadLogDistance = "logDistance must be non-negative"; > > seems unused Good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From vkempik at openjdk.java.net Tue Feb 16 14:09:54 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 16 Feb 2021 14:09:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <44L8Jccum5-J3RntkBsRZJ5daAJ-X1tYt_4xspIbP6U=.4dd53895-2fb7-4396-82e1-8387828bcdbf@github.com> On Thu, 4 Feb 2021 22:49:23 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297: > >> 295: stub = SharedRuntime::handle_unsafe_access(thread, next_pc); >> 296: } >> 297: } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) { > > Can we add a comment here describing what this case means? This was added as part of this commit ( to linux_aarch64) - https://github.com/openjdk/jdk/commit/339d52600b285eb3bc57d9ff107567d4424efeb1 @gerard-ziemski do we really want to add anything new here ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+828220+forax at openjdk.java.net Tue Feb 16 15:56:48 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 16 Feb 2021 15:56:48 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 14:03:56 GMT, Jim Laskey wrote: >> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1548: >> >>> 1546: * @return a stream of (pseudo)randomly chosen {@code int} values >>> 1547: */ >>> 1548: >> >> Is `@Override` intentionally omitted? > > The interface method is a default method, so not technically an override. It's not an override but @Override has a broader semantics than just overriding an existing method. Given that it helps to understand that this method is part of a larger algorithm, i think this method should be tagged with @Override ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Tue Feb 16 16:21:43 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 16 Feb 2021 16:21:43 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 15:54:08 GMT, R?mi Forax wrote: >> The interface method is a default method, so not technically an override. > > It's not an override but @Override has a broader semantics than just overriding an existing method. > Given that it helps to understand that this method is part of a larger algorithm, i think this method should be tagged with @Override Okay ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jboes at openjdk.java.net Tue Feb 16 17:23:42 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 16 Feb 2021 17:23:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: Message-ID: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From jnimeh at openjdk.java.net Tue Feb 16 17:43:41 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 16 Feb 2021 17:43:41 GMT Subject: Integrated: 8248223: KeyAgreement spec update on multi-party key exchange support In-Reply-To: References: Message-ID: <-fnmb5bNN-wncYe3cVGYJXn_5XCYlU5WaAHARUrgqZ0=.c785030a-3c98-432c-84d3-d30064954581@github.com> On Wed, 10 Feb 2021 16:33:54 GMT, Jamil Nimeh wrote: > This is a spec-only change that clarifies the requirement on KeyAgreement implementations for multi-party support where there are 3 or more parties involved. This change states that 3+ party support is implementation-specific unless the underlying specification for that algorithm requires support for 3 or more parties. > Bug: https://bugs.openjdk.java.net/browse/JDK-8248223 > CSR: https://bugs.openjdk.java.net/browse/JDK-8261456 This pull request has now been integrated. Changeset: 6b6f7940 Author: Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/6b6f7940 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8248223: KeyAgreement spec update on multi-party key exchange support Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2512 From github.com+741251+turbanoff at openjdk.java.net Tue Feb 16 18:44:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Feb 2021 18:44:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: <04LMLK3YO1cEPtchQl39EhAgeSN2mvEdQONQg_UzLKc=.7d1ce34f-04b6-4248-ba32-efec0c24b915@github.com> On Mon, 8 Feb 2021 21:18:44 GMT, Philippe Marschall wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> fix review comments > > src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230: > >> 228: // Copy the entire input stream into an InputStream that does >> 229: // support mark >> 230: is = new ByteArrayInputStream(is.readAllBytes()); > > I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do: > > PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); Good idea. Will improve. By the way, code in `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)` looks suspicious: it reads only `InputStream.available()` bytes, which doesn't make much sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From mullan at openjdk.java.net Tue Feb 16 18:45:44 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 16 Feb 2021 18:45:44 GMT Subject: RFR: 8257497: Key identifier compliance issue [v5] In-Reply-To: <5h7yVK3O-WOeqmurzg5yRIj_I-xJLJ8iRbMl6UD5eu4=.6e0caf2c-4680-4dc8-befb-ed90bd954c90@github.com> References: <5h7yVK3O-WOeqmurzg5yRIj_I-xJLJ8iRbMl6UD5eu4=.6e0caf2c-4680-4dc8-befb-ed90bd954c90@github.com> Message-ID: <4pJxygFcGhjUhpqhhYMSsGka8pDi9M5AeptLTjmyTKg=.daa07ab0-861b-44f2-9f9a-1c3d440ffaf4@github.com> On Fri, 12 Feb 2021 20:42:03 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Reduced one param to createV3Extensions src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1484: > 1482: > 1483: KeyIdentifier signerSubjectKeyId; > 1484: if (subjectPubKey.equals(issuerPubKey)) { I think in most cases, this equality test will not work as there is no requirement for PublicKey to override Object.equals, so in most cases this will just check if they reference the same object. I suggest comparing the encoded bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From github.com+741251+turbanoff at openjdk.java.net Tue Feb 16 18:47:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Feb 2021 18:47:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com> References: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com> Message-ID: On Tue, 9 Feb 2021 11:40:09 GMT, Philippe Marschall wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> fix review comments > > src/java.base/share/classes/java/util/jar/JarInputStream.java line 93: > >> 91: if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) { >> 92: man = new Manifest(); >> 93: byte[] bytes = new BufferedInputStream(this).readAllBytes(); > > I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7. > > In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly. Usage of `BufferedInputStream` removed ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From rhalade at openjdk.java.net Tue Feb 16 18:58:44 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 16 Feb 2021 18:58:44 GMT Subject: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v5] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 12:39:54 GMT, Fernando Guallini wrote: >> The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: >> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java >> javax/net/ssl/TLSCommon/TLSTest.java >> sun/security/ssl/CipherSuite/SupportedGroups.java >> >> >> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > refactor isConnectionReset method Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From fguallini at openjdk.java.net Tue Feb 16 18:58:46 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 16 Feb 2021 18:58:46 GMT Subject: Integrated: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini wrote: > The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures: > sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java > javax/net/ssl/TLSCommon/TLSTest.java > sun/security/ssl/CipherSuite/SupportedGroups.java > > > javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged. This pull request has now been integrated. Changeset: 0a50688d Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/0a50688d Stats: 58 lines in 4 files changed: 42 ins; 7 del; 9 mod 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset Reviewed-by: dfuchs, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/2405 From github.com+741251+turbanoff at openjdk.java.net Tue Feb 16 18:58:57 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Feb 2021 18:58:57 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v12] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6e71e961..1b30471d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=10-11 Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+30433125+djelinski at openjdk.java.net Tue Feb 16 19:30:04 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Tue, 16 Feb 2021 19:30:04 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v4] In-Reply-To: References: Message-ID: > Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. > > First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. > Baseline results before any MemoryCache changes: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op > CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op > CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op > CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op > there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. > > Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op > CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op > The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. > > The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op > CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op > I wasn't expecting that much of an improvement, and don't know how to explain it. > > The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. djelinski has updated the pull request incrementally with two additional commits since the last revision: - Switch cache to FIFO order - Order of expiration should match insertion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2255/files - new: https://git.openjdk.java.net/jdk/pull/2255/files/abe0e238..c7b064f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=02-03 Stats: 33 lines in 1 file changed: 1 ins; 3 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/2255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2255/head:pull/2255 PR: https://git.openjdk.java.net/jdk/pull/2255 From github.com+30433125+djelinski at openjdk.java.net Tue Feb 16 19:41:39 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Tue, 16 Feb 2021 19:41:39 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> Message-ID: On Wed, 10 Feb 2021 19:19:33 GMT, djelinski wrote: >>> Thanks for your review! Some comments below. >>> >>> > A full handshake or OCSP status grabbing could counteract all the performance gain with the cache update. >>> >>> Yes, but that's unlikely. Note that K=3 is before K=1 in the queue only because 3 wasn't used since 1 was last used. This means that either K=3 is used less frequently than K=1, or that all cached items are in active use. In the former case we don't lose much by dropping K=3 (granted, there's nothing to offset that). In the latter we are dealing with full cache at all times, which means that most `put()`s would scan the queue, and we will gain a lot by finishing faster. >> >> I may think it differently. It may be hard to know the future frequency of an cached item based on the past behaviors. For the above case, I'm not sure that K=3 is used less frequently than K=1. Maybe, next few seconds, K=1 could be more frequently. >> >> I would like a solution to following the timeout specification: keep the newer items if possible. >> >>> >>> > get() [..] without [..] change the order of the queue >>> >>> If we do that, frequently used entries will be evicted at the same age as never used ones. This means we will have to recompute (full handshake/fresh OCSP) both the frequently used and the infrequently used entries. It's better to recompute only the infrequently used ones, and reuse the frequently used as long as possible - we will do less work that way. >>> That's probably the reason why a `LinkedHashMap` with `accessOrder=true` was chosen as the backing store implementation originally. >>> >> >> See above. It may be true for some case to determine the frequency, but Cache is a general class and we may want to be more careful about if we are really be able to determine the frequency within the Cache implementation. >> >>> > get() performance is more important [..] so we should try to keep the cache small if possible >>> >>> I don't see the link; could you explain? >>> >> >> link? Did you mean the link to get() method? It is a method in the Cache class. >> >>> > In the update, the SoftReference.clear() get removed. I'm not sure of the impact of the enqueued objects any longer. In theory, it could improve the memory use, which could counteract the performance gain in some situation. >>> >>> That's the best part: no objects ever get enqueued! We only called `clear()` right before losing the last reference to `SoftCacheEntry` (which is the `SoftReference`). When GC collects the `SoftReference`, it does not enqueue anything. GC only enqueues the `SoftReference` when it collects the referenced object (session / OCSP response) without collecting the `SoftReference` (cache entry) itself. >>> This is [documented behavior](https://docs.oracle.com/javase/7/docs/api/java/lang/ref/package-summary.html): _If a registered reference becomes unreachable itself, then it will never be enqueued._ >>> >> >> I need more time for this section. >> >>> > Could you edit the bug >>> >>> I'd need an account on the bug tracker first. >> >> Okay. No worries, I will help you if we could get an agreement about the update. > >> I may think it differently. It may be hard to know the future frequency of an cached item based on the past behaviors. For the above case, I'm not sure that K=3 is used less frequently than K=1. Maybe, next few seconds, K=1 could be more frequently. > > I agree that such prediction might not be 100% accurate. But, quick google search reveals that there are [many](https://www.usenix.org/system/files/hotstorage20_paper_eytan.pdf) [articles](https://link.springer.com/article/10.1007/PL00009255) that claim that LRU caches offer better hit rates than FIFO, especially for in-memory caches. >> I would like a solution to following the timeout specification: keep the newer items if possible. > > That's a trivial change; all we need to do is change `true` to `false` [here](https://github.com/openjdk/jdk/blob/abe0e238bd25adb1ddd2b655613899bfa063cd85/src/java.base/share/classes/sun/security/util/Cache.java#L268). But, as stated above, LRU is better than FIFO, so I wouldn't want to do that. > > I could keep LRU and add another linked list that would store items in the order of their expiration dates; then we could quickly scan that list for expired items. Note: the order of expiration dates is not necessarily the order of insertion, because 1) `System.currentTimeMillis()` is not monotonic - it can move back when something changes the system time, 2) the expiration date is calculated at insertion time, so if someone changes the timeout on a non-empty cache, new items may have shorter expiration time than old ones. So, I'd either need to address that first (change `currentTimeMillis` to `nanoTime` and store creation time instead of expiration time), or use insertion sort for adding items (which would get very slow if either of the above mentioned situations happened). > Let me know your thoughts. Well, if removing all expired items before evicting live ones is a non-negotiable, implementing all operations in constant time is much easier with FIFO, where we only need to keep one item order. The new commits contain the following changes: - use `nanoTime` instead of `currentTimeMillis` to make sure that time never goes back - store insertion time instead of expiration time, so that older items always expire before newer ones, even when timeout is changed - change internal hash map to store (and evict) items in insertion (FIFO) order - always stop scanning entries after finding the first non-expired item, because subsequent items are now guaranteed to have later expiration dates, and collected soft references are handled by reference queue. tier1 and jdk_security tests passed; benchmark results show only minimal changes. I verified that none of the classes using `Cache` mentions LRU, looks like this was an implementation detail. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From hchao at openjdk.java.net Tue Feb 16 22:13:05 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 16 Feb 2021 22:13:05 GMT Subject: RFR: 8257497: Key identifier compliance issue [v6] In-Reply-To: References: Message-ID: > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Compare keys using encoded bytes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2343/files - new: https://git.openjdk.java.net/jdk/pull/2343/files/4bd7e45c..55bff9eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2343&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2343/head:pull/2343 PR: https://git.openjdk.java.net/jdk/pull/2343 From hchao at openjdk.java.net Tue Feb 16 22:15:40 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 16 Feb 2021 22:15:40 GMT Subject: RFR: 8257497: Key identifier compliance issue [v5] In-Reply-To: <4pJxygFcGhjUhpqhhYMSsGka8pDi9M5AeptLTjmyTKg=.daa07ab0-861b-44f2-9f9a-1c3d440ffaf4@github.com> References: <5h7yVK3O-WOeqmurzg5yRIj_I-xJLJ8iRbMl6UD5eu4=.6e0caf2c-4680-4dc8-befb-ed90bd954c90@github.com> <4pJxygFcGhjUhpqhhYMSsGka8pDi9M5AeptLTjmyTKg=.daa07ab0-861b-44f2-9f9a-1c3d440ffaf4@github.com> Message-ID: On Tue, 16 Feb 2021 18:33:52 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduced one param to createV3Extensions > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1484: > >> 1482: >> 1483: KeyIdentifier signerSubjectKeyId; >> 1484: if (subjectPubKey.equals(issuerPubKey)) { > > I think in most cases, this equality test will not work as there is no requirement for PublicKey to override Object.equals, so in most cases this will just check if they reference the same object. I suggest comparing the encoded bytes. Original logic using this equality test. Fixed as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From chegar at openjdk.java.net Wed Feb 17 10:33:43 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 17 Feb 2021 10:33:43 GMT Subject: RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote: > In another bug this question from me was answered by Alan Bateman : > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? > > > Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). > > > So I added freeing of the malloced memory to handleSendFailed . > Please review ! > > Thanks, Matthias Marked as reviewed by chegar (Reviewer). src/jdk.sctp/unix/native/libsctp/SctpChannelImpl.c line 236: > 234: return; > 235: } > 236: This looks fine. If NewDirectByteBuffer returns NULL there will be a pending OutOfMemoryError. src/jdk.sctp/unix/native/libsctp/SctpChannelImpl.c line 251: > 249: free(addressP); > 250: handleSocketError(env, errno); > 251: return; At this point the direct ByteBuffer has been successfully allocated and refers to the memory at addressP. But the direct ByteBuffer, while in the Java heap, will not have any references to it, so freeing addressP should be fine here. src/jdk.sctp/unix/native/libsctp/SctpChannelImpl.c line 257: > 255: //TODO: assert false: "should not reach here"; > 256: free(addressP); > 257: return; same a previous comment - looks ok. src/jdk.sctp/unix/native/libsctp/SctpChannelImpl.c line 270: > 268: return; > 269: } > 270: (*env)->SetObjectField(env, resultContainerObj, src_valueID, resultObj); If NewObject returns NULL, there will be a pending OutOfMemoryError. Freeing addressP should be safe here, same reasoning as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From chegar at openjdk.java.net Wed Feb 17 10:46:39 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 17 Feb 2021 10:46:39 GMT Subject: RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 10:30:45 GMT, Chris Hegarty wrote: >> In another bug this question from me was answered by Alan Bateman : >> >> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? >> >> >> Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). >> >> >> So I added freeing of the malloced memory to handleSendFailed . >> Please review ! >> >> Thanks, Matthias > > Marked as reviewed by chegar (Reviewer). This changes look good to me. Additionally, and separately, I have filed JDK-8261881. >From 8261881 : The SCTP implementation uses NewDirectByteBuffer to create a new direct byte-buffer in native code. Such creations of a direct byte-buffer are not automatically associated with a Cleaner, therefore the native memory associated with the buffer may not be released when the buffer is no longer reachable. The Java code that results in the native NewDirectByteBuffer should be examined with a view to creating a cleaner and assigning it to the direct byte-buffer. ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From valeriep at openjdk.java.net Wed Feb 17 12:25:40 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 17 Feb 2021 12:25:40 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 15:06:35 GMT, Martin Balao wrote: > Hi, > > I'd like to propose a fix for JDK-8261355 [1]. > > The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. > > No regressions observed in jdk/sun/security/pkcs11. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 I will take a look. Thanks~ ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From akozlov at openjdk.java.net Wed Feb 17 12:36:10 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 12:36:10 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Re-do safefetch.hpp - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos - stubRoutines.inline.hpp -> safefetch.hpp - Update copyrights - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Extract SafeFetch32/N to stubRoutines.inline.hpp - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=17 Stats: 2946 lines in 74 files changed: 2861 ins; 27 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 17 12:36:11 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 12:36:11 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:51:56 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31: > >> 29: #include "asm/assembler.inline.hpp" >> 30: #include "oops/compressedOops.hpp" >> 31: #include "runtime/vm_version.hpp" > > It's not clear why this include needed to be added. Line 448 calls `VM_Version::features()`. It seems the declaration is included indirectly somehow on the rest of the platforms, through OS specific headers. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From alanb at openjdk.java.net Wed Feb 17 12:53:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Feb 2021 12:53:54 GMT Subject: RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote: > In another bug this question from me was answered by Alan Bateman : > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? > > > Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). > > > So I added freeing of the malloced memory to handleSendFailed . > Please review ! > > Thanks, Matthias The changes looks okay to me. I see Chris has created JDK-8261881 to setup the cleanup. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2586 From akozlov at openjdk.java.net Wed Feb 17 13:09:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 13:09:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 16:21:53 GMT, Bernhard Urban-Forster wrote: >> This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds. >> @lewurm could you comment here please > > Those values can be observed in the debugger, but aren't documented or defined in header files. > > This mode was useful for the initial bootstrap of the platform (it helped with missing W^X transitions), but shouldn't be required anymore today. I'm fine with removing it altogether. OK, I'm going to remove this block. So we'll be able to revert changes in globals.hpp https://github.com/openjdk/jdk/pull/2200/files#r568986339 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 17 13:11:48 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 13:11:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <2DZXzH1_KDoevOmbbR0ipW0LWSo16BCilHOP1geU3_0=.201276ca-ddb3-49eb-a488-122b54467c49@github.com> On Tue, 2 Feb 2021 22:42:22 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/logging/logStream.hpp line 35: > >> 33: class LogStream : public outputStream { >> 34: // see test/hotspot/gtest/logging/test_logStream.cpp >> 35: friend class LogStreamTest; > > It's not clear why this change is made for this port. This was done for previous implementation of W^X, for gtests be able to access this test. This not required anymore, this hunk was reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From mbaesken at openjdk.java.net Wed Feb 17 13:21:38 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 17 Feb 2021 13:21:38 GMT Subject: RFR: JDK-8261791:(sctp) handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 12:51:06 GMT, Alan Bateman wrote: >> In another bug this question from me was answered by Alan Bateman : >> >> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? >> >> >> Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). >> >> >> So I added freeing of the malloced memory to handleSendFailed . >> Please review ! >> >> Thanks, Matthias > > The changes looks okay to me. I see Chris has created JDK-8261881 to setup the cleanup. Hi Alan and Chris, thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From mbaesken at openjdk.java.net Wed Feb 17 13:29:49 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 17 Feb 2021 13:29:49 GMT Subject: RFR: JDK-8261791:(sctp) handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 13:19:13 GMT, Matthias Baesken wrote: >> The changes looks okay to me. I see Chris has created JDK-8261881 to setup the cleanup. > > Hi Alan and Chris, thanks for the reviews. Looks like I cannot integrate it, even after changing the title!? Is this a bug? ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From alanb at openjdk.java.net Wed Feb 17 13:38:37 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Feb 2021 13:38:37 GMT Subject: RFR: JDK-8261791:(sctp) handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: Message-ID: <1dXY_QHIedDY-Fhapr-kmrtHddIFz6T_cKIub0SxX88=.6e648ccc-45dd-4208-b177-13f80338b187@github.com> On Wed, 17 Feb 2021 13:27:13 GMT, Matthias Baesken wrote: >> Hi Alan and Chris, thanks for the reviews. > > Looks like I cannot integrate it, even after changing the title!? > Is this a bug? Here's the jcheck failure: https://github.com/openjdk/jdk/pull/2586/checks?check_run_id=1918880270 ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From dfuchs at openjdk.java.net Wed Feb 17 13:45:37 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 17 Feb 2021 13:45:37 GMT Subject: RFR: JDK-8261791:(sctp) handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: <1dXY_QHIedDY-Fhapr-kmrtHddIFz6T_cKIub0SxX88=.6e648ccc-45dd-4208-b177-13f80338b187@github.com> References: <1dXY_QHIedDY-Fhapr-kmrtHddIFz6T_cKIub0SxX88=.6e648ccc-45dd-4208-b177-13f80338b187@github.com> Message-ID: On Wed, 17 Feb 2021 13:36:17 GMT, Alan Bateman wrote: >> Looks like I cannot integrate it, even after changing the title!? >> Is this a bug? > > Here's the jcheck failure: > https://github.com/openjdk/jdk/pull/2586/checks?check_run_id=1918880270 As pointed out by Alan: It seems like a space is missing after the colon in the PR title ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From mbaesken at openjdk.java.net Wed Feb 17 13:52:38 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 17 Feb 2021 13:52:38 GMT Subject: RFR: JDK-8261791: (sctp) handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: <1dXY_QHIedDY-Fhapr-kmrtHddIFz6T_cKIub0SxX88=.6e648ccc-45dd-4208-b177-13f80338b187@github.com> References: <1dXY_QHIedDY-Fhapr-kmrtHddIFz6T_cKIub0SxX88=.6e648ccc-45dd-4208-b177-13f80338b187@github.com> Message-ID: On Wed, 17 Feb 2021 13:36:17 GMT, Alan Bateman wrote: > Here's the jcheck failure: > https://github.com/openjdk/jdk/pull/2586/checks?check_run_id=1918880270 Hi Alan , I am aware of the jcheck message. It claims : "The commit message does not reference any issue. " I adjusted now the for the 3 or 4th time the message "JDK-8261791:(sctp) handleSendFailed in SctpChannelImpl.c potential leaks" without any progress . I think this is because it was modified in JBS after I created it (never had this problem without such a JBS modification). ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From mbaesken at openjdk.java.net Wed Feb 17 13:52:39 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 17 Feb 2021 13:52:39 GMT Subject: RFR: JDK-8261791: (sctp) handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: <1dXY_QHIedDY-Fhapr-kmrtHddIFz6T_cKIub0SxX88=.6e648ccc-45dd-4208-b177-13f80338b187@github.com> Message-ID: On Wed, 17 Feb 2021 13:43:14 GMT, Daniel Fuchs wrote: > As pointed out by Alan: It seems like a space is missing after the colon in the PR title lets give it a try. Thanks ! ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From mbaesken at openjdk.java.net Wed Feb 17 13:52:40 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 17 Feb 2021 13:52:40 GMT Subject: Integrated: JDK-8261791: (sctp) handleSendFailed in SctpChannelImpl.c potential leaks In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote: > In another bug this question from me was answered by Alan Bateman : > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ? > > > Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner). > > > So I added freeing of the malloced memory to handleSendFailed . > Please review ! > > Thanks, Matthias This pull request has now been integrated. Changeset: a0658795 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/a0658795 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod 8261791: (sctp) handleSendFailed in SctpChannelImpl.c potential leaks Reviewed-by: chegar, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2586 From github.com+10835776+stsypanov at openjdk.java.net Wed Feb 17 14:51:52 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 17 Feb 2021 14:51:52 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible Message-ID: Non-static classes hold a link to their parent classes, which in many cases can be avoided. ------------- Commit messages: - 8261880: Change nested classes in java.base to static nested classes where possible Changes: https://git.openjdk.java.net/jdk/pull/2589/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261880 Stats: 20 lines in 16 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589 PR: https://git.openjdk.java.net/jdk/pull/2589 From aph at openjdk.java.net Wed Feb 17 15:55:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 17 Feb 2021 15:55:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 06:24:05 GMT, Vladimir Kempik wrote: >> This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c. >> I don't understand why you think it's acceptable to bail in this case. Can you explain, please? > > it's for everything that uses less than 8 bytes on a stack( ints ( 4), shorts(2), bytes(1), floats(4)). > currently native wrapper generation does not support such cases at all, it needs refactoring before this can be implemented. > So when a method has more argument than can be placed in registers, we may have issues. > > So we just bailing out to interpreter in case when a smaller (<=4 b) type is going to be passed thru the stack. > > There was attempt to implement handling such cases but currently it requires some hacks (like using some vectors for non-specific task) - https://github.com/openjdk/aarch64-port/pull/3 OK. I checked and the Panama preview doesn't support direct native calls for stack arguments, so we're good for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Wed Feb 17 15:55:50 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 17 Feb 2021 15:55:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> Message-ID: <2D2djDl7sFFBYlKWrD1t7aXikT8r5iVAibMR4HI6bfw=.1465f633-0045-4917-b4dd-883f04e5e41e@github.com> On Mon, 15 Feb 2021 17:45:32 GMT, Anton Kozlov wrote: >> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. > > The latest merge with JDK-8261071 should resolve the issue. Please take a look. Looks much better, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From mullan at openjdk.java.net Wed Feb 17 15:58:45 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 17 Feb 2021 15:58:45 GMT Subject: RFR: 8257497: Key identifier compliance issue [v6] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 22:13:05 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Compare keys using encoded bytes Looks good. However, I think you should change the title of the bug to be more descriptive, which will help for release notes, etc. How about: "Update keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280." ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2343 From redestad at openjdk.java.net Wed Feb 17 16:27:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 17 Feb 2021 16:27:40 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ??????? wrote: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192: > 190: > 191: /* Placeholder class for DelegatingMethodHandles generated ahead of time */ > 192: static final class Holder {} For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+10835776+stsypanov at openjdk.java.net Wed Feb 17 16:38:04 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 17 Feb 2021 16:38:04 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:24:46 GMT, Claes Redestad wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8261880: Remove static from declarations of Holder nested classes > > src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192: > >> 190: >> 191: /* Placeholder class for DelegatingMethodHandles generated ahead of time */ >> 192: static final class Holder {} > > For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not. I'll just revert them ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+10835776+stsypanov at openjdk.java.net Wed Feb 17 16:38:03 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 17 Feb 2021 16:38:03 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8261880: Remove static from declarations of Holder nested classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2589/files - new: https://git.openjdk.java.net/jdk/pull/2589/files/5650cce4..c6f9cf6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589 PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+7806504+liach at openjdk.java.net Wed Feb 17 16:38:04 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 17 Feb 2021 16:38:04 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:32:39 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192: >> >>> 190: >>> 191: /* Placeholder class for DelegatingMethodHandles generated ahead of time */ >>> 192: static final class Holder {} >> >> For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not. > > I'll just revert them For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From hchao at openjdk.java.net Wed Feb 17 16:41:41 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 17 Feb 2021 16:41:41 GMT Subject: RFR: 8257497: Update keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280 [v6] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 15:55:30 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Compare keys using encoded bytes > > Looks good. However, I think you should change the title of the bug to be more descriptive, which will help for release notes, etc. How about: "Update keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280." @seanjmullan Good idea, and updated the bug's title as suggested. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From hchao at openjdk.java.net Wed Feb 17 16:41:43 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 17 Feb 2021 16:41:43 GMT Subject: Integrated: 8257497: Update keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280 In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 23:06:30 GMT, Hai-May Chao wrote: > This change is made for compliance with RFC 5280 section 4.2.1.1 for Authority Key Identifier extension. This pull request has now been integrated. Changeset: 05301f5f Author: Hai-May Chao URL: https://git.openjdk.java.net/jdk/commit/05301f5f Stats: 153 lines in 3 files changed: 139 ins; 7 del; 7 mod 8257497: Update keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280 Reviewed-by: coffeys, mullan, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/2343 From redestad at openjdk.java.net Wed Feb 17 17:27:56 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 17 Feb 2021 17:27:56 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:35:02 GMT, liach wrote: >> I'll just revert them > > For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors. Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From jlaskey at openjdk.java.net Wed Feb 17 17:35:09 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 17 Feb 2021 17:35:09 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v18] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: - Merge branch 'master' into 8248862 - Flatten out use of all() - Add review edits - Added table of available algorithms. - Merge branch 'master' into 8248862 - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. - Update package info to credit LMX algorithm - Merge branch 'master' into 8248862 - Correct range used by nextBytes - ... and 38 more: https://git.openjdk.java.net/jdk/compare/05301f5f...16f066fe ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=17 Stats: 13341 lines in 26 files changed: 11195 ins; 2055 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Wed Feb 17 17:39:47 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 17 Feb 2021 17:39:47 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 21:30:12 GMT, Andrey Turbanov wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Added table of available algorithms. > > test/jdk/java/util/Random/RandomTestBsi1999.java line 227: > >> 225: static int checkRunStats(int[] stats) { >> 226: int runFailure = 0; >> 227: runFailure |= ((2267 <= stats[1]) || (stats[1] <= 2733)) ? 0 : 1; > > 1. confusing formatting. > 2. This condition is always `true`. Looks like `&&` should be used instead of `||` Correct. Changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+828220+forax at openjdk.java.net Wed Feb 17 17:44:47 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 17 Feb 2021 17:44:47 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 17:24:50 GMT, Claes Redestad wrote: >> For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors. > > Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9. Inner classes doesn't really exist for the JVM, it's just an attribute (in fact, a pair of attributes) that is read/write by javac (it's very similar to the way generics work). So it is Ok to have static methods in inner classes since Java 1.1 from the JVM POV with the caveat that you may not be all to call them from Java-the-language. Also since Java 11, inner classes are also nestmate and those attributes (NestHost/NestMembers) change the behavior of the VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From valeriep at openjdk.java.net Thu Feb 18 05:06:44 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 18 Feb 2021 05:06:44 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: References: Message-ID: On Sat, 6 Feb 2021 14:40:04 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > materials src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 97: > 95: } finally { > 96: Arrays.fill(masterSecret, (byte)0); > 97: } It seems that for other Tls* classes, the Arrays.fill(...) call is still inside each method instead of being moved up a level. Just curious why this is done differently? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Thu Feb 18 05:17:44 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 18 Feb 2021 05:17:44 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: References: Message-ID: <3pT0mtOYZTMwkOrraWKs7noVswYVFOwO0gTqNXJINIA=.bb9a704e-474b-4ae2-8956-9ba1161e734b@github.com> On Sat, 6 Feb 2021 14:40:04 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > materials src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 186: > 184: serverMacKey = new SecretKeySpec(tmp, "Mac"); > 185: > 186: Arrays.fill(tmp, (byte)0); It looks like you can use the SecretKeySpec(byte[], int, int, String) to simplify the code at line 175-186. Essentially, the code block does: clientMacKey = new SecretKeySpec(keyBlock, ofs, macLength, "Mac"); ofs += macLength; serverMacKey = new SecretKeySpec(keyBlock, ofs, macLength, "Mac"); ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From github.com+741251+turbanoff at openjdk.java.net Thu Feb 18 07:15:40 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 18 Feb 2021 07:15:40 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: On Tue, 16 Feb 2021 17:20:37 GMT, Julia Boes wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? > https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 > https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From ewhelan at openjdk.java.net Thu Feb 18 09:58:39 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Thu, 18 Feb 2021 09:58:39 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output In-Reply-To: References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: On Mon, 1 Feb 2021 19:40:07 GMT, Rajan Halade wrote: >> Hi everyone, >> >> Please review my fix for JDK-8211227 >> >> This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. >> >> Thanks, >> Evan > > test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 83: > >> 81: // Re-enabling as test depends on these algorithms >> 82: SecurityUtils.removeFromDisabledTlsAlgs("TLSv1", "TLSv1.1"); >> 83: var url = new URL("https://jpg-data.us.oracle.com/"); > > This URL is not accessible outside. Thanks Rajan, I'm going to change my approach for this test, I will set up a dummy server on localhost and create my URL based off that, rather than URLs pointing to an existing site ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From jboes at openjdk.java.net Thu Feb 18 10:38:41 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 18 Feb 2021 10:38:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: <8pRy5JBdXXoJzu35O6aFHAUALWZ__OBbdganHZKu1FE=.f5fcf42b-eab5-49a6-9450-4942c933f39d@github.com> On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? To re-integrate, just run the /integrate command again. Before doing that, could someone from security libs acknowledge the changes in their area? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From valeriep at openjdk.java.net Thu Feb 18 11:07:45 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 18 Feb 2021 11:07:45 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: References: Message-ID: <_7q_ApgqO9B2FE9OHUJjpplhQXHpjr71Xm1GvCIKKoU=.41508c6c-cfbe-40a7-a135-3cc64ba17ab5@github.com> On Sat, 6 Feb 2021 14:40:04 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > materials src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 220: > 218: System.arraycopy(keyBlock, ofs, tmp, 0, ivLength); > 219: ofs += ivLength; > 220: serverIv = new IvParameterSpec(tmp); Seems easier to just use the IvParameterSpec(byte[], int, int) constructor? src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 251: > 249: clientIv = new IvParameterSpec(tmp); > 250: System.arraycopy(block, ivLength, tmp, 0, ivLength); > 251: serverIv = new IvParameterSpec(tmp); Again, consider using IvParameterSpec(byte[], int, int) and get rid of tmp? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Thu Feb 18 11:11:41 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 18 Feb 2021 11:11:41 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: References: Message-ID: <36m7BOHwLgBn6NU7n_ohiunDx8ZXlLWnWmw3KVDL20Q=.684c5aed-54e8-4161-90b0-8bec4d54a124@github.com> On Sat, 6 Feb 2021 14:40:04 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > materials Other files look fine. Thanks~ src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 261: > 259: md5.update(clientRandom); > 260: md5.update(serverRandom); > 261: digest = md5.digest(); In other Tls* sources, you call MessageDigest.reset() but not here? Particular reason? ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From chegar at openjdk.java.net Thu Feb 18 11:54:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 18 Feb 2021 11:54:40 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: <8erqBs2u14oRGdt-KmCGy9IGLZnv5k1tqwm57BSnjBQ=.4e8133b8-f287-43a0-94d3-da136336e56b@github.com> On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes The changes in java/net look ok to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From christoph.langer at sap.com Thu Feb 18 13:11:15 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 18 Feb 2021 13:11:15 +0000 Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore In-Reply-To: References: Message-ID: Hi Martin, this backport looks good to me. Best regards Christoph From: Doerr, Martin Sent: Donnerstag, 18. Februar 2021 12:11 To: security-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore Hi, JDK-8256421 is backported to 11.0.11-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I'm using the jdk16u backport. See "Fix Request (jdk16u)" comment. VerifyCACerts.java: I had to change the COUNT manually: - private static final int COUNT = 95; + private static final int COUNT = 97; And I've computed the new CHECKSUM which gets verified by the test: shasum -a 256 jdk/lib/security/cacerts | sed -e 's/../&:/g' | tr '[:lower:]' '[:upper:]' | cut -c1-95 9F:6B:41:1D:05:AF:E3:C5:4F:E8:39:89:50:79:60:B1:F6:A4:02:40:0C:28:8D:73:78:08:E5:61:7C:17:EA:59 Bug: https://bugs.openjdk.java.net/browse/JDK-8256421 Original change (from 16u): https://github.com/openjdk/jdk16u/commit/4ccaf6b8 11u backport: http://cr.openjdk.java.net/~mdoerr/8256421_HARICA_cacerts_11u/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+10835776+stsypanov at openjdk.java.net Thu Feb 18 14:35:48 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 18 Feb 2021 14:35:48 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings Message-ID: Hello, as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: String delimiter = this.delimiter; char[] chars = new char[this.len + addLen]; int k = getChars(this.prefix, chars, 0); if (size > 0) { k += getChars(elts[0], chars, k); // inflate byte[] for(int i = 1; i < size; ++i) { k += getChars(delimiter, chars, k); k += getChars(elts[i], chars, k); } } k += getChars(this.suffix, chars, k); return new String(chars); // compress char[] -> byte[] This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) covering both cases when resulting String is Latin1 or UTF-16 I've prepared a patch along with benchmark proving that this change is correct and brings improvement. @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class StringJoinerBenchmark { @Benchmark public String stringJoiner(Data data) { String[] stringArray = data.stringArray; return Joiner.joinWithStringJoiner(stringArray); } @State(Scope.Thread) public static class Data { @Param({"latin", "cyrillic", "mixed"}) private String mode; @Param({"8", "32", "64"}) private int length; @Param({"5", "10", "100"}) private int count; private String[] stringArray; @Setup public void setup() { RandomStringGenerator generator = new RandomStringGenerator(); stringArray = new String[count]; for (int i = 0; i < count; i++) { String alphabet = getAlphabet(i, mode); stringArray[i] = generator.randomString(alphabet, length); } } private static String getAlphabet(int index, String mode) { var latin = "abcdefghijklmnopqrstuvwxyz"; //English var cyrillic = "????????????????????????????????"; // Russian String alphabet; switch (mode) { case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; case "latin" -> alphabet = latin; case "cyrillic" -> alphabet = cyrillic; default -> throw new RuntimeException("Illegal mode " + mode); } return alphabet; } } } (count) (length) (mode) Java 14 patched Units stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op ------------- Commit messages: - 8261880: Check also delimiter, prefix and suffix - 8148937: (str) Adapt StringJoiner for Compact Strings Changes: https://git.openjdk.java.net/jdk/pull/2627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8148937 Stats: 77 lines in 3 files changed: 56 ins; 6 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2627/head:pull/2627 PR: https://git.openjdk.java.net/jdk/pull/2627 From redestad at openjdk.java.net Thu Feb 18 15:22:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Feb 2021 15:22:39 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 14:30:15 GMT, ?????? ??????? wrote: > Hello, > > as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. > > This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. > > As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: > String delimiter = this.delimiter; > char[] chars = new char[this.len + addLen]; > int k = getChars(this.prefix, chars, 0); > if (size > 0) { > k += getChars(elts[0], chars, k); // inflate byte[] > > for(int i = 1; i < size; ++i) { > k += getChars(delimiter, chars, k); > k += getChars(elts[i], chars, k); > } > } > > k += getChars(this.suffix, chars, k); > return new String(chars); // compress char[] -> byte[] > This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) > covering both cases when resulting String is Latin1 or UTF-16 > > I've prepared a patch along with benchmark proving that this change is correct and brings improvement. > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class StringJoinerBenchmark { > > @Benchmark > public String stringJoiner(Data data) { > String[] stringArray = data.stringArray; > return Joiner.joinWithStringJoiner(stringArray); > } > > @State(Scope.Thread) > public static class Data { > > @Param({"latin", "cyrillic", "mixed"}) > private String mode; > > @Param({"8", "32", "64"}) > private int length; > > @Param({"5", "10", "100"}) > private int count; > > private String[] stringArray; > > @Setup > public void setup() { > RandomStringGenerator generator = new RandomStringGenerator(); > > stringArray = new String[count]; > > for (int i = 0; i < count; i++) { > String alphabet = getAlphabet(i, mode); > stringArray[i] = generator.randomString(alphabet, length); > } > } > > private static String getAlphabet(int index, String mode) { > var latin = "abcdefghijklmnopqrstuvwxyz"; //English > var cyrillic = "????????????????????????????????"; // Russian > > String alphabet; > switch (mode) { > case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; > case "latin" -> alphabet = latin; > case "cyrillic" -> alphabet = cyrillic; > default -> throw new RuntimeException("Illegal mode " + mode); > } > return alphabet; > } > } > } > > > (count) (length) (mode) Java 14 patched Units > stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op > stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op > stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op > stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op > stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op > stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op > stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op > stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op > stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op > stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op > stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op > stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op > stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op > stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op > stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op > stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op > stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op > stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op > stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op > stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op > stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op > stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op > stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op > stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op > stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op > stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op > stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op > > stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From jlaskey at openjdk.java.net Thu Feb 18 15:29:01 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Feb 2021 15:29:01 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v19] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey 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 branch 'master' into 8248862 - Update tests for RandomGeneratorFactory.all() - Merge branch 'master' into 8248862 - Flatten out use of all() - Add review edits - Added table of available algorithms. - Merge branch 'master' into 8248862 - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. - Update package info to credit LMX algorithm - ... and 40 more: https://git.openjdk.java.net/jdk/compare/f94a8452...7d0ebfc9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=18 Stats: 13341 lines in 26 files changed: 11195 ins; 2055 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Thu Feb 18 16:24:00 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Feb 2021 16:24:00 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v20] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Correct copyright notice. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/7d0ebfc9..9861b4e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=18-19 Stats: 28 lines in 1 file changed: 6 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From weijun at openjdk.java.net Thu Feb 18 16:43:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 18 Feb 2021 16:43:49 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: References: Message-ID: <4bFR2nekMGfOPo0r6h0IgrKB1UJVNNVdOBnxP38DAS4=.fafe3ef4-4086-4ff1-8216-441f9d5f4fff@github.com> On Thu, 18 Feb 2021 05:03:58 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> materials > > src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 97: > >> 95: } finally { >> 96: Arrays.fill(masterSecret, (byte)0); >> 97: } > > It seems that for other Tls* classes, the Arrays.fill(...) call is still inside each method instead of being moved up a level. Just curious why this is done differently? The `engineGenerateKey0` method is quite long and I don't want to wrap everything in a big try-finally block, so I move it a little higher. Now `masterSecret` is still created and cleaned in the same method. > src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 186: > >> 184: serverMacKey = new SecretKeySpec(tmp, "Mac"); >> 185: >> 186: Arrays.fill(tmp, (byte)0); > > It looks like you can use the SecretKeySpec(byte[], int, int, String) to simplify the code at line 175-186. Essentially, the code block does: > clientMacKey = new SecretKeySpec(keyBlock, ofs, macLength, "Mac"); > ofs += macLength; > serverMacKey = new SecretKeySpec(keyBlock, ofs, macLength, "Mac"); Good idea. > src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 220: > >> 218: System.arraycopy(keyBlock, ofs, tmp, 0, ivLength); >> 219: ofs += ivLength; >> 220: serverIv = new IvParameterSpec(tmp); > > Seems easier to just use the IvParameterSpec(byte[], int, int) constructor? Yes. > src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 251: > >> 249: clientIv = new IvParameterSpec(tmp); >> 250: System.arraycopy(block, ivLength, tmp, 0, ivLength); >> 251: serverIv = new IvParameterSpec(tmp); > > Again, consider using IvParameterSpec(byte[], int, int) and get rid of tmp? Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Thu Feb 18 19:21:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 18 Feb 2021 19:21:42 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: <36m7BOHwLgBn6NU7n_ohiunDx8ZXlLWnWmw3KVDL20Q=.684c5aed-54e8-4161-90b0-8bec4d54a124@github.com> References: <36m7BOHwLgBn6NU7n_ohiunDx8ZXlLWnWmw3KVDL20Q=.684c5aed-54e8-4161-90b0-8bec4d54a124@github.com> Message-ID: On Thu, 18 Feb 2021 11:08:06 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> materials > > src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 261: > >> 259: md5.update(clientRandom); >> 260: md5.update(serverRandom); >> 261: digest = md5.digest(); > > In other Tls* sources, you call MessageDigest.reset() but not here? Particular reason? I usually call it when the last updated bytes are sensitive. They will stay in the buffer. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From mullan at openjdk.java.net Thu Feb 18 19:24:43 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 18 Feb 2021 19:24:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: Message-ID: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > remove unnecessary file.exists() check src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228: > 226: try { > 227: if (is.markSupported() == false) { > 228: // Copy the entire input stream into an InputStream that does I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+10835776+stsypanov at openjdk.java.net Thu Feb 18 20:16:39 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 18 Feb 2021 20:16:39 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 15:19:43 GMT, Claes Redestad wrote: >> Hello, >> >> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. >> >> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. >> >> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: >> String delimiter = this.delimiter; >> char[] chars = new char[this.len + addLen]; >> int k = getChars(this.prefix, chars, 0); >> if (size > 0) { >> k += getChars(elts[0], chars, k); // inflate byte[] >> >> for(int i = 1; i < size; ++i) { >> k += getChars(delimiter, chars, k); >> k += getChars(elts[i], chars, k); >> } >> } >> >> k += getChars(this.suffix, chars, k); >> return new String(chars); // compress char[] -> byte[] >> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) >> covering both cases when resulting String is Latin1 or UTF-16 >> >> I've prepared a patch along with benchmark proving that this change is correct and brings improvement. >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class StringJoinerBenchmark { >> >> @Benchmark >> public String stringJoiner(Data data) { >> String[] stringArray = data.stringArray; >> return Joiner.joinWithStringJoiner(stringArray); >> } >> >> @State(Scope.Thread) >> public static class Data { >> >> @Param({"latin", "cyrillic", "mixed"}) >> private String mode; >> >> @Param({"8", "32", "64"}) >> private int length; >> >> @Param({"5", "10", "100"}) >> private int count; >> >> private String[] stringArray; >> >> @Setup >> public void setup() { >> RandomStringGenerator generator = new RandomStringGenerator(); >> >> stringArray = new String[count]; >> >> for (int i = 0; i < count; i++) { >> String alphabet = getAlphabet(i, mode); >> stringArray[i] = generator.randomString(alphabet, length); >> } >> } >> >> private static String getAlphabet(int index, String mode) { >> var latin = "abcdefghijklmnopqrstuvwxyz"; //English >> var cyrillic = "????????????????????????????????"; // Russian >> >> String alphabet; >> switch (mode) { >> case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; >> case "latin" -> alphabet = latin; >> case "cyrillic" -> alphabet = cyrillic; >> default -> throw new RuntimeException("Illegal mode " + mode); >> } >> return alphabet; >> } >> } >> } >> >> >> (count) (length) (mode) Java 14 patched Units >> stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op >> stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op >> stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op >> stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op >> stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op >> stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op >> stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op >> stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op >> stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op >> stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op >> stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op >> stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op >> stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op >> stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op >> stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op >> stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op >> stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op >> stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op >> stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op >> stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op >> stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op >> stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op >> stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op >> stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op >> stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op >> stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op >> stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op >> >> stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op > > Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. > > As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. Hi @cl4es, > Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. I've checked out Aleksey's branch and applied my changes onto it, the only thing that I changed to make it work is replacing public boolean isLatin1(String str) { return str.isLatin1(); } with public boolean isLatin1(String str) { return str.coder == String.LATIN1; } The rest of the code was left intact. `jdk:tier1` is OK after the change. > As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. Apart from `JavaLangAccess` the only thing that comes to my mind is reflection, but it will destroy all the improvement. Otherwise I cannot figure out any other way to access somehow package-private latin/non-latin functionality of `j.l.String` in `java.util` package. I wonder, whether I'm missing any other opportunities? ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From ewhelan at openjdk.java.net Thu Feb 18 20:37:58 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Thu, 18 Feb 2021 20:37:58 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output [v2] In-Reply-To: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: > Hi everyone, > > Please review my fix for JDK-8211227 > > This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. > > Thanks, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: 8211227: Re-wrote LoggingFormatConsistency to use local SSL server rather than an existing URL ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2331/files - new: https://git.openjdk.java.net/jdk/pull/2331/files/e8c262f2..ff7e2eb4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2331&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2331&range=00-01 Stats: 232 lines in 1 file changed: 213 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/2331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2331/head:pull/2331 PR: https://git.openjdk.java.net/jdk/pull/2331 From ewhelan at openjdk.java.net Thu Feb 18 20:37:59 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Thu, 18 Feb 2021 20:37:59 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output [v2] In-Reply-To: References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: On Mon, 1 Feb 2021 19:41:09 GMT, Rajan Halade wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8211227: Re-wrote LoggingFormatConsistency to use local SSL server rather than an existing URL > > test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 50: > >> 48: public class LoggingFormatConsistency { >> 49: public static void main(String[] args) throws Exception { >> 50: if (args.length == 0){ > > Please add a comment to explain when the test should be run with parameter. Done! Thanks > test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 36: > >> 34: /* >> 35: * This test runs in another process so we can monitor the debug >> 36: * results. The OutputAnalyzer must see correct debug output to return a > > Suggestion: > > * results. The OutputAnalyzer must see correct debug output to return a Blank space removed ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From rhalade at openjdk.java.net Thu Feb 18 22:27:40 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 18 Feb 2021 22:27:40 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output [v2] In-Reply-To: References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: On Thu, 18 Feb 2021 20:37:58 GMT, Evan Whelan wrote: >> Hi everyone, >> >> Please review my fix for JDK-8211227 >> >> This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. >> >> Thanks, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8211227: Re-wrote LoggingFormatConsistency to use local SSL server rather than an existing URL Changes requested by rhalade (Reviewer). test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 145: > 143: * Fork off the other side, then do your work. > 144: */ > 145: LoggingFormatConsistency() throws Exception { Have you looked at the templates available at test/jdk/javax/net/ssl/templates? Check SSLSocketTemplate.java which is using CountDownLatch. ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 19 08:07:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 19 Feb 2021 08:07:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> References: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> Message-ID: On Thu, 18 Feb 2021 19:21:45 GMT, Sean Mullan wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> remove unnecessary file.exists() check > > src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228: > >> 226: try { >> 227: if (is.markSupported() == false) { >> 228: // Copy the entire input stream into an InputStream that does > > I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is. As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code: PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); private static List parsePKCS7(InputStream is) certs = parsePKCS7(is); public X509CertPath(InputStream is, String encoding) return new X509CertPath(new ByteArrayInputStream(data), encoding); PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); private static List parsePKCS7(InputStream is) certs = parsePKCS7(is); public X509CertPath(InputStream is, String encoding) this(is, PKIPATH_ENCODING); public X509CertPath(InputStream is) throws CertificateException { return new X509CertPath(new ByteArrayInputStream(encoding)); ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png) Perhaps original marking approach was lost during refactoring? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From ewhelan at openjdk.java.net Fri Feb 19 09:48:40 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Fri, 19 Feb 2021 09:48:40 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output [v2] In-Reply-To: References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: On Thu, 18 Feb 2021 22:24:28 GMT, Rajan Halade wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8211227: Re-wrote LoggingFormatConsistency to use local SSL server rather than an existing URL > > test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 145: > >> 143: * Fork off the other side, then do your work. >> 144: */ >> 145: LoggingFormatConsistency() throws Exception { > > Have you looked at the templates available at test/jdk/javax/net/ssl/templates? Check SSLSocketTemplate.java which is using CountDownLatch. I have not! I'll take a look, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From jjiang at openjdk.java.net Fri Feb 19 12:05:46 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Fri, 19 Feb 2021 12:05:46 GMT Subject: RFR: JDK-8261969: SNIHostName would check if the encoded hostname conform to RFC 3490 Message-ID: Similar to the constructor SNIHostName(String hostname), the constructor SNIHostName(byte[] encoded) also needs to check if the encoded hostname conform to RFC 3490. ------------- Commit messages: - JDK-8261969: SNIHostName would check if the encoded hostname conform to RFC 3490 Changes: https://git.openjdk.java.net/jdk/pull/2639/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2639&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261969 Stats: 39 lines in 2 files changed: 24 ins; 5 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2639.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2639/head:pull/2639 PR: https://git.openjdk.java.net/jdk/pull/2639 From jlaskey at openjdk.java.net Fri Feb 19 12:48:05 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 19 Feb 2021 12:48:05 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v21] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove tabs from random/package-info.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/9861b4e4..cfaf7cef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=19-20 Stats: 102 lines in 1 file changed: 0 ins; 0 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Fri Feb 19 13:00:44 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 19 Feb 2021 13:00:44 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com> References: <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com> Message-ID: On Wed, 25 Nov 2020 13:55:32 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGenerator.java line 745: >> >>> 743: * if the period is unknown. >>> 744: */ >>> 745: BigInteger UNKNOWN_PERIOD = BigInteger.ZERO; >> >> move those 3 values into RandomGeneratorFactory ? > > Will ponder on this one. I tend to agree with you since they are most likely to be used for filtering factories RandomGeneratorFactory querying was a later development. period() originally was a RandomGenerator query, but got moved when more queries were added. This will require a CSR and will come later. Now unused and removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From mullan at openjdk.java.net Fri Feb 19 15:05:42 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 19 Feb 2021 15:05:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> Message-ID: On Fri, 19 Feb 2021 08:05:06 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228: >> >>> 226: try { >>> 227: if (is.markSupported() == false) { >>> 228: // Copy the entire input stream into an InputStream that does >> >> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is. > > As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code: > > PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); > private static List parsePKCS7(InputStream is) > certs = parsePKCS7(is); > public X509CertPath(InputStream is, String encoding) > return new X509CertPath(new ByteArrayInputStream(data), encoding); > > PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); > private static List parsePKCS7(InputStream is) > certs = parsePKCS7(is); > public X509CertPath(InputStream is, String encoding) > this(is, PKIPATH_ENCODING); > public X509CertPath(InputStream is) throws CertificateException { > return new X509CertPath(new ByteArrayInputStream(encoding)); > > ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png) > > Perhaps original marking approach was lost during refactoring? You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later. [1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6 ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From weijun at openjdk.java.net Fri Feb 19 21:49:00 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 19 Feb 2021 21:49:00 GMT Subject: RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. Message-ID: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> `InetAddress` is loading native library `net` and at the same time `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a deadlock. We can access `InetAddress` in `SunNativeProvider.` before loading the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is initialized. Thanks to @dholmes-ora for providing this workaround. No new regression test, hard to reproduce. ------------- Commit messages: - 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. Changes: https://git.openjdk.java.net/jdk/pull/2655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8210373 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2655/head:pull/2655 PR: https://git.openjdk.java.net/jdk/pull/2655 From weijun at openjdk.java.net Fri Feb 19 22:21:06 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 19 Feb 2021 22:21:06 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v9] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: simpler spec creation, and one more clean ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2070/files - new: https://git.openjdk.java.net/jdk/pull/2070/files/2241bf8a..83eb7dcc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=07-08 Stats: 22 lines in 2 files changed: 1 ins; 15 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Fri Feb 19 22:21:06 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 19 Feb 2021 22:21:06 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: <36m7BOHwLgBn6NU7n_ohiunDx8ZXlLWnWmw3KVDL20Q=.684c5aed-54e8-4161-90b0-8bec4d54a124@github.com> References: <36m7BOHwLgBn6NU7n_ohiunDx8ZXlLWnWmw3KVDL20Q=.684c5aed-54e8-4161-90b0-8bec4d54a124@github.com> Message-ID: <5h_L9QEhnm5S0dmOUo7cnsDD7GMTaPiunBNT31mf6-8=.7b345e61-39df-48d4-a3a4-c1a1e1d9e9d5@github.com> On Thu, 18 Feb 2021 11:09:17 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> materials > > Other files look fine. Thanks~ Add one more clean. Adjusting macKeyLen and ivLen in TlsKeyMaterialParameterSpec exposed another leak. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Fri Feb 19 22:39:48 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 19 Feb 2021 22:39:48 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 21:04:00 GMT, Weijun Wang wrote: >> Please review this change to disable XML signatures that use SHA-1 based digest or signature algorithms. SHA-1 is weak and is not a recommended algorithm for digital signatures. This will improve out of the box security by restricting XML signatures that use SHA-1 algorithms. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8261246 >> Release Note: https://bugs.openjdk.java.net/browse/JDK-8261364 > > Change looks good. All test changes are about re-enable disabled algorithms. Do we have a test on ensuring disabled algorithms are indeed disabled? ------------- PR: https://git.openjdk.java.net/jdk/pull/2463 From cverghese at openjdk.java.net Fri Feb 19 23:21:52 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Fri, 19 Feb 2021 23:21:52 GMT Subject: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v10] In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake Clive Verghese has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge master - Fix test failures - Address review comments - Update copyright year - Add error handling guidelines - Fix bugids and use server port passed as a parameter - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl ------------- Changes: https://git.openjdk.java.net/jdk/pull/2057/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2057&range=09 Stats: 199 lines in 7 files changed: 177 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/2057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2057/head:pull/2057 PR: https://git.openjdk.java.net/jdk/pull/2057 From darcy at openjdk.java.net Sat Feb 20 00:12:43 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 20 Feb 2021 00:12:43 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v21] In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 12:48:05 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove tabs from random/package-info.java src/java.base/share/classes/java/util/random/package-info.java line 193: > 191: * > 192: * > 193: *

Random Number Generator Algorithms Available in Java SE

Some comments and questions on the spec status of this table: is the intentional to require all of these algorithms in all compliant implementation of Java SE or just in the JDK reference implementation? Is the list intended to be exhaustive, meaning no other algorithms should be findable? I recommend clarifying the intended Java SE vs JDK status here. Also, I recommend including wording along the lines of "this list may change in the future" and "an implementation may provide additional algorithms" etc. Also, to aid future evolution of the set of algorithms, was there consideration of an "isDeprecated" predicate so that algorithms could be so-marked for a while before being dropped? ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jnimeh at openjdk.java.net Sat Feb 20 02:03:57 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Sat, 20 Feb 2021 02:03:57 GMT Subject: RFR: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages In-Reply-To: References: Message-ID: On Sat, 20 Feb 2021 01:56:37 GMT, Jamil Nimeh wrote: > This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client | server].SignatureSchemes property and its effect on messages that assert the signature_algorithms and signature_algorithms_cert extensions, or supported_signature_algorithms vectors like those used in TLS 1.2 CertificateRequest messages. With this change, the ordering of the signature algorithms in the property value will be preserved in the ordering as integer identifiers in the messages itself. Prior to this fix the property algorithms will be asserted, but in the order as shown in the sun.security.ssl.SignatureAlgorithms enumeration. > > This does not affect the default ordering of these signature schemes when the property is not given a value. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255867 src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 43: > 41: import java.util.Map; > 42: import java.util.Set; > 43: import java.util.stream.Collectors; Remnant from an earlier attempt at a fix, will remove. ------------- PR: https://git.openjdk.java.net/jdk/pull/2658 From jnimeh at openjdk.java.net Sat Feb 20 02:03:57 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Sat, 20 Feb 2021 02:03:57 GMT Subject: RFR: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages Message-ID: This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client | server].SignatureSchemes property and its effect on messages that assert the signature_algorithms and signature_algorithms_cert extensions, or supported_signature_algorithms vectors like those used in TLS 1.2 CertificateRequest messages. With this change, the ordering of the signature algorithms in the property value will be preserved in the ordering as integer identifiers in the messages itself. Prior to this fix the property algorithms will be asserted, but in the order as shown in the sun.security.ssl.SignatureAlgorithms enumeration. This does not affect the default ordering of these signature schemes when the property is not given a value. JBS: https://bugs.openjdk.java.net/browse/JDK-8255867 ------------- Commit messages: - 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages Changes: https://git.openjdk.java.net/jdk/pull/2658/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2658&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255867 Stats: 384 lines in 2 files changed: 380 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2658.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2658/head:pull/2658 PR: https://git.openjdk.java.net/jdk/pull/2658 From jlaskey at openjdk.java.net Sat Feb 20 15:20:42 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Sat, 20 Feb 2021 15:20:42 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v21] In-Reply-To: References: Message-ID: On Sat, 20 Feb 2021 00:09:51 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove tabs from random/package-info.java > > src/java.base/share/classes/java/util/random/package-info.java line 193: > >> 191: * >> 192: * >> 193: *

Random Number Generator Algorithms Available in Java SE

> > Some comments and questions on the spec status of this table: is the intentional to require all of these algorithms in all compliant implementation of Java SE or just in the JDK reference implementation? Is the list intended to be exhaustive, meaning no other algorithms should be findable? > > I recommend clarifying the intended Java SE vs JDK status here. Also, I recommend including wording along the lines of "this list may change in the future" and "an implementation may provide additional algorithms" etc. > > Also, to aid future evolution of the set of algorithms, was there consideration of an "isDeprecated" predicate so that algorithms could be so-marked for a while before being dropped? Precise advice on wording please. The table reflect algorithms guaranteed findable in JDK 17. Whether they are required in all other deployments is something the CSR review should define. "this list may change in the future" is a good idea. Not sure "isDeprecated" can be done in a meaningful way. This would require that users would have to add that filter to every query or have all() not include deprecated algorithms. Better to be prepared to handle not finding the algorithm. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From prr at openjdk.java.net Sun Feb 21 16:42:50 2021 From: prr at openjdk.java.net (Phil Race) Date: Sun, 21 Feb 2021 16:42:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: > > - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos > - Re-do safefetch.hpp > - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos > - stubRoutines.inline.hpp -> safefetch.hpp > - Update copyrights > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Extract SafeFetch32/N to stubRoutines.inline.hpp > - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" > > This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. > - Merge pull request #9 from VladimirKempik/pull/2200 > > Removed unused variables > - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c Looks like the compiler warning changess are now the only desktop changes. That is fine by me. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Mon Feb 22 03:45:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 22 Feb 2021 03:45:44 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 20:46:41 GMT, Sean Mullan wrote: > Please review this change to disable XML signatures that use SHA-1 based digest or signature algorithms. SHA-1 is weak and is not a recommended algorithm for digital signatures. This will improve out of the box security by restricting XML signatures that use SHA-1 algorithms. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8261246 > Release Note: https://bugs.openjdk.java.net/browse/JDK-8261364 test/lib/jdk/test/lib/security/SecurityUtils.java line 78: > 76: * part of the algorithm URI. > 77: */ > 78: public static void removeAlgsFromDSigPolicy(List algs) { How about using `String... algs` as arguments? ------------- PR: https://git.openjdk.java.net/jdk/pull/2463 From valeriep at openjdk.java.net Mon Feb 22 06:41:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 22 Feb 2021 06:41:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v8] In-Reply-To: References: <36m7BOHwLgBn6NU7n_ohiunDx8ZXlLWnWmw3KVDL20Q=.684c5aed-54e8-4161-90b0-8bec4d54a124@github.com> Message-ID: <_2LX8kDN3wDv2AVixrKMSod7mSajHiuuOBimdixslaM=.f9a6e821-0042-4f4d-a1b0-75d64eebc121@github.com> On Thu, 18 Feb 2021 19:18:26 GMT, Weijun Wang wrote: >> src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 261: >> >>> 259: md5.update(clientRandom); >>> 260: md5.update(serverRandom); >>> 261: digest = md5.digest(); >> >> In other Tls* sources, you call MessageDigest.reset() but not here? Particular reason? > > I usually call it when the last updated bytes are sensitive. They will stay in the buffer. Ok >> src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java line 97: >> >>> 95: } finally { >>> 96: Arrays.fill(masterSecret, (byte)0); >>> 97: } >> >> It seems that for other Tls* classes, the Arrays.fill(...) call is still inside each method instead of being moved up a level. Just curious why this is done differently? > > The `engineGenerateKey0` method is quite long and I don't want to wrap everything in a big try-finally block, so I move it a little higher. Now `masterSecret` is still created and cleaned in the same method. Ok ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From valeriep at openjdk.java.net Mon Feb 22 07:15:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 22 Feb 2021 07:15:43 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v9] In-Reply-To: References: Message-ID: <6UxVZoVSD2JpDyCXhZFZyghwErL2Q9_TbBluRHWCsvs=.b91cc8f9-a8cd-4e94-b349-c74a264e4273@github.com> On Fri, 19 Feb 2021 22:21:06 GMT, Weijun Wang wrote: >> Clean up temporary byte array, char array, and keyspec around keys and passwords. >> >> No new regression test. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > simpler spec creation, and one more clean Changes look good. Thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2070 From ewhelan at openjdk.java.net Mon Feb 22 09:47:16 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 22 Feb 2021 09:47:16 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output [v3] In-Reply-To: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: > Hi everyone, > > Please review my fix for JDK-8211227 > > This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. > > Thanks, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: 8211227: Re-wrote LoggingFormatConsistency to leverage SSLSocketTemplate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2331/files - new: https://git.openjdk.java.net/jdk/pull/2331/files/ff7e2eb4..bc9d87d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2331&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2331&range=01-02 Stats: 229 lines in 1 file changed: 17 ins; 166 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2331/head:pull/2331 PR: https://git.openjdk.java.net/jdk/pull/2331 From jlaskey at openjdk.java.net Mon Feb 22 13:47:09 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 22 Feb 2021 13:47:09 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v22] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Revised javadoc per CSR reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/cfaf7cef..61f5d700 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=20-21 Stats: 31 lines in 3 files changed: 28 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From weijun at openjdk.java.net Mon Feb 22 15:58:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 22 Feb 2021 15:58:41 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v9] In-Reply-To: <6UxVZoVSD2JpDyCXhZFZyghwErL2Q9_TbBluRHWCsvs=.b91cc8f9-a8cd-4e94-b349-c74a264e4273@github.com> References: <6UxVZoVSD2JpDyCXhZFZyghwErL2Q9_TbBluRHWCsvs=.b91cc8f9-a8cd-4e94-b349-c74a264e4273@github.com> Message-ID: On Mon, 22 Feb 2021 07:12:57 GMT, Valerie Peng wrote: > Changes look good. Thanks~ Thanks a lot for your patience and precious feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From rhalade at openjdk.java.net Mon Feb 22 16:20:43 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 22 Feb 2021 16:20:43 GMT Subject: RFR: JDK-8261969: SNIHostName would check if the encoded hostname conform to RFC 3490 In-Reply-To: References: Message-ID: <7tiRMJ8PX1YkuoFzgZG_1siabiav4VSZ5Jp3qJFL9y8=.2d6388c0-13d1-4153-84eb-493e8f519592@github.com> On Fri, 19 Feb 2021 08:39:23 GMT, John Jiang wrote: > Similar to the constructor SNIHostName(String hostname), the constructor SNIHostName(byte[] encoded) also needs to check if the encoded hostname conform to RFC 3490. Changes requested by rhalade (Reviewer). test/jdk/javax/net/ssl/ServerName/IllegalSNIName.java line 40: > 38: try { > 39: new SNIHostName(hostname); > 40: throw new Exception("Expected to get IllegalArgumentException for " Suggestion: throw new RuntimeException("Expected to get IllegalArgumentException for " test/jdk/javax/net/ssl/ServerName/IllegalSNIName.java line 50: > 48: try { > 49: new SNIHostName(encodedHostname); > 50: throw new Exception("Expected to get IllegalArgumentException for " Suggestion: throw new RuntimeException("Expected to get IllegalArgumentException for " ------------- PR: https://git.openjdk.java.net/jdk/pull/2639 From fguallini at openjdk.java.net Mon Feb 22 16:46:53 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Mon, 22 Feb 2021 16:46:53 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 Message-ID: Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` New and old format are not compatible, that means they cannot share a rcache file. Since there is no interoperability between java GSS-API and native GSS-API new rcache format at the moment, this patch only enables the test scenarios that mimic AP-REQ replays with multiple processes using native GSS-API only (when available) and multiple processes using Java own implementation API only. If there is a decision to support the new format in the future, tests will be revisited accordingly. ------------- Commit messages: - java lib does not share rcache with native lib Changes: https://git.openjdk.java.net/jdk/pull/2676/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2676&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258855 Stats: 50 lines in 3 files changed: 25 ins; 22 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2676.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2676/head:pull/2676 PR: https://git.openjdk.java.net/jdk/pull/2676 From jnimeh at openjdk.java.net Mon Feb 22 17:07:58 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Mon, 22 Feb 2021 17:07:58 GMT Subject: RFR: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages [v2] In-Reply-To: References: Message-ID: > This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client | server].SignatureSchemes property and its effect on messages that assert the signature_algorithms and signature_algorithms_cert extensions, or supported_signature_algorithms vectors like those used in TLS 1.2 CertificateRequest messages. With this change, the ordering of the signature algorithms in the property value will be preserved in the ordering as integer identifiers in the messages itself. Prior to this fix the property algorithms will be asserted, but in the order as shown in the sun.security.ssl.SignatureAlgorithms enumeration. > > This does not affect the default ordering of these signature schemes when the property is not given a value. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255867 Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary import ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2658/files - new: https://git.openjdk.java.net/jdk/pull/2658/files/49247253..9b9d967f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2658&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2658&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2658.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2658/head:pull/2658 PR: https://git.openjdk.java.net/jdk/pull/2658 From ascarpino at openjdk.java.net Mon Feb 22 17:47:56 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 22 Feb 2021 17:47:56 GMT Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling Message-ID: Hi, I need a code review of this change to ECDH. It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling. They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place. The new exception handling is a result of no longer having the native library. Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException thanks, Tony ------------- Commit messages: - merge with 8261502 - initial change Changes: https://git.openjdk.java.net/jdk/pull/2659/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2659&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261502 Stats: 205 lines in 2 files changed: 138 ins; 32 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/2659.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2659/head:pull/2659 PR: https://git.openjdk.java.net/jdk/pull/2659 From xuelei at openjdk.java.net Mon Feb 22 18:36:51 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 22 Feb 2021 18:36:51 GMT Subject: RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. In-Reply-To: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> References: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> Message-ID: On Fri, 19 Feb 2021 21:44:15 GMT, Weijun Wang wrote: > `InetAddress` is loading native library `net` and at the same time `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a deadlock. > > We can access `InetAddress` in `SunNativeProvider.` before loading the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is initialized. Thanks to @dholmes-ora for providing this workaround. > > No new regression test, hard to reproduce. src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 74: > 72: System.getProperty("sun.security.nativegss.debug")); > 73: try { > 74: Class.forName("java.net.InetAddress"); The returned value of Class.forName() is not used, someone else could delete this line later is he/she does not know the story behind this line. Would you mind add a few line comments about why it is added? Otherwise, looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2655 From cverghese at openjdk.java.net Mon Feb 22 18:40:03 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Mon, 22 Feb 2021 18:40:03 GMT Subject: Integrated: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> References: <__6eFeAaRpa6GHDCLFfjXcUD4fsc83Ck_Ee4crEEREM=.3b22e8af-af8c-4262-b49c-eb875e3bd5b6@github.com> Message-ID: On Wed, 13 Jan 2021 06:19:18 GMT, Clive Verghese wrote: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received correctly during TLS handshake This pull request has now been integrated. Changeset: 63f8fc87 Author: Clive Verghese Committer: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/63f8fc87 Stats: 199 lines in 7 files changed: 177 ins; 0 del; 22 mod 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/2057 From rhalade at openjdk.java.net Mon Feb 22 18:46:43 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 22 Feb 2021 18:46:43 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output [v3] In-Reply-To: References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: On Mon, 22 Feb 2021 09:47:16 GMT, Evan Whelan wrote: >> Hi everyone, >> >> Please review my fix for JDK-8211227 >> >> This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. >> >> Thanks, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8211227: Re-wrote LoggingFormatConsistency to leverage SSLSocketTemplate Thanks for developing test for this change and updating it to use template. ------------- Marked as reviewed by rhalade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2331 From xuelei at openjdk.java.net Mon Feb 22 19:00:44 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 22 Feb 2021 19:00:44 GMT Subject: RFR: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages [v2] In-Reply-To: References: Message-ID: <7E_1XUS-3-GBpluhotO1C_zavndQvUI11wl6PrgJsp4=.0609fe18-57d9-49a5-95e1-52affd914a0e@github.com> On Mon, 22 Feb 2021 17:07:58 GMT, Jamil Nimeh wrote: >> This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client | server].SignatureSchemes property and its effect on messages that assert the signature_algorithms and signature_algorithms_cert extensions, or supported_signature_algorithms vectors like those used in TLS 1.2 CertificateRequest messages. With this change, the ordering of the signature algorithms in the property value will be preserved in the ordering as integer identifiers in the messages itself. Prior to this fix the property algorithms will be asserted, but in the order as shown in the sun.security.ssl.SignatureAlgorithms enumeration. >> >> This does not affect the default ordering of these signature schemes when the property is not given a value. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8255867 > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary import test/jdk/sun/security/ssl/SignatureScheme/SigSchemePropOrdering.java line 90: > 88: private static final String SIG_SCHEME_STR = > 89: "rsa_pkcs1_sha256,rsa_pss_rsae_sha256,rsa_pss_pss_sha256," + > 90: "ed448,ed25519,ecdsa_secp256r1_sha256"; It have been a while that we are trying to avoid the use the binary keystore files in test. It would be nice that if new test cases could use the javax/net/ssl/templates/javax/net/ssl/templates instead. src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 387: > 385: config.signatureSchemes.isEmpty() ? > 386: Arrays.asList(SignatureScheme.values()) : > 387: config.signatureSchemes; I would like to have two more indents for the '?' operator. ------------- PR: https://git.openjdk.java.net/jdk/pull/2658 From weijun at openjdk.java.net Mon Feb 22 19:48:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 22 Feb 2021 19:48:40 GMT Subject: RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. In-Reply-To: References: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> Message-ID: On Mon, 22 Feb 2021 18:33:17 GMT, Xue-Lei Andrew Fan wrote: >> `InetAddress` is loading native library `net` and at the same time `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a deadlock. >> >> We can access `InetAddress` in `SunNativeProvider.` before loading the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is initialized. Thanks to @dholmes-ora for providing this workaround. >> >> No new regression test, hard to reproduce. > > src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 74: > >> 72: System.getProperty("sun.security.nativegss.debug")); >> 73: try { >> 74: Class.forName("java.net.InetAddress"); > > The returned value of Class.forName() is not used, someone else could delete this line later is he/she does not know the story behind this line. Would you mind add a few line comments about why it is added? > > Otherwise, looks good to me. Definitely. I should have added one. Thanks for reminding. ------------- PR: https://git.openjdk.java.net/jdk/pull/2655 From jnimeh at openjdk.java.net Mon Feb 22 20:07:41 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Mon, 22 Feb 2021 20:07:41 GMT Subject: RFR: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages [v2] In-Reply-To: <7E_1XUS-3-GBpluhotO1C_zavndQvUI11wl6PrgJsp4=.0609fe18-57d9-49a5-95e1-52affd914a0e@github.com> References: <7E_1XUS-3-GBpluhotO1C_zavndQvUI11wl6PrgJsp4=.0609fe18-57d9-49a5-95e1-52affd914a0e@github.com> Message-ID: On Mon, 22 Feb 2021 18:56:10 GMT, Xue-Lei Andrew Fan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary import > > test/jdk/sun/security/ssl/SignatureScheme/SigSchemePropOrdering.java line 90: > >> 88: private static final String SIG_SCHEME_STR = >> 89: "rsa_pkcs1_sha256,rsa_pss_rsae_sha256,rsa_pss_pss_sha256," + >> 90: "ed448,ed25519,ecdsa_secp256r1_sha256"; > > It have been a while that we are trying to avoid the use the binary keystore files in test. It would be nice that if new test cases could use the javax/net/ssl/templates/javax/net/ssl/templates instead. I should be able to rework it into an extension of SSLEngineTemplate. > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 387: > >> 385: config.signatureSchemes.isEmpty() ? >> 386: Arrays.asList(SignatureScheme.values()) : >> 387: config.signatureSchemes; > > I would like to have two more indents for the '?' operator. No problem, will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/2658 From github.com+30433125+djelinski at openjdk.java.net Mon Feb 22 20:39:42 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Mon, 22 Feb 2021 20:39:42 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> Message-ID: On Tue, 16 Feb 2021 19:38:50 GMT, djelinski wrote: >>> I may think it differently. It may be hard to know the future frequency of an cached item based on the past behaviors. For the above case, I'm not sure that K=3 is used less frequently than K=1. Maybe, next few seconds, K=1 could be more frequently. >> >> I agree that such prediction might not be 100% accurate. But, quick google search reveals that there are [many](https://www.usenix.org/system/files/hotstorage20_paper_eytan.pdf) [articles](https://link.springer.com/article/10.1007/PL00009255) that claim that LRU caches offer better hit rates than FIFO, especially for in-memory caches. >>> I would like a solution to following the timeout specification: keep the newer items if possible. >> >> That's a trivial change; all we need to do is change `true` to `false` [here](https://github.com/openjdk/jdk/blob/abe0e238bd25adb1ddd2b655613899bfa063cd85/src/java.base/share/classes/sun/security/util/Cache.java#L268). But, as stated above, LRU is better than FIFO, so I wouldn't want to do that. >> >> I could keep LRU and add another linked list that would store items in the order of their expiration dates; then we could quickly scan that list for expired items. Note: the order of expiration dates is not necessarily the order of insertion, because 1) `System.currentTimeMillis()` is not monotonic - it can move back when something changes the system time, 2) the expiration date is calculated at insertion time, so if someone changes the timeout on a non-empty cache, new items may have shorter expiration time than old ones. So, I'd either need to address that first (change `currentTimeMillis` to `nanoTime` and store creation time instead of expiration time), or use insertion sort for adding items (which would get very slow if either of the above mentioned situations happened). >> Let me know your thoughts. > > Well, if removing all expired items before evicting live ones is a non-negotiable, implementing all operations in constant time is much easier with FIFO, where we only need to keep one item order. > The new commits contain the following changes: > - use `nanoTime` instead of `currentTimeMillis` to make sure that time never goes back > - store insertion time instead of expiration time, so that older items always expire before newer ones, even when timeout is changed > - change internal hash map to store (and evict) items in insertion (FIFO) order > - always stop scanning entries after finding the first non-expired item, because subsequent items are now guaranteed to have later expiration dates, and collected soft references are handled by reference queue. > > tier1 and jdk_security tests passed; benchmark results show only minimal changes. I verified that none of the classes using `Cache` mentions LRU, looks like this was an implementation detail. Actually there's a much easier solution to reduce the number of slow `put()`s without making any behavioral changes. The cache object could store the earliest expire time, and then exit `expungeExpiredEntries()` early when current time is earlier than the earliest expire time - when it is, we know that there are no expired items in the queue and we can skip the scan entirely. @XueleiFan do you think the above is worth exploring? ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From weijun at openjdk.java.net Mon Feb 22 20:56:09 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 22 Feb 2021 20:56:09 GMT Subject: RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. [v2] In-Reply-To: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> References: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> Message-ID: <201dUxdejLMY0YXqxxehFiKTTK3rVVQM6Y1rTZgNFVk=.dbc7c717-fe2d-41f3-8188-81c2d43c6b73@github.com> > `InetAddress` is loading native library `net` and at the same time `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a deadlock. > > We can access `InetAddress` in `SunNativeProvider.` before loading the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is initialized. Thanks to @dholmes-ora for providing this workaround. > > No new regression test, hard to reproduce. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2655/files - new: https://git.openjdk.java.net/jdk/pull/2655/files/cf3feb4c..c63068c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2655&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2655&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2655/head:pull/2655 PR: https://git.openjdk.java.net/jdk/pull/2655 From ewhelan at openjdk.java.net Mon Feb 22 21:06:41 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 22 Feb 2021 21:06:41 GMT Subject: RFR: 8211227: Inconsistent TLS protocol version in debug output [v3] In-Reply-To: References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: <_d6eR0PziphbC25OtVAReLZ57WHeFfdeXIw1kEpRFTk=.8d892f94-65e7-4a18-a0e1-296383c1ab1e@github.com> On Mon, 22 Feb 2021 18:44:15 GMT, Rajan Halade wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8211227: Re-wrote LoggingFormatConsistency to leverage SSLSocketTemplate > > Thanks for developing test for this change and updating it to use template. Thanks Rajan, I appreciate the guidance. ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From ewhelan at openjdk.java.net Mon Feb 22 21:14:50 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 22 Feb 2021 21:14:50 GMT Subject: Integrated: 8211227: Inconsistent TLS protocol version in debug output In-Reply-To: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> References: <1Ve50_ulCaJ8IvyHS5F84_8GrgMn-rAgjN4wawqIOeY=.7ce9dd44-2c6a-46a8-b4f2-e0d879005954@github.com> Message-ID: On Mon, 1 Feb 2021 10:37:35 GMT, Evan Whelan wrote: > Hi everyone, > > Please review my fix for JDK-8211227 > > This supportability fix will result in a more consistent debug format when reading and writing TLS protocol versions. > > Thanks, > Evan This pull request has now been integrated. Changeset: a8672885 Author: Evan Whelan Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/a8672885 Stats: 162 lines in 6 files changed: 151 ins; 0 del; 11 mod 8211227: Inconsistent TLS protocol version in debug output Reviewed-by: xuelei, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/2331 From jnimeh at openjdk.java.net Mon Feb 22 21:28:57 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Mon, 22 Feb 2021 21:28:57 GMT Subject: RFR: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages [v3] In-Reply-To: References: Message-ID: > This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client | server].SignatureSchemes property and its effect on messages that assert the signature_algorithms and signature_algorithms_cert extensions, or supported_signature_algorithms vectors like those used in TLS 1.2 CertificateRequest messages. With this change, the ordering of the signature algorithms in the property value will be preserved in the ordering as integer identifiers in the messages itself. Prior to this fix the property algorithms will be asserted, but in the order as shown in the sun.security.ssl.SignatureAlgorithms enumeration. > > This does not affect the default ordering of these signature schemes when the property is not given a value. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255867 Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Fix indentation, make test a derivation of SSLEngineTemplate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2658/files - new: https://git.openjdk.java.net/jdk/pull/2658/files/9b9d967f..20498ee3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2658&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2658&range=01-02 Stats: 88 lines in 3 files changed: 12 ins; 49 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2658.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2658/head:pull/2658 PR: https://git.openjdk.java.net/jdk/pull/2658 From xuelei at openjdk.java.net Mon Feb 22 21:33:39 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 22 Feb 2021 21:33:39 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: References: <7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com> Message-ID: <66glPmvqcGuafhMIJXikBQzzaCp1-N3OGY8-hoypaUA=.7e49e138-8487-4700-806d-f9c2e80bfa7b@github.com> On Mon, 22 Feb 2021 20:36:53 GMT, djelinski wrote: > Actually there's a much easier solution to reduce the number of slow `put()`s without making any behavioral changes. > The cache object could store the earliest expire time, and then exit `expungeExpiredEntries()` early when current time is earlier than the earliest expire time - when it is, we know that there are no expired items in the queue and we can skip the scan entirely. > @XueleiFan do you think the above is worth exploring? Definitely, I think it is a good improvement. Actually, it is a surprise to me that the current code is not working this way. Sorry, I was/am on vacation, and the review could be delayed for a few days. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From xuelei at openjdk.java.net Mon Feb 22 21:35:56 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 22 Feb 2021 21:35:56 GMT Subject: RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. [v2] In-Reply-To: <201dUxdejLMY0YXqxxehFiKTTK3rVVQM6Y1rTZgNFVk=.dbc7c717-fe2d-41f3-8188-81c2d43c6b73@github.com> References: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> <201dUxdejLMY0YXqxxehFiKTTK3rVVQM6Y1rTZgNFVk=.dbc7c717-fe2d-41f3-8188-81c2d43c6b73@github.com> Message-ID: On Mon, 22 Feb 2021 20:56:09 GMT, Weijun Wang wrote: >> `InetAddress` is loading native library `net` and at the same time `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a deadlock. >> >> We can access `InetAddress` in `SunNativeProvider.` before loading the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is initialized. Thanks to @dholmes-ora for providing this workaround. >> >> No new regression test, hard to reproduce. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2655 From xuelei at openjdk.java.net Mon Feb 22 21:39:41 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 22 Feb 2021 21:39:41 GMT Subject: RFR: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages [v3] In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 21:28:57 GMT, Jamil Nimeh wrote: >> This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client | server].SignatureSchemes property and its effect on messages that assert the signature_algorithms and signature_algorithms_cert extensions, or supported_signature_algorithms vectors like those used in TLS 1.2 CertificateRequest messages. With this change, the ordering of the signature algorithms in the property value will be preserved in the ordering as integer identifiers in the messages itself. Prior to this fix the property algorithms will be asserted, but in the order as shown in the sun.security.ssl.SignatureAlgorithms enumeration. >> >> This does not affect the default ordering of these signature schemes when the property is not given a value. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8255867 > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation, make test a derivation of SSLEngineTemplate Looks good to me. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2658 From jnimeh at openjdk.java.net Mon Feb 22 22:20:41 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Mon, 22 Feb 2021 22:20:41 GMT Subject: Integrated: 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages In-Reply-To: References: Message-ID: On Sat, 20 Feb 2021 01:56:37 GMT, Jamil Nimeh wrote: > This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client | server].SignatureSchemes property and its effect on messages that assert the signature_algorithms and signature_algorithms_cert extensions, or supported_signature_algorithms vectors like those used in TLS 1.2 CertificateRequest messages. With this change, the ordering of the signature algorithms in the property value will be preserved in the ordering as integer identifiers in the messages itself. Prior to this fix the property algorithms will be asserted, but in the order as shown in the sun.security.ssl.SignatureAlgorithms enumeration. > > This does not affect the default ordering of these signature schemes when the property is not given a value. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255867 This pull request has now been integrated. Changeset: a30fb4fc Author: Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/a30fb4fc Stats: 356 lines in 3 files changed: 342 ins; 0 del; 14 mod 8255867: SignatureScheme JSSE property does not preserve ordering in handshake messages Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/2658 From jjiang at openjdk.java.net Mon Feb 22 22:33:58 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Mon, 22 Feb 2021 22:33:58 GMT Subject: RFR: JDK-8261969: SNIHostName should check if the encoded hostname conform to RFC 3490 [v2] In-Reply-To: References: Message-ID: > Similar to the constructor SNIHostName(String hostname), the constructor SNIHostName(byte[] encoded) also needs to check if the encoded hostname conform to RFC 3490. John Jiang 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 branch 'master' into jdk-8261969 - JDK-8261969: SNIHostName would check if the encoded hostname conform to RFC 3490 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2639/files - new: https://git.openjdk.java.net/jdk/pull/2639/files/59ba1c47..35041c54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2639&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2639&range=00-01 Stats: 3642 lines in 114 files changed: 2487 ins; 569 del; 586 mod Patch: https://git.openjdk.java.net/jdk/pull/2639.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2639/head:pull/2639 PR: https://git.openjdk.java.net/jdk/pull/2639 From jjiang at openjdk.java.net Mon Feb 22 22:40:45 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Mon, 22 Feb 2021 22:40:45 GMT Subject: RFR: JDK-8261969: SNIHostName should check if the encoded hostname conform to RFC 3490 [v2] In-Reply-To: <7tiRMJ8PX1YkuoFzgZG_1siabiav4VSZ5Jp3qJFL9y8=.2d6388c0-13d1-4153-84eb-493e8f519592@github.com> References: <7tiRMJ8PX1YkuoFzgZG_1siabiav4VSZ5Jp3qJFL9y8=.2d6388c0-13d1-4153-84eb-493e8f519592@github.com> Message-ID: On Mon, 22 Feb 2021 16:17:28 GMT, Rajan Halade wrote: >> John Jiang 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 branch 'master' into jdk-8261969 >> - JDK-8261969: SNIHostName would check if the encoded hostname conform to RFC 3490 > > Changes requested by rhalade (Reviewer). I wouldn't merge the master to this branch :-( ------------- PR: https://git.openjdk.java.net/jdk/pull/2639 From weijun at openjdk.java.net Tue Feb 23 01:02:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 23 Feb 2021 01:02:38 GMT Subject: Integrated: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. In-Reply-To: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> References: <3C0sd4mUyqGNlymHhKtSDrgc4bvjblUVVGQuE23OZz8=.1aab5138-0e7c-412e-9e1d-d064fe15064f@github.com> Message-ID: On Fri, 19 Feb 2021 21:44:15 GMT, Weijun Wang wrote: > `InetAddress` is loading native library `net` and at the same time `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a deadlock. > > We can access `InetAddress` in `SunNativeProvider.` before loading the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is initialized. Thanks to @dholmes-ora for providing this workaround. > > No new regression test, hard to reproduce. This pull request has now been integrated. Changeset: 991f7c13 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/991f7c13 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/2655 From weijun at openjdk.java.net Tue Feb 23 01:16:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 23 Feb 2021 01:16:33 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v4] In-Reply-To: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> Message-ID: > This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0. > > The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last import. Some are new. > > Several tests need to be updated because of internal method signature changes. > > The "Support RSA-PSS with parameters" commit introduces a new public API and would need a CSR. > > The last patch is one we just fixed several days ago. Weijun Wang 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 two new commits since the last revision: - Support RSA-PSS with parameters Header from folded patch '17': since 17 Header from folded patch 'pss-policy': Restrict digest algorithms used inside PSSParameterSpec - No more newInstance calls ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1206/files - new: https://git.openjdk.java.net/jdk/pull/1206/files/f7ee7648..a79df58e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1206&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1206&range=02-03 Stats: 496 lines in 7 files changed: 462 ins; 25 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1206/head:pull/1206 PR: https://git.openjdk.java.net/jdk/pull/1206 From luoziyi at openjdk.java.net Tue Feb 23 01:43:56 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Tue, 23 Feb 2021 01:43:56 GMT Subject: RFR: 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards Message-ID: All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most cases, the requested KeySpec is equal to the concrete implementation so the inversion does not matter. But there are few cases, as presented in the added jtreg test, will cause unexpected behavior (e.g., ClassCastException rather than an InvalidKeySpecException). The fix is trivial. ------------- Commit messages: - 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards Changes: https://git.openjdk.java.net/jdk/pull/2681/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2681&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254717 Stats: 112 lines in 15 files changed: 71 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/2681.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2681/head:pull/2681 PR: https://git.openjdk.java.net/jdk/pull/2681 From luoziyi at openjdk.java.net Tue Feb 23 01:46:41 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Tue, 23 Feb 2021 01:46:41 GMT Subject: RFR: 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards In-Reply-To: References: Message-ID: <1vUryEDdfj_6IrCIRpXmKWPnJ7HgsPBhy5AQhhH2XJc=.8a1ac4e1-7c48-4bf1-abfb-0ee14c28a4fb@github.com> On Tue, 23 Feb 2021 01:38:36 GMT, Ziyi Luo wrote: > All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most cases, the requested KeySpec is equal to the concrete implementation so the inversion does not matter. But there are few cases, as presented in the added jtreg test, will cause unexpected behavior (e.g., ClassCastException rather than an InvalidKeySpecException). The fix is trivial. Will change the branch and submit a new one ------------- PR: https://git.openjdk.java.net/jdk/pull/2681 From luoziyi at openjdk.java.net Tue Feb 23 01:46:41 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Tue, 23 Feb 2021 01:46:41 GMT Subject: Withdrawn: 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 01:38:36 GMT, Ziyi Luo wrote: > All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most cases, the requested KeySpec is equal to the concrete implementation so the inversion does not matter. But there are few cases, as presented in the added jtreg test, will cause unexpected behavior (e.g., ClassCastException rather than an InvalidKeySpecException). The fix is trivial. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2681 From luoziyi at openjdk.java.net Tue Feb 23 01:52:54 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Tue, 23 Feb 2021 01:52:54 GMT Subject: RFR: 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards Message-ID: All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most cases, the requested KeySpec is equal to the concrete implementation so the inversion does not matter. But there are few cases, as presented in the added jtreg test, will cause unexpected behavior (e.g., ClassCastException rather than an InvalidKeySpecException). The fix is trivial. ------------- Commit messages: - 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards Changes: https://git.openjdk.java.net/jdk/pull/2682/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2682&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254717 Stats: 112 lines in 15 files changed: 71 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/2682.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2682/head:pull/2682 PR: https://git.openjdk.java.net/jdk/pull/2682 From jjiang at openjdk.java.net Tue Feb 23 02:10:58 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Tue, 23 Feb 2021 02:10:58 GMT Subject: RFR: JDK-8261969: SNIHostName should check if the encoded hostname conform to RFC 3490 [v3] In-Reply-To: References: Message-ID: > Similar to the constructor SNIHostName(String hostname), the constructor SNIHostName(byte[] encoded) also needs to check if the encoded hostname conform to RFC 3490. John Jiang has updated the pull request incrementally with one additional commit since the last revision: Throw RuntimeException instead of Exception ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2639/files - new: https://git.openjdk.java.net/jdk/pull/2639/files/35041c54..5801cf3f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2639&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2639&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2639.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2639/head:pull/2639 PR: https://git.openjdk.java.net/jdk/pull/2639 From weijun at openjdk.java.net Tue Feb 23 04:11:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 23 Feb 2021 04:11:40 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v4] In-Reply-To: <2xmxyLwSG2TZBwsomKHoeH6HPoq3ksEoUcD6qKmFDOs=.85e21651-8c03-4367-9396-07b0a305dd2a@github.com> References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> <6mjKEZHZfj4PWQqtpMPGTGeotuxQ76KgxP5kgFVt1NI=.64f5afd1-a67b-40a5-958e-290a22853545@github.com> <2xmxyLwSG2TZBwsomKHoeH6HPoq3ksEoUcD6qKmFDOs=.85e21651-8c03-4367-9396-07b0a305dd2a@github.com> Message-ID: On Mon, 11 Jan 2021 17:58:03 GMT, Weijun Wang wrote: >> I've force pushed a new series of commits from scratch. The difference: >> >> 1. The `s/Portions copyright/Copyright/` change is inside auto import. >> 2. Some `s/Sun Microsystems/Oracle/` change in auto import >> 3. No more deprecated `newInstance()` calls, a new (the last one) commit is created for this > > A CSR at https://bugs.openjdk.java.net/browse/JDK-8259575 is created. I'll remember to update the `@since 16` in source to 17 some time. I've refreshed the "Support RSA-PSS with parameters" commit on secureValidation check and added a new test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From jlaskey at openjdk.java.net Tue Feb 23 14:07:02 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 23 Feb 2021 14:07:02 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v23] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Various corrects ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/61f5d700..eeab6454 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=21-22 Stats: 34 lines in 4 files changed: 20 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Tue Feb 23 14:14:04 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 23 Feb 2021 14:14:04 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v24] In-Reply-To: References: Message-ID: <8yP2fkwGtSY6TDhYSRw9kCjAPru-mVik-6R_oJsK9Nc=.c89ee245-7a76-4933-b785-81ed117a887a@github.com> > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: L32X64StarStarRandom -> L32X64MixRandom ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/eeab6454..58a05f4c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=22-23 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Tue Feb 23 16:47:59 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 23 Feb 2021 16:47:59 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Merge branch 'master' into 8248862 - Adjust ThreadLocalRandom javadoc inheritence - L32X64StarStarRandom -> L32X64MixRandom - Various corrects - Revised javadoc per CSR reviews - Remove tabs from random/package-info.java - Correct copyright notice. - Merge branch 'master' into 8248862 - Update tests for RandomGeneratorFactory.all() - Merge branch 'master' into 8248862 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/0257caad...b9094279 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=24 Stats: 13693 lines in 26 files changed: 11542 ins; 2066 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From weijun at openjdk.java.net Tue Feb 23 18:16:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 23 Feb 2021 18:16:42 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 In-Reply-To: References: Message-ID: <927dgerK7IHGp5_DOmDx7ZSMFwifoTF0nDi3dzeHJ6A=.586494fd-5a2b-46f6-82d9-5073bd6f2cfd@github.com> On Mon, 22 Feb 2021 16:39:56 GMT, Fernando Guallini wrote: > Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: > `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` > > New and old format are not compatible, that means they cannot share a rcache file. Since there is no interoperability between java GSS-API and native GSS-API new rcache format at the moment, this patch only enables the test scenarios that mimic AP-REQ replays with multiple processes using native GSS-API only (when available) and multiple processes using Java own implementation API only. > > If there is a decision to support the new format in the future, tests will be revisited accordingly. Only one nit. test/jdk/sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java line 40: > 38: * -Djdk.net.hosts.file=TestHosts > 39: * -Dtest.service=host > 40: * -Dtest.libs=N ReplayCacheTestProc No need to test native libs with MD5. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2676 From fguallini at openjdk.java.net Tue Feb 23 18:56:03 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 23 Feb 2021 18:56:03 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2] In-Reply-To: References: Message-ID: <5zNdoJLnJz8zr_vu8Lrx6Os9aI9o3lOAPeuHJApaQ7k=.edfe6e0b-62a2-4df8-acac-b1df758d22e6@github.com> > Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: > `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` > > New and old format are not compatible, that means they cannot share a rcache file. Since there is no interoperability between java GSS-API and native GSS-API new rcache format at the moment, this patch only enables the test scenarios that mimic AP-REQ replays with multiple processes using native GSS-API only (when available) and multiple processes using Java own implementation API only. > > If there is a decision to support the new format in the future, tests will be revisited accordingly. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: remove native lib test with MD5 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2676/files - new: https://git.openjdk.java.net/jdk/pull/2676/files/abfa28ba..142b151b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2676&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2676&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2676.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2676/head:pull/2676 PR: https://git.openjdk.java.net/jdk/pull/2676 From fguallini at openjdk.java.net Tue Feb 23 18:56:05 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 23 Feb 2021 18:56:05 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2] In-Reply-To: <927dgerK7IHGp5_DOmDx7ZSMFwifoTF0nDi3dzeHJ6A=.586494fd-5a2b-46f6-82d9-5073bd6f2cfd@github.com> References: <927dgerK7IHGp5_DOmDx7ZSMFwifoTF0nDi3dzeHJ6A=.586494fd-5a2b-46f6-82d9-5073bd6f2cfd@github.com> Message-ID: <9lGqDqYwtAbehX__BARXO3iM7GmpkpgxuHyOpm8qN6E=.a66279d4-984d-4707-aade-0a734ada223b@github.com> On Tue, 23 Feb 2021 18:13:24 GMT, Weijun Wang wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> remove native lib test with MD5 > > test/jdk/sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java line 40: > >> 38: * -Djdk.net.hosts.file=TestHosts >> 39: * -Dtest.service=host >> 40: * -Dtest.libs=N ReplayCacheTestProc > > No need to test native libs with MD5. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/2676 From ascarpino at openjdk.java.net Tue Feb 23 20:40:05 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 23 Feb 2021 20:40:05 GMT Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling [v2] In-Reply-To: References: Message-ID: > Hi, > > I need a code review of this change to ECDH. It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling. They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place. The new exception handling is a result of no longer having the native library. Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException > > thanks, > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: Simpler fix for ECPrivateKey ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2659/files - new: https://git.openjdk.java.net/jdk/pull/2659/files/3451055a..aec24cc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2659&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2659&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2659.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2659/head:pull/2659 PR: https://git.openjdk.java.net/jdk/pull/2659 From rhalade at openjdk.java.net Tue Feb 23 22:52:45 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 23 Feb 2021 22:52:45 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2] In-Reply-To: <5zNdoJLnJz8zr_vu8Lrx6Os9aI9o3lOAPeuHJApaQ7k=.edfe6e0b-62a2-4df8-acac-b1df758d22e6@github.com> References: <5zNdoJLnJz8zr_vu8Lrx6Os9aI9o3lOAPeuHJApaQ7k=.edfe6e0b-62a2-4df8-acac-b1df758d22e6@github.com> Message-ID: <0_BDAqEgJVI6Usv9xKUuRP8VGl0PtWbhuvOSQzB3skc=.74b9e49b-03f8-4eb5-9255-4f62759140a5@github.com> On Tue, 23 Feb 2021 18:56:03 GMT, Fernando Guallini wrote: >> Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: >> `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` >> >> New and old format are not compatible, that means they cannot share a rcache file. Since there is no interoperability between java GSS-API and native GSS-API new rcache format at the moment, this patch only enables the test scenarios that mimic AP-REQ replays with multiple processes using native GSS-API only (when available) and multiple processes using Java own implementation API only. >> >> If there is a decision to support the new format in the future, tests will be revisited accordingly. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > remove native lib test with MD5 test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java line 127: > 125: libs = userLibs.split(","); > 126: if (Arrays.asList(libs).contains("N") && !isNativeLibAvailable()) { > 127: System.out.println("Native mode not available - skipped"); Can you please add a comment here with which scenarios are skipped? ------------- PR: https://git.openjdk.java.net/jdk/pull/2676 From weijun at openjdk.java.net Wed Feb 24 01:43:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 24 Feb 2021 01:43:53 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos Message-ID: Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). ------------- Commit messages: - 8139348: Deprecate 3DES and RC4 in Kerberos Changes: https://git.openjdk.java.net/jdk/pull/2701/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2701&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8139348 Stats: 36 lines in 5 files changed: 7 ins; 3 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/2701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2701/head:pull/2701 PR: https://git.openjdk.java.net/jdk/pull/2701 From jnimeh at openjdk.java.net Wed Feb 24 02:45:38 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Wed, 24 Feb 2021 02:45:38 GMT Subject: RFR: 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 01:47:48 GMT, Ziyi Luo wrote: > All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most cases, the requested KeySpec is equal to the concrete implementation so the inversion does not matter. But there are few cases, as presented in the added jtreg test, will cause unexpected behavior (e.g., ClassCastException rather than an InvalidKeySpecException). The fix is trivial. > > Co-author @SalusaSecondus The fix itself makes sense and looks good to me. However I think it will cause two other tests to break. Please try running the following two tests with your changes and see if they fail for you as they did for me: open/test/jdk/sun/security/rsa/TestKeyFactory.java open/test/jdk/sun/security/rsa/pss/TestPSSKeySupport.java Also just a minor nit: some of the modified files should have their copyright dates updated to 2021. test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 2: > 1: /* > 2: * Copyright (c) 2011, Amazon.com, Inc. or its affiliates. All rights reserved. Nit: Should this be 2021? test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 27: > 25: * @test > 26: * @bug 8254717 > 27: * @summary Two users facing implications caused by "isAssignableFrom" checks in "engineGetKeySpec" being backwards. Nit: I think standard practice is to have the summary be the synopsis from JDK-8254717 (isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards). ------------- PR: https://git.openjdk.java.net/jdk/pull/2682 From alanb at openjdk.java.net Wed Feb 24 08:54:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 24 Feb 2021 08:54:42 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67: > 65: private final SinkChannel sink; > 66: > 67: private static class Initializer This one is okay to do. src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java line 51: > 49: * Represents a service provider in the services catalog. > 50: */ > 51: public static final class ServiceProvider { This one is okay to do. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From fguallini at openjdk.java.net Wed Feb 24 12:34:16 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 24 Feb 2021 12:34:16 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v3] In-Reply-To: References: Message-ID: > Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: > `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` > > New and old format are not compatible, that means they cannot share a rcache file. Since there is no interoperability between java GSS-API and native GSS-API new rcache format at the moment, this patch only enables the test scenarios that mimic AP-REQ replays with multiple processes using native GSS-API only (when available) and multiple processes using Java own implementation API only. > > If there is a decision to support the new format in the future, tests will be revisited accordingly. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add comment when scenario is skipped ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2676/files - new: https://git.openjdk.java.net/jdk/pull/2676/files/142b151b..d153db17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2676&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2676&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2676.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2676/head:pull/2676 PR: https://git.openjdk.java.net/jdk/pull/2676 From fguallini at openjdk.java.net Wed Feb 24 12:34:17 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 24 Feb 2021 12:34:17 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2] In-Reply-To: <0_BDAqEgJVI6Usv9xKUuRP8VGl0PtWbhuvOSQzB3skc=.74b9e49b-03f8-4eb5-9255-4f62759140a5@github.com> References: <5zNdoJLnJz8zr_vu8Lrx6Os9aI9o3lOAPeuHJApaQ7k=.edfe6e0b-62a2-4df8-acac-b1df758d22e6@github.com> <0_BDAqEgJVI6Usv9xKUuRP8VGl0PtWbhuvOSQzB3skc=.74b9e49b-03f8-4eb5-9255-4f62759140a5@github.com> Message-ID: <0RVUeYm-TkbHkVps-SBI5SNeXI1-j546XzJRTm6l8FQ=.b9b19ca5-71b1-40e7-ac0e-143598f3f485@github.com> On Tue, 23 Feb 2021 22:43:09 GMT, Rajan Halade wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> remove native lib test with MD5 > > test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java line 127: > >> 125: libs = userLibs.split(","); >> 126: if (Arrays.asList(libs).contains("N") && !isNativeLibAvailable()) { >> 127: System.out.println("Native mode not available - skipped"); > > Can you please add a comment here with which scenarios are skipped? Added an extra comment there. ------------- PR: https://git.openjdk.java.net/jdk/pull/2676 From rhalade at openjdk.java.net Wed Feb 24 16:45:45 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 24 Feb 2021 16:45:45 GMT Subject: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v3] In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 12:34:16 GMT, Fernando Guallini wrote: >> Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: >> `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` >> >> New and old format are not compatible, that means they cannot share a rcache file. Since there is no interoperability between java GSS-API and native GSS-API new rcache format at the moment, this patch only enables the test scenarios that mimic AP-REQ replays with multiple processes using native GSS-API only (when available) and multiple processes using Java own implementation API only. >> >> If there is a decision to support the new format in the future, tests will be revisited accordingly. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > add comment when scenario is skipped Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2676 From fguallini at openjdk.java.net Wed Feb 24 17:08:40 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 24 Feb 2021 17:08:40 GMT Subject: Integrated: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 16:39:56 GMT, Fernando Guallini wrote: > Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: > `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` > > New and old format are not compatible, that means they cannot share a rcache file. Since there is no interoperability between java GSS-API and native GSS-API new rcache format at the moment, this patch only enables the test scenarios that mimic AP-REQ replays with multiple processes using native GSS-API only (when available) and multiple processes using Java own implementation API only. > > If there is a decision to support the new format in the future, tests will be revisited accordingly. This pull request has now been integrated. Changeset: d70fd7b3 Author: Fernando Guallini Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/d70fd7b3 Stats: 46 lines in 3 files changed: 21 ins; 22 del; 3 mod 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 Reviewed-by: weijun, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/2676 From mullan at openjdk.java.net Wed Feb 24 21:36:41 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 24 Feb 2021 21:36:41 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos In-Reply-To: References: Message-ID: <8EvtA2wwRmvxEoioQ3qL91TPPGwT8J5rv0ysUI2PH6c=.e2023760-955a-4545-bb80-88598029d8ed@github.com> On Wed, 24 Feb 2021 01:38:07 GMT, Weijun Wang wrote: > Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). Is there a test that checks that the weak algorithms are actually disabled? I wasn't sure if I saw anything or maybe that is another test that you didn't have to modify? test/jdk/sun/security/krb5/auto/NewSalt.java line 26: > 24: /* > 25: * @test > 26: * @bug 6960894 8194486 8139348 I don't know if there are any rules or best practices about this, but I usually don't put a bugid on a test if it isn't specifically testing what this bug is about. ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From weijun at openjdk.java.net Wed Feb 24 21:40:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 24 Feb 2021 21:40:45 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos In-Reply-To: <8EvtA2wwRmvxEoioQ3qL91TPPGwT8J5rv0ysUI2PH6c=.e2023760-955a-4545-bb80-88598029d8ed@github.com> References: <8EvtA2wwRmvxEoioQ3qL91TPPGwT8J5rv0ysUI2PH6c=.e2023760-955a-4545-bb80-88598029d8ed@github.com> Message-ID: On Wed, 24 Feb 2021 21:28:41 GMT, Sean Mullan wrote: >> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). > > test/jdk/sun/security/krb5/auto/NewSalt.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 6960894 8194486 8139348 > > I don't know if there are any rules or best practices about this, but I usually don't put a bugid on a test if it isn't specifically testing what this bug is about. OK, I'll remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From weijun at openjdk.java.net Wed Feb 24 21:46:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 24 Feb 2021 21:46:40 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos In-Reply-To: <8EvtA2wwRmvxEoioQ3qL91TPPGwT8J5rv0ysUI2PH6c=.e2023760-955a-4545-bb80-88598029d8ed@github.com> References: <8EvtA2wwRmvxEoioQ3qL91TPPGwT8J5rv0ysUI2PH6c=.e2023760-955a-4545-bb80-88598029d8ed@github.com> Message-ID: On Wed, 24 Feb 2021 21:33:33 GMT, Sean Mullan wrote: > Is there a test that checks that the weak algorithms are actually disabled? I wasn't sure if I saw anything or maybe that is another test that you didn't have to modify? Actually there's no. I can add all weak etypes into `onlythree.conf` and they should be ignored. ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From mullan at openjdk.java.net Wed Feb 24 22:00:40 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 24 Feb 2021 22:00:40 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures In-Reply-To: References: Message-ID: <4Xxe7A3kGMhmrAoEUTQwnLqhkuRPxl9t-preUs3XBRA=.53b0dc19-3c94-409b-ac6a-062a8e34ca9b@github.com> On Mon, 22 Feb 2021 03:42:23 GMT, Weijun Wang wrote: >> Please review this change to disable XML signatures that use SHA-1 based digest or signature algorithms. SHA-1 is weak and is not a recommended algorithm for digital signatures. This will improve out of the box security by restricting XML signatures that use SHA-1 algorithms. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8261246 >> Release Note: https://bugs.openjdk.java.net/browse/JDK-8261364 > > test/lib/jdk/test/lib/security/SecurityUtils.java line 78: > >> 76: * part of the algorithm URI. >> 77: */ >> 78: public static void removeAlgsFromDSigPolicy(List algs) { > > How about using `String... algs` as arguments? Yes, that is nicer. ------------- PR: https://git.openjdk.java.net/jdk/pull/2463 From mullan at openjdk.java.net Wed Feb 24 22:05:40 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 24 Feb 2021 22:05:40 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 22:36:24 GMT, Weijun Wang wrote: > All test changes are about re-enabling disabled algorithms. Do we have a test on ensuring disabled algorithms are indeed disabled? How about we set "org.jcp.xml.dsig.secureValidation" to false everywhere in the existing tests and add a new dedicated test to check for disabled algorithms/key sizes etc. That is what test/jdk/javax/xml/crypto/dsig/SecureValidationPolicy.java does, see this code block on lines 65-69: for (String alg : restrictedAlgs) { if (!Policy.restrictAlg(alg)) { throw new Exception(alg + " alg not restricted"); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/2463 From weijun at openjdk.java.net Wed Feb 24 22:25:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 24 Feb 2021 22:25:52 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos [v2] In-Reply-To: References: Message-ID: > Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: test updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2701/files - new: https://git.openjdk.java.net/jdk/pull/2701/files/1b2764fd..146bc47a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2701&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2701&range=00-01 Stats: 42 lines in 5 files changed: 22 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2701/head:pull/2701 PR: https://git.openjdk.java.net/jdk/pull/2701 From weijun at openjdk.java.net Wed Feb 24 22:25:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 24 Feb 2021 22:25:52 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos In-Reply-To: References: <8EvtA2wwRmvxEoioQ3qL91TPPGwT8J5rv0ysUI2PH6c=.e2023760-955a-4545-bb80-88598029d8ed@github.com> Message-ID: On Wed, 24 Feb 2021 21:43:52 GMT, Weijun Wang wrote: >> Is there a test that checks that the weak algorithms are actually disabled? I wasn't sure if I saw anything or maybe that is another test that you didn't have to modify? > >> Is there a test that checks that the weak algorithms are actually disabled? I wasn't sure if I saw anything or maybe that is another test that you didn't have to modify? > > Yes there's one and I'll update it. I can also add all weak etypes into `onlythree.conf` and they should be ignored. Updated tests. There is a `weakcrypto.conf` file which has been useless for a long time since `WeakCrypto.java` generates krb5.conf on the fly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From weijun at openjdk.java.net Wed Feb 24 22:33:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 24 Feb 2021 22:33:38 GMT Subject: RFR: 8259709: Disable SHA-1 XML Signatures In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 22:02:45 GMT, Sean Mullan wrote: > > All test changes are about re-enabling disabled algorithms. Do we have a test on ensuring disabled algorithms are indeed disabled? How about we set "org.jcp.xml.dsig.secureValidation" to false everywhere in the existing tests and add a new dedicated test to check for disabled algorithms/key sizes etc. > > That is what test/jdk/javax/xml/crypto/dsig/SecureValidationPolicy.java does, see this code block on lines 65-69: > > ``` > for (String alg : restrictedAlgs) { > if (!Policy.restrictAlg(alg)) { > throw new Exception(alg + " alg not restricted"); > } > } > ``` This is only about checking the parsing function of the Policy class. I would be more confident if an actual validation call is made. I have a test on PSS at https://github.com/openjdk/jdk/blob/a79df58e0ad0b19aa8e0611cc55f5628383c2950/test/jdk/javax/xml/crypto/dsig/SecureValidation.java. Maybe I can enhance it to contain more algorithms. ------------- PR: https://git.openjdk.java.net/jdk/pull/2463 From weijun at openjdk.java.net Thu Feb 25 00:19:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 25 Feb 2021 00:19:41 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos In-Reply-To: References: <8EvtA2wwRmvxEoioQ3qL91TPPGwT8J5rv0ysUI2PH6c=.e2023760-955a-4545-bb80-88598029d8ed@github.com> Message-ID: On Wed, 24 Feb 2021 22:23:14 GMT, Weijun Wang wrote: >>> Is there a test that checks that the weak algorithms are actually disabled? I wasn't sure if I saw anything or maybe that is another test that you didn't have to modify? >> >> Yes there's one and I'll update it. I can also add all weak etypes into `onlythree.conf` and they should be ignored. > > Updated tests. There is a `weakcrypto.conf` file which has been useless for a long time since `WeakCrypto.java` generates krb5.conf on the fly. Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8262335. ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From github.com+10835776+stsypanov at openjdk.java.net Thu Feb 25 11:07:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 25 Feb 2021 11:07:47 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 08:50:36 GMT, Alan Bateman wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8261880: Remove static from declarations of Holder nested classes > > src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67: > >> 65: private final SinkChannel sink; >> 66: >> 67: private static class Initializer > > This one is okay to do. Thanks for review! Could you review the rest of the code and approve this PR, if it's fine? ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From jjiang at openjdk.java.net Thu Feb 25 13:38:44 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 25 Feb 2021 13:38:44 GMT Subject: RFR: JDK-8261969: SNIHostName should check if the encoded hostname conform to RFC 3490 [v3] In-Reply-To: References: <7tiRMJ8PX1YkuoFzgZG_1siabiav4VSZ5Jp3qJFL9y8=.2d6388c0-13d1-4153-84eb-493e8f519592@github.com> Message-ID: <9r7SnJfBEna8TfvXOKqmftAuRnHl5VGSeBuJSytnSaE=.f74979f6-f2e0-4af4-b016-f936e9928d9a@github.com> On Mon, 22 Feb 2021 22:38:19 GMT, John Jiang wrote: >> Changes requested by rhalade (Reviewer). > > I wouldn't merge the master to this branch :-( Could the latest patch be reviewed? ------------- PR: https://git.openjdk.java.net/jdk/pull/2639 From mullan at openjdk.java.net Thu Feb 25 13:43:42 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 25 Feb 2021 13:43:42 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos [v2] In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 22:25:52 GMT, Weijun Wang wrote: >> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > test updates Marked as reviewed by mullan (Reviewer). test/jdk/sun/security/krb5/auto/W83.java line 26: > 24: /* > 25: * @test > 26: * @bug 6932525 6951366 6959292 8194486 8139348 I don't think you should add the bugid here since it isn't really about testing this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From weijun at openjdk.java.net Thu Feb 25 14:34:00 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 25 Feb 2021 14:34:00 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos [v3] In-Reply-To: References: Message-ID: > Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: no need to mention unrelated bug ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2701/files - new: https://git.openjdk.java.net/jdk/pull/2701/files/146bc47a..0e7a61dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2701&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2701&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2701/head:pull/2701 PR: https://git.openjdk.java.net/jdk/pull/2701 From weijun at openjdk.java.net Thu Feb 25 14:34:01 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 25 Feb 2021 14:34:01 GMT Subject: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos [v2] In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 13:40:59 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> test updates > > test/jdk/sun/security/krb5/auto/W83.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 6932525 6951366 6959292 8194486 8139348 > > I don't think you should add the bugid here since it isn't really about testing this change. OK, so as long as a test is not meant to test the change for a bug, then its bugid should not appear there. ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From gziemski at openjdk.java.net Thu Feb 25 17:34:58 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 25 Feb 2021 17:34:58 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: > > - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos > - Re-do safefetch.hpp > - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos > - stubRoutines.inline.hpp -> safefetch.hpp > - Update copyrights > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Extract SafeFetch32/N to stubRoutines.inline.hpp > - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" > > This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. > - Merge pull request #9 from VladimirKempik/pull/2200 > > Removed unused variables > - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From martin.doerr at sap.com Mon Feb 8 13:28:39 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 08 Feb 2021 13:28:39 -0000 Subject: [11u] RFR: 8244683: A TSA server used by tests In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Montag, 8. Februar 2021 14:18 To: Doerr, Martin ; security-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8244683: A TSA server used by tests Hi Martin, Thanks for downporting this. Nice documentation of the changes! Looks good. Best regards, Goetz. From: Doerr, Martin > Sent: Tuesday, February 2, 2021 9:28 PM To: security-dev >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8244683: A TSA server used by tests Hi, JDK-8244683 is backported to 11.0.11-oracle. I'd like to backport it for parity. It doesn't apply cleanly. TimestampCheck.java: - The parts which get removed contain minor differences (see [1]) - Resolution: Take new version. TsaHandler.java and TsaSigner.java: - New code contains usages of KnownOIDs which don't exist in 11u. - Resolution: Translate them (see [2]) TsaSigner.java: - New code uses ObjectIdentifier.of - Resolution: Change back to "new ObjectIdentifier" according to [1] - Uses HexPrinter (for debug code) which doesn't exist in 11u. - Resolution: Use HexDumpEncoder instead: System.out.println(new HexDumpEncoder().encode(bytes)); An additional testfix is needed: https://bugs.openjdk.java.net/browse/JDK-8246709 which applies cleanly except that it needs an import change (see [3]). That change is not included in the webrev. I just want to push 11u backport of 8244683 together with 8246709 (including [3]) together. Bug: https://bugs.openjdk.java.net/browse/JDK-8244683 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/56bda3e6d148 11u backport: http://cr.openjdk.java.net/~mdoerr/8244683_TSA_11u/webrev.00/ Please review. Best regards, Martin [1] diff JDK11u:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java JDK16:TimestampCheck_before_8244683.java 65a66 > * 8242151 137c138 < ObjectIdentifier policyId = new ObjectIdentifier(defaultPolicyId); --- > ObjectIdentifier policyId = ObjectIdentifier.of(defaultPolicyId); 161c162 < policyId = new ObjectIdentifier(defaultPolicyId); --- > policyId = ObjectIdentifier.of(defaultPolicyId); 233c234 < ContentInfo contentInfo = new ContentInfo(new ObjectIdentifier( --- > ContentInfo contentInfo = new ContentInfo(ObjectIdentifier.of( [2] KnownOIDs Translation: https://github.com/openjdk/jdk/commit/080b3b83ebffe5149fbc9ac48e921fb51e9c3c63#diff-e6d5bd6b166be4737084473fcf55b0f101a710263c899c19b0df2a702c89a30e [3] diff JDK16:TSA_testfix_orig.patch resolved_JDK11u:8246709_TSA.patch < import jdk.test.lib.process.OutputAnalyzer; --- > import jdk.testlibrary.OutputAnalyzer; -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Feb 18 11:11:19 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 18 Feb 2021 11:11:19 +0000 Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore Message-ID: Hi, JDK-8256421 is backported to 11.0.11-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I'm using the jdk16u backport. See "Fix Request (jdk16u)" comment. VerifyCACerts.java: I had to change the COUNT manually: - private static final int COUNT = 95; + private static final int COUNT = 97; And I've computed the new CHECKSUM which gets verified by the test: shasum -a 256 jdk/lib/security/cacerts | sed -e 's/../&:/g' | tr '[:lower:]' '[:upper:]' | cut -c1-95 9F:6B:41:1D:05:AF:E3:C5:4F:E8:39:89:50:79:60:B1:F6:A4:02:40:0C:28:8D:73:78:08:E5:61:7C:17:EA:59 Bug: https://bugs.openjdk.java.net/browse/JDK-8256421 Original change (from 16u): https://github.com/openjdk/jdk16u/commit/4ccaf6b8 11u backport: http://cr.openjdk.java.net/~mdoerr/8256421_HARICA_cacerts_11u/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Feb 18 13:47:12 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 18 Feb 2021 13:47:12 +0000 Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review and the approval! Best regards, Martin From: Langer, Christoph Sent: Donnerstag, 18. Februar 2021 14:11 To: Doerr, Martin ; security-dev ; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: RE: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore Hi Martin, this backport looks good to me. Best regards Christoph From: Doerr, Martin > Sent: Donnerstag, 18. Februar 2021 12:11 To: security-dev >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore Hi, JDK-8256421 is backported to 11.0.11-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I'm using the jdk16u backport. See "Fix Request (jdk16u)" comment. VerifyCACerts.java: I had to change the COUNT manually: - private static final int COUNT = 95; + private static final int COUNT = 97; And I've computed the new CHECKSUM which gets verified by the test: shasum -a 256 jdk/lib/security/cacerts | sed -e 's/../&:/g' | tr '[:lower:]' '[:upper:]' | cut -c1-95 9F:6B:41:1D:05:AF:E3:C5:4F:E8:39:89:50:79:60:B1:F6:A4:02:40:0C:28:8D:73:78:08:E5:61:7C:17:EA:59 Bug: https://bugs.openjdk.java.net/browse/JDK-8256421 Original change (from 16u): https://github.com/openjdk/jdk16u/commit/4ccaf6b8 11u backport: http://cr.openjdk.java.net/~mdoerr/8256421_HARICA_cacerts_11u/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Thu Feb 25 18:53:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 25 Feb 2021 18:53:39 GMT Subject: Integrated: 8139348: Deprecate 3DES and RC4 in Kerberos In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 01:38:07 GMT, Weijun Wang wrote: > Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). This pull request has now been integrated. Changeset: ded96ddc Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/ded96ddc Stats: 72 lines in 7 files changed: 29 ins; 8 del; 35 mod 8139348: Deprecate 3DES and RC4 in Kerberos Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2701 From weijun at openjdk.java.net Thu Feb 25 21:02:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 25 Feb 2021 21:02:52 GMT Subject: RFR: 8262389: Use permitted_enctypes if default_tkt_enctypes or default_tgs_enctypes is not present Message-ID: When default_tkt_enctypes or default_tgs_enctypes, use the value of permitted_enctypes if it exists. Please also review the CSR at https://bugs.openjdk.java.net/browse/JDK-8262391 and release note at https://bugs.openjdk.java.net/browse/JDK-8262401. ------------- Commit messages: - 8262389: Use permitted_enctypes if default_tkt_enctypes or default_tgs_enctypes is not present Changes: https://git.openjdk.java.net/jdk/pull/2729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2729&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262389 Stats: 60 lines in 2 files changed: 60 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2729/head:pull/2729 PR: https://git.openjdk.java.net/jdk/pull/2729 From akolarkunnu at openjdk.java.net Fri Feb 26 11:18:51 2021 From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu) Date: Fri, 26 Feb 2021 11:18:51 GMT Subject: RFR: 8260923: Add more tests for SSLSocket input/output shutdown Message-ID: There is a lack of tests in the area of java.net.Socket.shutdownInput() and java.net.Socket.shutdownOutput() , so added more tests in this area of with different TLS versions. Please review. ------------- Commit messages: - 8260923: Add more tests for SSLSocket input/output shutdown Changes: https://git.openjdk.java.net/jdk/pull/2745/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2745&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260923 Stats: 59 lines in 1 file changed: 37 ins; 13 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2745.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2745/head:pull/2745 PR: https://git.openjdk.java.net/jdk/pull/2745 From akozlov at openjdk.java.net Fri Feb 26 12:26:18 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 26 Feb 2021 12:26:18 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v19] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits: - Merge branch 'master' into jdk-macos - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Re-do safefetch.hpp - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos - stubRoutines.inline.hpp -> safefetch.hpp - Update copyrights - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Extract SafeFetch32/N to stubRoutines.inline.hpp - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. - ... and 79 more: https://git.openjdk.java.net/jdk/compare/d7efb4cc...74687c0b ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18 Stats: 2953 lines in 74 files changed: 2862 ins; 27 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 26 12:53:11 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 26 Feb 2021 12:53:11 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v20] In-Reply-To: References: Message-ID: <4ipGJ8KKE0_KPuWfExCo1jo3Tg9iewQkSKuZTcntoNE=.8c1c3dcb-4db2-4e0a-b42f-6db5f78c6406@github.com> > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #10 from VladimirKempik/pull/2200 Fix build after merge with master - Fix build after merge with master ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/74687c0b..241aedee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18-19 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 26 12:55:50 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 26 Feb 2021 12:55:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/java.base/macosx/native/libjli/java_md_macosx.m line 210: > >> 208: if (preferredJVM == NULL) { >> 209: #if defined(__i386__) >> 210: preferredJVM = "client"; > > #if defined(__i386__) > preferredJVM = "client"; > Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS. Hello I thought the openjdk7 supported 32-bit macos at some point in time ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+828220+forax at openjdk.java.net Fri Feb 26 13:20:47 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 26 Feb 2021 13:20:47 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: References: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> Message-ID: <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com> On Fri, 26 Feb 2021 13:13:19 GMT, Jim Laskey wrote: >> Stayin' alive > > Looking for some final code reviews. I still don't like the fact that the factory uses reflection but i don't see how to do better ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Fri Feb 26 13:20:46 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 26 Feb 2021 13:20:46 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> References: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> Message-ID: On Mon, 4 Jan 2021 13:54:14 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Stayin' alive Looking for some final code reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From ewhelan at openjdk.java.net Fri Feb 26 14:32:55 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Fri, 26 Feb 2021 14:32:55 GMT Subject: RFR: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" Message-ID: Hi all, Please review my test fix relating to JDK-8262438 This patch introduces as Thread.sleep at the start of each iteration which creates a new test jvm. This allows the server socket sufficient time to release the previous connection and allows the port to be used again. I also refactored the behaviour for when the exitCode is not 0, allowing for an easier to read output. An incorrect HttpsUrlConnection.disconnect() was also removed. The test was ran 100 times on all platforms and no failures were seen. Thanks, Evan ------------- Commit messages: - 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" Changes: https://git.openjdk.java.net/jdk/pull/2749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2749&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262438 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2749/head:pull/2749 PR: https://git.openjdk.java.net/jdk/pull/2749 From daniel.daugherty at oracle.com Fri Feb 26 14:37:11 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 26 Feb 2021 09:37:11 -0500 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <77712482-850c-3945-2c4e-7865544a412b@oracle.com> On 2/26/21 7:55 AM, Vladimir Kempik wrote: > On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: > >>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> support macos_aarch64 in hsdis >> src/java.base/macosx/native/libjli/java_md_macosx.m line 210: >> >>> 208: if (preferredJVM == NULL) { >>> 209: #if defined(__i386__) >>> 210: preferredJVM = "client"; >> #if defined(__i386__) >> preferredJVM = "client"; >> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS. > Hello > I thought the openjdk7 supported 32-bit macos at some point in time The macOS porting project supported 32-bit macOS, but when the code was integrated into OpenJDK7 I don't believe that 32-bit macOS was supported. I could be wrong... it was quite a while ago... Dan > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 From mullan at openjdk.java.net Fri Feb 26 14:41:40 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 26 Feb 2021 14:41:40 GMT Subject: RFR: 8259535: ECDSA SignatureValue do not always have the specified length In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 15:24:07 GMT, Weijun Wang wrote: > The code change fixes the ECDSA XML signature length issue. It should only happen when there is no P1363 ECDSA support, which is not true when SunEC is used. > > If a PrivateKey is not of ECPrivateKey type then the bug will still show up. Technically, we can drill into the OID/parameter of the ASN.1 encoding and do further evaluation, but I think this is not worth doing. Please advise me if you think differently. Marked as reviewed by mullan (Reviewer). src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java line 68: > 66: * > 67: * @param asn1Bytes > 68: * @param rawLen You should add the same javadoc for these parameters as you did in ECDSAUtils.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/2550 From erik.joelsson at oracle.com Fri Feb 26 15:06:39 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 26 Feb 2021 07:06:39 -0800 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: <77712482-850c-3945-2c4e-7865544a412b@oracle.com> References: <77712482-850c-3945-2c4e-7865544a412b@oracle.com> Message-ID: On 2021-02-26 06:37, daniel.daugherty at oracle.com wrote: > On 2/26/21 7:55 AM, Vladimir Kempik wrote: >> On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty >> wrote: >> >>>> Anton Kozlov has updated the pull request incrementally with one >>>> additional commit since the last revision: >>>> >>>> ?? support macos_aarch64 in hsdis >>> src/java.base/macosx/native/libjli/java_md_macosx.m line 210: >>> >>>> 208:???? if (preferredJVM == NULL) { >>>> 209: #if defined(__i386__) >>>> 210:???????? preferredJVM = "client"; >>> #if defined(__i386__) >>> ???????? preferredJVM = "client"; >>> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on >>> macOS. >> Hello >> I thought the openjdk7 supported 32-bit macos at some point in time > > The macOS porting project supported 32-bit macOS, but when the code > was integrated into OpenJDK7 I don't believe that 32-bit macOS was > supported. I could be wrong... it was quite a while ago... > AFAIK, OpenJDK never supported 32bit macos, but there are certainly leftovers here and there indicating that the original source did at some point. In the build system we cleaned that up a long time ago. /Erik From weijun at openjdk.java.net Fri Feb 26 15:37:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 26 Feb 2021 15:37:41 GMT Subject: RFR: 8259535: ECDSA SignatureValue do not always have the specified length In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 21:23:51 GMT, Sean Mullan wrote: >> The code change fixes the ECDSA XML signature length issue. It should only happen when there is no P1363 ECDSA support, which is not true when SunEC is used. >> >> If a PrivateKey is not of ECPrivateKey type then the bug will still show up. Technically, we can drill into the OID/parameter of the ASN.1 encoding and do further evaluation, but I think this is not worth doing. Please advise me if you think differently. > > src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java line 68: > >> 66: * >> 67: * @param asn1Bytes >> 68: * @param rawLen > > You should add the same javadoc for these parameters as you did in ECDSAUtils.java. Well, it looks like a "style" to only list the param names without any explanation in this file and nearby files. Since the body of this method is only one line I assume people curious about the meaning of the parameters can just navigate to `ECDSAUtils.convertASN1toXMLDSIG` to read the description there. Can we just keep it "clean"? ------------- PR: https://git.openjdk.java.net/jdk/pull/2550 From mullan at openjdk.java.net Fri Feb 26 16:05:01 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 26 Feb 2021 16:05:01 GMT Subject: RFR: 8259535: ECDSA SignatureValue do not always have the specified length In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 15:34:42 GMT, Weijun Wang wrote: >> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java line 68: >> >>> 66: * >>> 67: * @param asn1Bytes >>> 68: * @param rawLen >> >> You should add the same javadoc for these parameters as you did in ECDSAUtils.java. > > Well, it looks like a "style" to only list the param names without any explanation in this file and nearby files. Since the body of this method is only one line I assume people curious about the meaning of the parameters can just navigate to `ECDSAUtils.convertASN1toXMLDSIG` to read the description there. > > Can we just keep it "clean"? Ok, sounds reasonable. ------------- PR: https://git.openjdk.java.net/jdk/pull/2550 From weijun at openjdk.java.net Fri Feb 26 16:52:48 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 26 Feb 2021 16:52:48 GMT Subject: Integrated: 8259535: ECDSA SignatureValue do not always have the specified length In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 15:24:07 GMT, Weijun Wang wrote: > The code change fixes the ECDSA XML signature length issue. It should only happen when there is no P1363 ECDSA support, which is not true when SunEC is used. > > If a PrivateKey is not of ECPrivateKey type then the bug will still show up. Technically, we can drill into the OID/parameter of the ASN.1 encoding and do further evaluation, but I think this is not worth doing. Please advise me if you think differently. This pull request has now been integrated. Changeset: a4c24961 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/a4c24961 Stats: 227 lines in 4 files changed: 216 ins; 2 del; 9 mod 8259535: ECDSA SignatureValue do not always have the specified length Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2550 From dfuchs at openjdk.java.net Fri Feb 26 17:19:41 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 26 Feb 2021 17:19:41 GMT Subject: RFR: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 14:28:23 GMT, Evan Whelan wrote: > Hi all, > > Please review my test fix relating to JDK-8262438 > > This patch introduces as Thread.sleep at the start of each iteration which creates a new test jvm. > This allows the server socket sufficient time to release the previous connection and allows the port to be used again. > > I also refactored the behaviour for when the exitCode is not 0, allowing for an easier to read output. > An incorrect HttpsUrlConnection.disconnect() was also removed. > > The test was ran 100 times on all platforms and no failures were seen. > > Thanks, > Evan Hi Evan - I am a bit skeptical that the proposed fix will solve the issue. AFAICS the exception is raised by the server side - and if I read it correctly it happens when the server finds that the socket is already closed when it tries to close it. How could sleeping between 2 process invocation solve this? The port used is an ephemeral port - so it should never be the same? Does the log show that the same port was being reused? ------------- PR: https://git.openjdk.java.net/jdk/pull/2749 From akozlov at openjdk.java.net Fri Feb 26 19:17:12 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 26 Feb 2021 19:17:12 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - Minor fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/241aedee..663cb4a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19-20 Stats: 85 lines in 5 files changed: 0 ins; 80 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From rriggs at openjdk.java.net Fri Feb 26 21:53:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 26 Feb 2021 21:53:46 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 16:47:59 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - Merge branch 'master' into 8248862 > - Adjust ThreadLocalRandom javadoc inheritence > - L32X64StarStarRandom -> L32X64MixRandom > - Various corrects > - Revised javadoc per CSR reviews > - Remove tabs from random/package-info.java > - Correct copyright notice. > - Merge branch 'master' into 8248862 > - Update tests for RandomGeneratorFactory.all() > - Merge branch 'master' into 8248862 > - ... and 47 more: https://git.openjdk.java.net/jdk/compare/0257caad...b9094279 src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 232: > 230: Provider provider = fm.get(name); > 231: if (!isSubclass(category, provider)) { > 232: throw new IllegalArgumentException(name + " is an unknown random number generator"); The message is a bit vague. How about: "The random number generator does not support the category" src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 240: > 238: * Returns a {@link RandomGenerator} that utilizes the {@code name} > 239: * algorithm. > 240: * In javadoc, this seems like is should read as: "utilizes the named algorithm". The use of the parameter name is unnecessary in this case because it is obvious and readability suffers as is. src/java.base/share/classes/java/util/random/RandomGenerator.java line 1313: > 1311: * furthermore can easily jump to an arbitrarily specified distant > 1312: * point in the state cycle. > 1313: * The similarity of the first sentence of each of the Jumpable, Leapable, and arbitrarlyJumpable interface is so similar as to obscure the differences. You have to read 25 words in to be able to find the description that makes them different. The italics help but should include the whole of the phrase that distinguishes them. Alternatively, move the phrase to the beginning of the sentence or drop the redundant phrasing. "provide a common protocol of objects that generate pseudorandom sequences of numbers of Boolean values", etc. src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 55: > 53: * > 54: * A specific {@link RandomGeneratorFactory} can be located by using the > 55: * {@link RandomGenerator#factoryOf(String)} method, where the argument string Broken link: the method is in this class. should be just "#factoryOf". src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 600: > 598: try { > 599: ensureConstructors(); > 600: return ctorBytes.newInstance((Object)seed); IntelliJ warns that the cast to (Object) is redundant. src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 29: > 27: > 28: import java.lang.reflect.Constructor; > 29: import java.lang.reflect.Method; Used import. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From rriggs at openjdk.java.net Fri Feb 26 21:53:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 26 Feb 2021 21:53:47 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: References: Message-ID: <0VaZHVlAPVPZOyMk1UK1j3ujLDQEwYeYx3dG_cwBHfA=.9d457d8b-4625-4943-ae0f-935d2462f31d@github.com> On Wed, 25 Nov 2020 16:22:32 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 106: >> >>> 104: * Map of provider classes. >>> 105: */ >>> 106: private static volatile Map> factoryMap; >> >> should be FACTORY_MAP given that it's a static field > > will fall out of using class holder idiom IntelliJ warns that this volatile field is unused. It has been replaced by the method getFactoryMap(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1292