Integrated: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out
On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo wrote: > The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds > set on sslServerSocket. This time interval could be inadequate when the > machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So > the statement has been removed. This pull request has now been integrated. Changeset: 036ae0ea Author:Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/036ae0ea Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out Reviewed-by: xuelei, rhalade, hchao - PR: https://git.openjdk.java.net/jdk/pull/3116
Integrated: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo wrote: > The Test is updated to use positive integer as seed for SecureRandom. This pull request has now been integrated. Changeset: 5a51d709 Author:Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/5a51d709 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8247895: SHA1PRNGReseed.java is calling setSeed(0) Reviewed-by: weijun, rhalade - PR: https://git.openjdk.java.net/jdk/pull/3114
Re: RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed [v2]
On Mon, 22 Mar 2021 18:06:56 GMT, Weijun Wang wrote: >> We don't use `digest` anymore but still need to ignore the 0 argument. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > typo Marked as reviewed by valeriep (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3124
Re: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
On Sat, 20 Mar 2021 19:24:45 GMT, SalusaSecondus wrote: >> We seem to have a choice and I'm not sure the best way to approach this. >> >> 1. We trust the properties in `P11Key` and just ask it if the values are >> both sensitive and extractable. [1] >> 2. But if we already trust P11Key, why not also trust that it properly >> implements the RSAPrivateKey interfaces [2]. This is the strategy used by >> the snippet I posted earlier (delegating to `implGetSoftwareFactory()`) >> 3. We don't trust P11Key except to use getKeyId(), this yields the current >> design where we pull the attributes every time the factory needs them. >> >> We should probably reduce calls to `C_GetAttributeValue` as they may be very >> slow. At the least they cross the JNI boundary and at worst they interact >> with a slow piece of hardware (possibly over a network). The current design >> will have two calls in a worst case, but is likely to have only one call the >> vast majority of the time. >> >> [1] >> https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L92 >> [2] >> https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406 > > P11PrivateKey is private so we cannot check that. Our options to figure out > if something is sensitive are: > 1. See if it doesn't implement `RSAPrivateKey` (this yields the prior snippet > with `implGetSoftwareFactory()`) > 2. Try to access the attributes directly from the token (this yields the > current solution which we're modifying) > 3. Check the value of `p11Key.extractable` (which is package-private and thus > visible) > > The smallest change would be to keep our strategy as 2. While I like it the > least (my favorite is number 1) it has the smallest risk of changing some > undocumented behavior on a PKCS#11 device that we're unfamiliar with (and not > testing because we may not have the hardware costing tens of thousands of > dollars). Option 3 somewhat spits the difference between 1 and 2. Or, how about changing the scope of P11PrivateKey/P11RSAPrivateKey/P11RSAPrivateNonCRTKey to pkg private? This way we can take advantage of the info implied by the type of class and avoid the potential double failure of querying the attributes. - PR: https://git.openjdk.java.net/jdk/pull/2949
Re: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
On Sat, 20 Mar 2021 17:41:45 GMT, SalusaSecondus
wrote:
>> I think that this code will work, but since there already is
>> [P11RSAPrivateKey and
>> P11RSAPrivateNonCRTKey](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406)
>> (both of which implement the standard `RSAPrivateKey` and
>> `RSAPrivateCrtKey` interfaces respectively), can we just depend on and
>> simplify our code? (My concern is that there is some unknown reason for
>> calling `C_GetAttributeValue` directly here.)
>>
>> For example (based on the non-P11 code above)
>> } else if (key instanceof RSAPrivateKey) {
>> if (keySpec.isAssignableFrom(PKCS8_KEYSPEC_CLS)) {
>> return keySpec.cast(new
>> PKCS8EncodedKeySpec(key.getEncoded()));
>> } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
>> if (key instanceof RSAPrivateCrtKey) {
>> RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey)key;
>> return keySpec.cast(new RSAPrivateCrtKeySpec(
>> crtKey.getModulus(),
>> crtKey.getPublicExponent(),
>> crtKey.getPrivateExponent(),
>> crtKey.getPrimeP(),
>> crtKey.getPrimeQ(),
>> crtKey.getPrimeExponentP(),
>> crtKey.getPrimeExponentQ(),
>> crtKey.getCrtCoefficient(),
>> crtKey.getParams()
>> ));
>> } else if (key instanceof RSAPrivateKey) {
>> if (!keySpec.isAssignableFrom(RSA_PRIV_KEYSPEC_CLS)) {
>> throw new InvalidKeySpecException
>> ("RSAPrivateCrtKeySpec can only be used with CRT
>> keys");
>> }
>>
>> // fall through to RSAPrivateKey (non-CRT)
>> RSAPrivateKey rsaKey = (RSAPrivateKey) key;
>> return keySpec.cast(new RSAPrivateKeySpec(
>> rsaKey.getModulus(),
>> rsaKey.getPrivateExponent(),
>> rsaKey.getParams()
>> ));
>> } else { // New P11 code starts here and handles the
>> P11PrivateKey case
>> throw new InvalidKeySpecException("RSA Private key is
>> not extractable");
>> } // End new P11 code
>> } else {
>> throw new InvalidKeySpecException
>> ("KeySpec must be RSAPrivate(Crt)KeySpec or "
>> + "PKCS8EncodedKeySpec for RSA private keys");
>> }
>
> I've used your code for both because it looks like a good solution.
>
> One thing which puzzles me is that the following implementation for the P11
> code passes all tests and avoids any interaction with P11 library at all. I
> didn't want to use it because I'm concerned that there is an untested
> edge-case we'd bump into.
>
> T implGetPrivateKeySpec(P11Key key, Class keySpec,
> Session[] session) throws PKCS11Exception,
> InvalidKeySpecException {
> if (key instanceof RSAPrivateKey) {
> try {
> return implGetSoftwareFactory().getKeySpec(key, keySpec);
> } catch (final InvalidKeySpecException e) {
> throw e;
> } catch (final GeneralSecurityException e) {
> throw new InvalidKeySpecException("Could not generate
> KeySpec", e);
> }
> } else {
> throw new InvalidKeySpecException("Key is not extractable");
> }
> }
Well, when the key object has all the attribute values available, things will
often work regardless which path you took.
-
PR: https://git.openjdk.java.net/jdk/pull/2949
Re: RFR: 8248268: Support KWP in addition to KW [v3]
> 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: Changed AlgorithmParameters impls to register under AES/KW/NoPadding and AES/KWP/NoPadding - Changes: - all: https://git.openjdk.java.net/jdk/pull/2404/files - new: https://git.openjdk.java.net/jdk/pull/2404/files/bc912f63..c90fdb1e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=01-02 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 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
Re: RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed [v2]
On Mon, 22 Mar 2021 18:40:37 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo > > src/java.base/share/classes/java/security/SecureRandom.java line 739: > >> 737: * to actually do any seeding. We either keep the object >> unseeded >> 738: * (in `new SecureRandom()`) or we seed the object explicitly >> 739: * (in `new SecureRandom(byte[])`). > > Maybe clearer to make it shorter? I removed the "It's critical..." sentence > as it seems redundant. > /* > * Ignore call from super constructor as well as any other calls > * unfortunate enough to be passing 0. All SecureRandom > * constructors call `super(0)` which leads to `setSeed(0)`. > * We either keep the object unseeded (in `new SecureRandom()`) > * or we seed the object explicitly (in `new SecureRandom(byte[])`). > */ Sure I can do that. - PR: https://git.openjdk.java.net/jdk/pull/3124
Re: RFR: 8248268: Support KWP in addition to KW
On Thu, 4 Feb 2021 10:51:12 GMT, Valerie Peng wrote: > 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 Ping, anyone has time to review this? - PR: https://git.openjdk.java.net/jdk/pull/2404
Re: RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed [v2]
On Mon, 22 Mar 2021 18:06:56 GMT, Weijun Wang wrote: >> We don't use `digest` anymore but still need to ignore the 0 argument. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > typo src/java.base/share/classes/java/security/SecureRandom.java line 739: > 737: * to actually do any seeding. We either keep the object unseeded > 738: * (in `new SecureRandom()`) or we seed the object explicitly > 739: * (in `new SecureRandom(byte[])`). Maybe clearer to make it shorter? I removed the "It's critical..." sentence as it seems redundant. /* * Ignore call from super constructor as well as any other calls * unfortunate enough to be passing 0. All SecureRandom * constructors call `super(0)` which leads to `setSeed(0)`. * We either keep the object unseeded (in `new SecureRandom()`) * or we seed the object explicitly (in `new SecureRandom(byte[])`). */ - PR: https://git.openjdk.java.net/jdk/pull/3124
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v34]
> 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: - RandomGeneratorFactory::all(Class category) @implNote was out of date - Clarify all() - Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/5e98d915..4562dd13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=33 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=32-33 Stats: 16 lines in 2 files changed: 3 ins; 0 del; 13 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
Re: RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed [v2]
> We don't use `digest` anymore but still need to ignore the 0 argument. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: typo - Changes: - all: https://git.openjdk.java.net/jdk/pull/3124/files - new: https://git.openjdk.java.net/jdk/pull/3124/files/dd61f386..6bd8b100 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3124&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3124&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3124/head:pull/3124 PR: https://git.openjdk.java.net/jdk/pull/3124
Re: RFR: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out
On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo wrote: > The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds > set on sslServerSocket. This time interval could be inadequate when the > machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So > the statement has been removed. Marked as reviewed by hchao (Committer). - PR: https://git.openjdk.java.net/jdk/pull/3116
Re: RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo wrote: > The Test is updated to use positive integer as seed for SecureRandom. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3114
Re: RFR: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out
On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo wrote: > The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds > set on sslServerSocket. This time interval could be inadequate when the > machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So > the statement has been removed. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3116
Re: RFR: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out
On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo wrote: > The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds > set on sslServerSocket. This time interval could be inadequate when the > machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So > the statement has been removed. Marked as reviewed by xuelei (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3116
RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed
We don't use `digest` anymore but still need to ignore the 0 argument. - Commit messages: - 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed Changes: https://git.openjdk.java.net/jdk/pull/3124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263978 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3124/head:pull/3124 PR: https://git.openjdk.java.net/jdk/pull/3124
Re: RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo wrote: > The Test is updated to use positive integer as seed for SecureRandom. Marked as reviewed by weijun (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3114
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32]
On Thu, 18 Mar 2021 21:43:16 GMT, Joe Darcy wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 67 commits:
>>
>> - Merge branch 'master' into 8248862
>> - Review revisions
>> - Missing @since
>> - Review revisions
>> - Review requested changes
>> - Merge branch 'master' into 8248862
>> - Remove conflicts
>> - Use isAnnotationPresent
>> - Introduce isDeprecated
>> - Update javadoc
>> - ... and 57 more:
>> https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1290:
>
>> 1288: * @return a new object that is a copy of this generator
>> 1289: */
>> 1290: LeapableGenerator copy();
>
> Suggest adding an Override annotation here and possibly to inheritDoc the
> text from Jumpable.copy.
Fails due to result variance.
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1455:
>
>> 1453: * period of this generator
>> 1454: */
>> 1455: void jump(double distance);
>
> Suggest Override and inheritDoc combo.
jump(double distance) does not occur in superinterface. The ability to jump
arbitrarily is specific to ArbitrarilyJumpableGenerator.
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1465:
>
>> 1463: * @implSpec The default implementation invokes
>> jump(jumpDistance()).
>> 1464: */
>> 1465: default void jump() { jump(jumpDistance()); }
>
> Should be able to avoid defining the jump method in this subinterface.
jump(double distance) does not occur in superinterface. The ability to jump
arbitrarily is specific to ArbitrarilyJumpableGenerator.
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1486:
>
>> 1484: * ({@link Long#MAX_VALUE Long.MAX_VALUE}).
>> 1485: */
>> 1486: default Stream jumps(double
>> distance) {
>
> Suggest adding an Override annotation.
jump(double distance) does not occur in superinterface. The ability to jump
arbitrarily is specific to ArbitrarilyJumpableGenerator.
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1521:
>
>> 1519: * {@link ArbitrarilyJumpableGenerator#leapDistance()
>> leapDistance}().
>> 1520: */
>> 1521: default void leap() { jump(leapDistance()); }
>
> Should need to define this method in the subinterface of Leapable.
jump(double distance) does not occur in superinterface. The ability to jump
arbitrarily is specific to ArbitrarilyJumpableGenerator.
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1538:
>
>> 1536: * returns the copy.
>> 1537: */
>> 1538: default ArbitrarilyJumpableGenerator copyAndJump(double
>> distance) {
>
> Suggest Override and inheritDoc.
jump(double distance) does not occur in superinterface. The ability to jump
arbitrarily is specific to ArbitrarilyJumpableGenerator.
-
PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v33]
> 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: Cleaned up ints(), longs(), doubles() - Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/63094f9d..5e98d915 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=32 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=31-32 Stats: 782 lines in 4 files changed: 310 ins; 416 del; 56 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
Integrated: 8263855: Use the blessed modifier order in java.management/naming
On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt wrote: > As with #2993 changing the order of `final static` to `static final` for the > `java.management`, `java.management.rmi` and `java.naming` modules. This pull request has now been integrated. Changeset: 5262d95b Author:Alex Blewitt Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/5262d95b Stats: 261 lines in 69 files changed: 0 ins; 0 del; 261 mod 8263855: Use the blessed modifier order in java.management/naming Reviewed-by: redestad, aefimov, dfuchs - PR: https://git.openjdk.java.net/jdk/pull/3078
Re: RFR: 8263855: Use the blessed modifier order in java.management/naming [v2]
On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt wrote: >> As with #2993 changing the order of `final static` to `static final` for the >> `java.management`, `java.management.rmi` and `java.naming` modules. > > Alex Blewitt has updated the pull request incrementally with one additional > commit since the last revision: > > Added more replacements of 'final public' with 'public final' Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3078
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
> 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 115 commits: - Merge branch 'master' into jdk-macos - JDK-8262491: bsd_aarch64 part - JDK-8263002: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Wider #ifdef block - Fix most of issues in java/foreign/ tests Failures related to va_args are tracked in JDK-8263512. - Add Azul copyright - Update Oracle copyright years - Use Thread::current_or_null_safe in SafeFetch - 8262903: [macos_aarch64] Thread::current() called on detached thread - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=28 Stats: 2947 lines in 75 files changed: 2838 ins; 27 del; 82 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
Re: RFR: 8263855: Use the blessed modifier order in java.management/naming [v2]
On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt wrote: >> As with #2993 changing the order of `final static` to `static final` for the >> `java.management`, `java.management.rmi` and `java.naming` modules. > > Alex Blewitt has updated the pull request incrementally with one additional > commit since the last revision: > > Added more replacements of 'final public' with 'public final' `java.naming` module changes look good to me. - Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/3078
RFR: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out
The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds set on sslServerSocket. This time interval could be inadequate when the machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So the statement has been removed. - Commit messages: - 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out Changes: https://git.openjdk.java.net/jdk/pull/3116/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3116&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225438 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3116.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3116/head:pull/3116 PR: https://git.openjdk.java.net/jdk/pull/3116
RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
The Test is updated to use positive integer as seed for SecureRandom. - Commit messages: - 8247895: SHA1PRNGReseed.java is calling setSeed(0) Changes: https://git.openjdk.java.net/jdk/pull/3114/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3114&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247895 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3114.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3114/head:pull/3114 PR: https://git.openjdk.java.net/jdk/pull/3114
