From filipakanation at gmail.com Fri Sep 1 08:42:07 2023 From: filipakanation at gmail.com (Filip Petr.) Date: Fri, 1 Sep 2023 10:42:07 +0200 Subject: Modification of Client hello TLS packet Message-ID: The alerts I'm getting are coming from some random web server i'm hitting and i dont know its architecture. In this error traces I'm submitting it's www.google.com but it happens for every other domain I'm trying to hit. It seems that my java app and my client side program is glitching as it's spotting some unusual extensions that I additionally added. I want it to adapt so it doesn't throw errors on them but rather just send them in client hello and act as if nothing has happened unusual. The ALPN extensions are matched according to Google Chrome's same ones that it's sending in ClientHello. The traces errors are in following link: https://pastebin.com/raw/6qmeg85H I appreciate all the help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Fri Sep 1 14:11:08 2023 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 1 Sep 2023 16:11:08 +0200 Subject: Modification of Client hello TLS packet In-Reply-To: References: Message-ID: <62E5D83F-2841-C745-8DFA-EA2B492B6653@hxcore.ol> An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Fri Sep 1 14:16:55 2023 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 1 Sep 2023 16:16:55 +0200 Subject: Modification of Client hello TLS packet In-Reply-To: <62E5D83F-2841-C745-8DFA-EA2B492B6653@hxcore.ol> References: , <62E5D83F-2841-C745-8DFA-EA2B492B6653@hxcore.ol> Message-ID: An HTML attachment was scrubbed... URL: From mbalao at openjdk.org Fri Sep 1 15:20:19 2023 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 1 Sep 2023 15:20:19 GMT Subject: RFR: 8315487: Security Providers Filter Message-ID: In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR. ## ProvidersFilter ### Filter construction (parser) The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized. The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor. While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future. ### Filter (structure and behavior) A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the service matches it. Otherwise, the filter moves to the next rule in the sequence. Rules are made of 3 regular expressions, derived from a filter pattern: provider, service type and algorithm or alias. A service matches a rule when its provider, service type and algorithm or alias matches the corresponding regular expressions in the rule. When a rule is matched by a service, it casts a decision (represented by the ProvidersFilter::FilterDecision class) that has two values: an allow or deny result and a priority that depends on how early (or left, in filter string terms) the rule is positioned in relative terms. Priorities are used for services that have aliases, as a mechanism to disambiguate contradictory decision results depending on which alias or algorithm is evaluated. When a service with aliases is passed through a filter, independent evaluations are made for the algorithm and each alias. The decision with highest priority (lowest in absolute numbers) is finally effective. ### Filter decisions cache To accomplish the goal of maximizing performance, most services are passed through the Providers filter at registration time, when added with the java.security.Provider::putService or java.security.Provider::put APIs. While uncommon, providers may override java.security.Provider::getService or java.security.Provider::getServices APIs and return services that were never registered. In these cases, the service is evaluated against the Providers filter the first time used. Once a service is evaluated against the filter, the decision is stored in the private isAllowed Provider.Service class field. When authorizing further uses of the service, the value from this cache is read, instead of performing a new filter evaluation. If the service does not experience any change, such as gaining or losing an alias (only possible with the legacy API), the cached value remains valid. Otherwise, a new filter evaluation has to take place. For example, a service could have been not allowed but a new alias matches an authorization rule in the filter that flips the previous decision. The method Provider.Service::computeIsAllowed (that internally invokes ProvidersFilter::computeIsAllowed) can be used to force the recomputation of an authorization cached decision. The method ProvidersFilter::isAllowed, when filtering capabilities are enabled, tries to get the service authorization from the Provider.Service isAllowed field, and triggers a computation if not initialized. For this mechanism to work, the Provider.Service::getIsAllowed private method is exposed through SharedSecrets and accessed from ProvidersFilter. ### Filter checking idiom At every point in the JDK where any of Provider::getService or Provider::getServices APIs are invoked, a Providers filter check must be applied by calling ProvidersFilter.isAllowed(serviceInstance). It's assumed that serviceInstance is not null. The returned value indicates if the serviceInstance service is allowed or not. When a service is not allowed, the caller must discard it. The reason why we need to apply this checking pattern is because Provider::getService or Provider::getServices APIs may be overwritten by a provider to return unregistered services that were not evaluated against the filter before. If these APIs were not overwritten, the implementation will only return allowed services. ### Debugging the filter There are 3 mechanisms to debug a filter: 1 - Set the "java.security.debug" System property to "jca" and find filter-related messages prefixed by "ProvidersFilter". This debug output includes information about the filter construction (parsing) as well as evaluations of services against the filter. Note: the application has to trigger the ProvidersFilter class static initialization for this output to be generated, for example by invoking java.security.Security::getProviders. Example: java -Djava.security.debug=jca -Djdk.security.providers.filter="SunJCE.Cipher.AES" Main Filter construction messages: ProvidersFilter: Parsing: SunJCE.Cipher.AES ProvidersFilter: -------------------- ProvidersFilter: Rule parsed: SunJCE.Cipher.AES ProvidersFilter: * Provider: SunJCE (regexp: \QSunJCE\E) ProvidersFilter: * Service type: Cipher (regexp: \QCipher\E) ProvidersFilter: * Algorithm: AES (regexp: \QAES\E) ProvidersFilter: * Decision: ALLOW - priority: 0 ProvidersFilter: Filter: SunJCE.Cipher.AES; !* (DEFAULT) ProvidersFilter: -------------------- Filter evaluation messages: ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: AES) ProvidersFilter: * Decision: ALLOW - priority: 0 ProvidersFilter: * Made by: SunJCE.Cipher.AES ProvidersFilter: -------------------- ProvidersFilter: The queried service has aliases. Checking them for a final decision... ProvidersFilter: -------------------- ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: OID.2.16.840.1.101.3.4.1) ProvidersFilter: * Decision: DENY - priority: 1 ProvidersFilter: * Made by: !* (DEFAULT) ProvidersFilter: -------------------- ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: 2.16.840.1.101.3.4.1) ProvidersFilter: * Decision: DENY - priority: 1 ProvidersFilter: * Made by: !* (DEFAULT) ProvidersFilter: -------------------- ProvidersFilter: Final decision based on AES algorithm: ALLOW - priority: 0 2 - Pass the -XshowSettings:security:providers JVM argument and check, for each statically installed security provider, which services are allowed and not allowed by the filter. Example: java -XshowSettings:security:providers -Djdk.security.providers.filter="SunJCE.Cipher.AES" -version Security provider static configuration: (in order of preference) ... ---------------------------------------- Provider name: SunJCE ... Provider services allowed: (type : algorithm) Cipher.AES aliases: [2.16.840.1.101.3.4.1, OID.2.16.840.1.101.3.4.1] Provider services NOT allowed: (type : algorithm) AlgorithmParameterGenerator.DiffieHellman aliases: [1.2.840.113549.1.3.1, DH, OID.1.2.840.113549.1.3.1] ... ---------------------------------------- ... 3 - When a filter cannot be constructed, the ProvidersFilter.ParserException exception includes the state of the filter at the time when the error occurred, and indicates which pattern could not be parsed. Example: java -XshowSettings:security:providers -Djdk.security.providers.filter="SunJCE.Cipher.AES; My Provider" Caused by: sun.security.jca.ProvidersFilter$Filter$ParserException: Only whitespace characters are valid after a pattern. Whitespaces that are part of a provider name, service type or algorithm must be escaped. * State: POST_PATTERN * Filter string: SunJCE.Cipher.AES; My Provider ---^--- ## ServicesMap Existing Provider::getService and Provider.getServices APIs were changed to return services that are allowed by the Providers filter only. In addition, a new Provider::getServicesNotAllowed method (exposed through the SharedSecrets mechanism) was introduced to obtain services that are not allowed by the Providers filter, for informational purposes only (see -XshowSettings:security:providers). These changes motivated an analysis of how services are stored internally in a Provider instance, and lead to the refactoring that will be explained in this section. ### Existing bugs and inconsistencies While analyzing the existing services map implementation, we categorized bugs found in 3 sets: 1) Concurrency bugs, 2) Serialization consistency bugs, and 3) Other bugs. While many of these bugs are related to corner cases that are unlikely to be triggered in real providers, others can potentially happen in highly concurrent scenarios and would be difficult to reproduce. #### 1 - Concurrency bugs 1.1 - A concurrent Provider::getServices call may remove services that are temporarily considered invalid because they are in the midst of an update. I.e. a provider added an alias but not the class name still, and a reader removes the service in between: Thread-1 (writer): Provider::put("Alg.Alias.MessageDigest.alias1", "alg1") ---> An invalid service is implicitly created Thread-2 (reader): Provider::getServices() ---> The invalid service is removed Thread-1 (writer): Provider::put("MessageDigest.alg1", "class1") ---> While the service is added again (valid, now), it won't have alias1. While the situation sounds unlikely for a regular service registration, it is possible when deserializing Providers as the order in which Property map entries are visited is not guaranteed. This scenario was not possible before JDK-8276660 because readers only removed invalid entries from legacyMap, but not from legacyStrings. As a result, invalid services could land in legacyMap without losing data after they become valid. See a reference to the JDK-8276660 removal here [1]. We have developed the ServicesConsistency::testInvalidGetServicesRemoval test to reflect this case. Notice that the fact that legacyMap is a ConcurrentHashMap instance does not prevent this bug from happening, as the problem is between non-atomic and non-synchronized writes. 1.2 - This bug is similar to 1.1 but occurs in Provider::getService [2], and is reflected in the test ServicesConsistency::testInvalidGetServiceRemoval. 1.3 - When signaling legacyChanged = false after recomputing the services set here [3], a concurrent legacyMap update that right before set legacyChanged = true [4] [5] would be missed. This was introduced by JDK-8276660 because, previously, legacyChanged = false was done in ensureLegacyParsed and this method was called in a synchronized getService block. Notice here that making legacyChanged volatile did not prevent this issue, as the problem is that publishing the new computed set and resetting the legacyChanged variable is not an atomic operation and a new update could have happened in between. We think that this type of problem can be solved in a lock-free way with a pattern such as the one proposed in ServicesMap::getServicesSet, that includes a double compare and exchange with a placeholder while computing the set. 1.4 - In operations such as Provider::implReplaceAll, there is a window in which all services look gone for readers [6] and this may cause spurious NoSuchAlgorithmException exceptions. Before JDK-8276660 the operation was seen as atomic by readers. The replaceAll change in the Properties map was made on legacyStrings by writers but only visible after readers impacted changes under a synchronized block. We think that replaceAll and putAll should be atomic for readers. In particular, putAll would be the legacy API mechanism to ensure that readers see services only when they have all their attributes added, and there is no risk of obtaining a service with half of them. See a test that checks an atomic replaceAll behavior in ServicesConsistency::testReplaceAllIsAtomic and a test that checks a putAll atomic behavior in ServicesConsistency::testPutAllIsAtomic. 1.5 - When a reader obtains a service from the legacyMap, Service::newInstance or Service::supportsParameter may be invoked and cached values such as classCache, constructorCache, hasKeyAttributes, supportedFormats and supportedClasses set. If there are further changes to the service (i.e.: new attributes added), cached values are never invalidated and there is a single service instance. As a result, the service information becomes inconsistent and the new attributes are missed, even for new readers. This did not happen before JDK-8276660 because ensureLegacyParsed started with a clear legacyMap and new Service instances (with uninitialized cache fields) were added. This bug is reflected in ServicesConsistency::testInvalidCachedClass, ServicesConsistency::testInvalidCachedHasKeyAttributes and ServicesConsistency::testInvalidCachedSupportedKeyFormats tests. #### 2 - Serialization consistency bugs This type of bugs make a deserialized Provider to have different services (class names, aliases and attributes) than the original instance. What they have in common is one or more of the following traits: 1) lack of synchronization between the Properties map and the actual inner services map, 2) an incorrect assumption that the Properties map is visited, while deserializing, in the same order in which entries were originally added, or 3) an inconsistent collision behavior between the Provider::put and Provider::putService APIs. We will show some examples that, while unrealistic, serve for the purpose of illustrating the aforementioned inconsistencies: 2.1 - Case-sensitive entries Ordered list of actions: put("MessageDigest.alg", "class1") put("MessageDigest.ALG", "class2") The previous list of actions creates a single Service instance that has "class2" as its class name. In the Properties map, however, both entries are present. List of actions in the order that they are executed while deserializing the provider: put("MessageDigest.ALG", "class2") put("MessageDigest.alg", "class1") The created Service instance, after deserialization, has "class1" as its class name. This case is reflected in the ServicesConsistency::testSerializationClassnameConsistency test. 2.2 - Entries by alias Ordered list of actions: put("MessageDigest.alg", "class1") put("Alg.Alias.MessageDigest.alias", "alg") put("Alg.Alias.MessageDigest.alias2", "alias") The previous list of actions creates a single Service instance that has "alg" as its algorithm, and "alias" and "alias2" as its aliases. List of actions in the order that they are executed while deserializing the provider: put("Alg.Alias.MessageDigest.alias2", "alias") put("Alg.Alias.MessageDigest.alias", "alg") put("MessageDigest.alg", "class1") After deserialization there will be two Service instances: one has "alias" as its algorithm and "alias2" as its alias, and the other has "alg" as its algorithm and "alias" as its alias. The former instance is invalid and reachable by "alias2" only, and the latter is valid and reachable by "alg" or "alias". 2.3 - Algorithm case-insensitive collision between Provider::putService and Provider::put Ordered list of actions: put("MessageDigest.ALG", "class1") putService(new Service(provider, "MessageDigest", "alg", "class2", null, null)) The previous list of actions creates two Service instances, from which the one using "class2" as its class name is visible. However, the Properties map has entries for both services. List of actions in the order that they are executed while deserializing the provider: put("MessageDigest.alg", "class2") put("MessageDigest.ALG", "class1") After deserialization, only the Service instance that has "class1" as its class name is available. This case is related to the ServicesConsistency::testCurrentAPIServicesOverride test. 2.4 - Alias collision between Provider::putService and Provider::put putService(new Service(provider, "MessageDigest", "alg1", "class1", List.of("alias"), null)) put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alias", "alg2") The previous list of actions creates two service instances, from which the one using "class1" as its class name is visible by "alias". However, the Properties map has the entry "Alg.Alias.MessageDigest.alias" associated with the service instance using "class2" as its class name. List of actions executed while deserializing the provider (in any order): put("MessageDigest.alg1", "class1") put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alias", "alg2") After deserialization, the Service instance using "class2" as its class name is the one identified by the alias "alias". This same inconsistency may occur with the algorithm instead of the alias. This case is related to the ServicesConsistency::legacyAPIServicesOverride test. 2.5 - Overwrites of algorithms with aliases Ordered list of actions: put("MessageDigest.alg1", "class1") put("Alg.Alias.MessageDigest.alias1", "alg1") put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alg1", "alg2") The previous list of actions creates two service instances, one that has "alg1" as its algorithm, "class1" as its class name and "alias1" as its alias, and the other that has "alg2" as its algorithm, "class2" as its class name and "alg1" as its alias. List of actions in the order that they are executed while deserializing the provider: put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alg1", "alg2") put("MessageDigest.alg1", "class1") put("Alg.Alias.MessageDigest.alias1", "alg1") After deserialization, a single Service instance is created. This instance has "alg2" as its algorithm, "class1" as its class name, and "alg1" and "alias1" as its aliases. This case is related to the ServicesConsistency::testLegacyAPIAliasCannotBeAlgorithm test. #### 3 - Other bugs 3.1 - Invalid services (without a class name) can be returned in Provider::getService, even when they are removed from the legacyMap [7]. This case is reflected in the ServicesConsistency::testInvalidServiceNotReturned test. 3.2 - Methods Provider::implMerge and Provider::implCompute pass a "null" value as the 2nd parameter to Provider::parseLegacy and a remove action [8]. In the case of an alias, Provider::parseLegacy will throw a NullPointerException here [9]. This issue has been introduced by JDK-8276660, and is reflected in the tests ServicesConsistency::testComputeDoesNotThrowNPE and ServicesConsistency::testMergeDoesNotThrowNPE. Note: we might be overlooking more bugs, as we decided to go with a new implementation at this point. ### Proposal We replaced the mechanism through which Service instances are organized inside a Provider, while maintaining the existing APIs to store and fetch services. These APIs are internally called Legacy and Current. The solution was designed to follow the principles of avoiding bottlenecks for service map readers (lock-free, thread-safe), ensuring consistency after Providers deserialization, ensuring consistency between the Provider's properties map and the actual services, enforcing consistency between the Legacy and Current APIs, and maintaining previous behavior to the maximum extent possible. What follows is a description of the most relevant design choices: 1 - Properties map synchronization: what you see on the Properties map is what you get from the internal services map Adding, modifying or removing a service has a direct or indirect impact on the Properties map to enforce consistency. For example, adding an uppercase entry may overwrite a previous lowercase one. While this behavior is different from a regular Properties structure, having both entries would break synchronization with the internal services map (which is case insensitive) and is problematic for serialization. Other cases, such as adding entries by aliases, are also handled and canonicalized. 2 - The Current API (Provider::putService) has preference over the Legacy API (Provider::put). We kept the preference of Provider::getService and Provider::getServices methods for Current API services over Legacy API counterparts. However, the internal map is now unified and Legacy services may be overwritten ?notice that the opposite is not possible?. This was redesigned considering that there is a single Properties map, and we aim to keep it aligned to the internal services map. For expected behavior between the Legacy and Current APIs, we suggest looking at the ServicesConsistency::testLegacyAPIServicesOverride and ServicesConsistency::testCurrentAPIServicesOverride tests. 3 - Copy-on-write strategy for Legacy API service changes We implemented a copy-on-write strategy that reminds of the one before JDK-8276660 but has a key difference: the new implementation is lock-free and faster from a service readers point of view. This strategy makes it possible to have service consistency in multi-threaded scenarios, and fix many of the concurrency bugs previously described. In terms of time consistency, we do not enforce that constraint between different services obtained from Provider::getServices. In other words, the Set returned may have an old version of service A and a new version of service B, even when the change to service A was applied first. We consider that it is not worth paying a synchronization cost for this type of consistency. Notice that Current API services do not require this approach because they are immutable: once added, they cannot be changed. 4 - Lock-free Provider::getServices The Provider::getServices method is optimized for service readers with a cached set and a lock-free implementation. ## SunNativeProvider Changes were introduced to make the SunNativeProvider security provider use the Provider::putService API to register services, instead of the legacy Provider::putAll. This was the only security provider in OpenJDK using a non-Provider::putService API. While this change does not have any observable implications, it is in the interest of a better code ?and sets a better example? to align it with the other OpenJDK security providers. In our assessment, these are the OpenJDK providers using the Providers::putService API: SunJCE, SunPKCS11, SunRsaSign, SunEC, SUN, SunJSSE, SunMSCAPI, XMLDSigRI, JdkLDAP, JdkSASL, SunJGSS, SunPCSC, Apple and SunJarVerification. ## Testing As part of our testing, we observed no regressions in the following test categories: * jdk:tier1 * jdk/java/security * jdk/sun/security Additionally, we introduced the following new regression tests: * jdk/sun/security/provider/ProvidersFilterTest.java * jdk/java/security/Provider/ServicesConsistency.java Finally, we extended the following tests: * jdk/tools/launcher/Settings.java This contribution is co-authored by Francisco Ferrari and Martin Balao. -- [1] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1332 [2] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1289 [3] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1340 [4] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1145 [5] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1181 [6] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L976 [7] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1285-L1301 [8] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L999-L1016 [9] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1146 ------------- Commit messages: - 8315487: Security Providers Filter Changes: https://git.openjdk.org/jdk/pull/15539/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315487 Stats: 4600 lines in 24 files changed: 4029 ins; 323 del; 248 mod Patch: https://git.openjdk.org/jdk/pull/15539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539 PR: https://git.openjdk.org/jdk/pull/15539 From filipakanation at gmail.com Fri Sep 1 16:02:27 2023 From: filipakanation at gmail.com (Filip Petr.) Date: Fri, 1 Sep 2023 18:02:27 +0200 Subject: Modification of Client hello TLS packet Message-ID: This extension is my custom. It's the same extension that Google chrome added (https://datatracker.ietf.org/doc/html/rfc8701). You can check this extension on your Chrome browser using this following URL https://tls.peet.ws/api/tls I don't understand why this is an issue for my Java program? I checked in Wireshark and the hex values in this extension are exactly the same that my browser sends out. For example, the browser sends it out like this aa aa 00 01 00 and i send it out like this 0a 0a 00 01 00. The only difference is the first 2 bytes that are kind of random as per convention. I don't understand why my Java doesn't like this? Only thing I did is added the tls grase .java file inside /security/ssl called (TLSGreaseExtension.java) with following content ( https://pastebin.com/CepmN9YD) and added it inside SSLExtension.java ( https://pastebin.com/6vXh7CKL). I don't see why it would throw an exception? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Fri Sep 1 16:30:04 2023 From: mbalao at redhat.com (Martin Balao) Date: Fri, 1 Sep 2023 12:30:04 -0400 Subject: RFD: Services lockdown for security providers In-Reply-To: <85e89abd-eac3-87df-9e4b-1fa2c36a6286@oracle.com> References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com> <4b159d35-ee2e-952d-8e22-c035e5ed17ea@oracle.com> <1a0ad927-2da8-c881-a80f-b4928341375f@redhat.com> <7c07a7b1-6c68-9534-59e1-1813439d7f47@redhat.com> <85e89abd-eac3-87df-9e4b-1fa2c36a6286@oracle.com> Message-ID: Hi Sean, Thanks for clarifying your idea. I understand your motivation and share your concerns. I can think of how this application-specific knowledge can turn into a library-specific one in real scenarios, which may open the door for undesired dependencies. I also agree with being wary about doing stack walks in a Security Manager style at time of use. We have to give it some thought. Just in case, we reserved the characters ":" and "," in our proposal for the Security Providers Filter [1] [2]. Extending the filter syntax in the future (in a backward compatible way) should not be a problem. Martin.- -- [1] - https://bugs.openjdk.org/browse/JDK-8315487 [2] - https://github.com/openjdk/jdk/pull/15539 On Thu, Jul 13, 2023 at 1:01?PM Sean Mullan wrote: > > > On 7/13/23 12:27 PM, Martin Balao wrote: > > On 7/13/23 12:06, Sean Mullan wrote: > >> One other comment that I thought of - is that from a practical > >> standpoint, I think it will be hard to unilaterally disable an algorithm > >> at the JCE layer unless it is so broken that almost no code ever uses > >> it, say MD2 or RC2. There may be cases where a weak algorithm is > >> acceptable, for example using MD5 for a checksum. (For a real example, > >> UUID.nameUUIDFromBytes uses MD5 to generate a UUID). > >> > >> If you have a single case in your application where a weak algorithm is > >> ok to use, you won't be able to disable it across the board. > > > > Yes, I agree with this observation. In fact, our original motivation was > > not to disable an algorithm across the board but a specific > > implementation of it ?i.e. blocking the implementation from provider X, > > because we want the one from provider Y or prefer the algorithm not to > > be available. What we also have in mind is using this enhancement in > > combination with security profiles that can enforce policies of allowed > > algorithms, at the risk of requiring changes in an application to be > > compliant. > > > >> > >> At the risk of complicating your syntax and implementation, it may be > >> worth exploring adding the name of a class to the syntax for cases like > >> this. But my comment is more about thinking about this a bit more first. > >> > >> Or perhaps adding some extensibility into the format would be a good > >> idea in case we want to add something like this down the line. > >> > > > > I have a couple of questions regarding this idea: > > > > 1) Isn't the class name an implementation detail? My concern is not much > > on how to extend the syntax but on binding the filter value to internal > > names. > > It is an application-specific detail. I would expect this to be applied > by applications that are most familiar with their usage, and not as part > of a global configuration. > > > 2) Why wouldn't a combination of Security Provider + Service Type + > > Algorithm be enough to identify a specific implementation? > > Because that doesn't tell you who is calling the specific > provider/service and whether that use case is acceptable or not. Also > most code that calls JCE APIs doesn't specify a specific provider. > > Again, I think this needs more thought, and I am not suggesting this is > the best course of action, but one thought is a syntax something like this: > > > jdk.security.providers.filter=java.util.UUID.nameUUIDFromBytes:MessageDigest.MD5;!*.MessageDigest.MD5;* > > But, that would probably mean extending the implementation to do a stack > walk to check if the specified class was one of the callers, which I am > very wary about doing something like this. But the overall issue still > remains for me. Maybe we should not be providing a way to unilaterally > disable algorithms unless it can be used more effectively in practice. > Otherwise I don't like the idea of telling a user they have to re-enable > the algorithm even if they only have a single case where it is acceptable. > > --Sean > > > Thanks, > > Martin.- > > > > > >> --Sean > >> > >> > >> On 7/13/23 11:44 AM, Martin Balao wrote: > >>> Hi Sean, > >>> > >>> Thanks for your feedback. > >>> > >>> Just to give some visibility, we have implemented most of the > >>> functionality and are now working on final adjustments, more tests > >>> coverage, documentation and internal reviews. The implementation is > >>> pretty much aligned to what we previously discussed, with the exception > >>> of algorithm's alias that turned up to have more complexity than > >>> anticipated ?particularly in the legacy mode of registering Services?. > >>> > >>> We will send a PR for public discussion in the coming weeks. > >>> > >>> Martin.- > >>> > >>> > >>> On 6/14/23 12:40, Sean Mullan wrote: > >>>> This proposal looks pretty good, although I think I would like to see > >>>> more examples and a prototype if you have it. > >>>> > >>>> I think this would work well in conjunction with Sean Coffey's > >>>> enhancement to add a security category to the java -XshowSettings > option > >>>> [1]. This would help debug issues with the syntax. The provider > >>>> suboption could be enhanced (perhaps by default, perhaps with an > >>>> additional suboption) to show the services that are disabled, ex, with > >>>> the property set to > >>>> > >>>> jdk.security.providers.filter=!*.MessageDigest.MD5; > >>>> !*.MessageDigest.MD2; *: > >>>> > >>>> it would show something like: > >>>> > >>>> Provider name: SUN > >>>> Provider information: ... > >>>> Provider services: (type : algorithm) > >>>> ... > >>>> MessageDigest : MD2 (disabled) > >>>> MessageDigest : MD5 (disabled) > >>>> ... > >>>> > >>>> I would even add that as a debugging tip in the documenting of the > >>>> syntax. > >>>> > >>>> --Sean > >>>> > >>>> [1] https://github.com/openjdk/jdk/pull/14394 > >>>> > >>>> On 5/24/23 5:03 PM, Martin Balao wrote: > >>>>> Hi, > >>>>> > >>>>> Thanks Anthony for your feedback. > >>>>> > >>>>> We've been exploring the syntax and semantics for this new property > >>>>> further, with the goal of making it more consistent and simple while > >>>>> retaining expressiveness power. We understand the importance of > clarity > >>>>> to minimize the risk of security providers, service types or > algorithms > >>>>> being unexpectedly enabled. > >>>>> > >>>>> In this new iteration of the proposal, we explore a filter that has > >>>>> similarities to the serialization filter (jdk.serialFilter). We think > >>>>> that it could be beneficial to leverage on a specification to which > the > >>>>> user is familiar already. > >>>>> > >>>>> > >>>>> General structure > >>>>> ==================== > >>>>> > >>>>> jdk.security.providers.filter=pattern-1; pattern-2; ...; pattern-n > >>>>> > >>>>> The property jdk.security.providers.filter is an overrideable > Security > >>>>> property. Thus, a System property with the same name exists and, when > >>>>> specified, overrides any value in its Security counterpart. When not > >>>>> specified (value is null), filtering capabilities are completely > >>>>> disabled: all installed security providers, service types and > >>>>> algorithms > >>>>> are allowed. If any of these properties are set during run time, the > >>>>> filter could be initialized already and the new value may not take > >>>>> effect. > >>>>> > >>>>> When filtering capabilities are enabled, each service is checked > >>>>> against > >>>>> the filter before registration. Notice that this affects both the > >>>>> initial list of security providers as well as those dynamically > >>>>> installed during run time. Once a service is registered, instances > >>>>> of it > >>>>> can be obtained and used without any other checks that could affect > >>>>> performance. > >>>>> > >>>>> The registration of a service involves a combination of a security > >>>>> provider, service type and algorithm. Each combination is evaluated > >>>>> against the filter patterns, from left to right. When a pattern > matches > >>>>> ?or, in other words, the rule concerns the service to be > registered?, a > >>>>> decision is made: the service will be allowed or denied. When a > >>>>> decision > >>>>> is made, remaining patterns are not checked for the service under > >>>>> consideration. When all patterns are checked and a decision is not > >>>>> made, > >>>>> the default behavior is to deny the service registration. > >>>>> > >>>>> Contrary to the serialization filter, white spaces between patterns > do > >>>>> not have any significance. > >>>>> > >>>>> > >>>>> Pattern matching > >>>>> ===================================================== > >>>>> > >>>>> pattern := ! security-provider.service-type.algorithm > >>>>> > >>>>> pattern := security-provider.service-type.algorithm > >>>>> > >>>>> A canonical pattern consists of 3 hierarchical levels separated by > ".". > >>>>> From left to right in lexicographic order, these levels denote a > >>>>> security provider, a service type and an algorithm. If a pattern > starts > >>>>> with "!", the decision made upon matching is to deny the service > >>>>> registration. Otherwise, the service registration is allowed. White > >>>>> spaces between "!" and the rest of the pattern do not have any > >>>>> significance. > >>>>> > >>>>> For a match to be successful, the security provider name, the service > >>>>> type and the algorithm have to match the pattern exactly (case > >>>>> insensitive). If the service type of a security provider interprets > the > >>>>> algorithm as a transformation composed of different parts, the full > >>>>> transformation has to be specified in the pattern: the filter takes a > >>>>> conservative approach and does not make any assumptions of what an > >>>>> algorithm name means. For example, "AES" as the algorithm of a > >>>>> canonical > >>>>> filter pattern will not match an "AES/ECB/PKCS5Padding" > transformation. > >>>>> > >>>>> If an algorithm alias is specified in the filter pattern, a service > >>>>> registering the alias will be matched. > >>>>> > >>>>> For convenience, it's possible to specify patterns in non-canonical > >>>>> forms: > >>>>> > >>>>> 1) At any level, the security provider, the service type or the > >>>>> algorithm name can contain wildcards ("*") to represent zero or more > >>>>> repetitions of any character; > >>>>> > >>>>> 2) The .algorithm part can be omitted to imply all algorithms under > the > >>>>> security provider and service type; > >>>>> > >>>>> 3) The .service-type.algorithm part can be omitted to imply all > service > >>>>> types and algorithms under the security provider; and, > >>>>> > >>>>> 4) The non-canonical form #1 can be combined with either #2 or #3. > >>>>> > >>>>> > >>>>> Security provider, service type and algorithm names escaping > >>>>> ================================================================= > >>>>> > >>>>> If the security provider, service type or algorithm name contains > >>>>> any of > >>>>> the characters "\", ".", ";" or "*", they have to be escaped by > >>>>> prepending the character "\". If the character "\" is found not > >>>>> escaping > >>>>> a character, it's silently discarded. > >>>>> > >>>>> White spaces are discarded at the beginning and end of names. > >>>>> > >>>>> It's worth mentioning that the described escaping rules apply to the > >>>>> jdk.security.providers.filter property value as read in > >>>>> java.lang.System::getProperty or java.security.Security::getProperty. > >>>>> Additional escaping might be needed depending on how the property is > >>>>> passed. For example, Security properties require "\" characters to be > >>>>> escaped. Thus, to match a provider name whose name is "\.", a filter > >>>>> would require the "jdk.security.providers.filter=\\\\\\." entry in > the > >>>>> java.security file. See more about this in java.util.Properties::load > >>>>> [1]. > >>>>> > >>>>> > >>>>> Examples (correct) > >>>>> ==================== > >>>>> > >>>>> -- > >>>>> > >>>>> Enable all security providers, service types and algorithms: > >>>>> > >>>>> jdk.security.providers.filter= > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=* > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=*.* > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=*.*.* > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the MD5 algorithm in MessageDigest > >>>>> services > >>>>> when implemented by the SUN security provider: > >>>>> > >>>>> jdk.security.providers.filter=!SUN.MessageDigest.MD5; * > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the MD5 algorithm in MessageDigest > >>>>> services, irrespective of the security provider: > >>>>> > >>>>> jdk.security.providers.filter=!*.MessageDigest.MD5; * > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for algorithms using MD5, irrespective of > the > >>>>> security provider and the service type: > >>>>> > >>>>> jdk.security.providers.filter=!*.*.*MD5*; * > >>>>> > >>>>> Notice that in this case there are wildcards at the beginning and > >>>>> end of > >>>>> the algorithm name. The reason is to match MD5 uses in algorithms > such > >>>>> as HmacMD5, MD5withRSA, PBEWithMD5AndDES, etc. > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the RC4 algorithm in Cipher services > when > >>>>> implemented by the SunJCE security provider: > >>>>> > >>>>> jdk.security.providers.filter=!SunJCE.Cipher.ARCFOUR; * > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=!SunJCE.Cipher.RC4; * > >>>>> > >>>>> or > >>>>> > >>>>> > jdk.security.providers.filter=!SunJCE.Cipher.1\.2\.840\.113549\.3\.4; * > >>>>> > >>>>> -- > >>>>> > >>>>> Enable the SUN security provider only, with all its service types and > >>>>> algorithms. Other security providers must be disabled. > >>>>> > >>>>> jdk.security.providers.filter=SUN > >>>>> > >>>>> -- > >>>>> > >>>>> Enable the SUN security provider only, with all its service types and > >>>>> algorithms except for MessageDigest. Other security providers must be > >>>>> disabled. > >>>>> > >>>>> jdk.security.providers.filter=!SUN.MessageDigest; SUN > >>>>> > >>>>> -- > >>>>> > >>>>> > >>>>> Examples (mistakes) > >>>>> ==================== > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the MD5 algorithm, irrespective of the > >>>>> security provider and the service type: > >>>>> > >>>>> jdk.security.providers.filter=*; !*.*.MD5 > >>>>> > >>>>> This is wrong because the pattern "*" is matched first and a decision > >>>>> allowing MD5 will be made immediately after. The pattern "!*.*.MD5" > >>>>> will > >>>>> never be checked. > >>>>> > >>>>> -- > >>>>> > >>>>> Enable all SUN service types except for MessageDigest. Disable other > >>>>> security providers. > >>>>> > >>>>> jdk.security.providers.filter=!SUN.MessageDigest > >>>>> > >>>>> While non-SUN security providers are effectively disabled, this is > >>>>> wrong > >>>>> because SUN services other than MessageDigest will not match any > >>>>> pattern > >>>>> and, by default, the decision is to deny registration. > >>>>> > >>>>> -- > >>>>> > >>>>> Enable the SunPKCS11 security provider only. > >>>>> > >>>>> jdk.security.providers.filter=SunPKCS11 > >>>>> > >>>>> This is wrong because the SunPKCS11 provider has to be identified by > >>>>> its > >>>>> name instead of its class. A possible name would have the form of > >>>>> SunPKCS11-NAME. In a filter, this can be matched either by > >>>>> "SunPKCS11-NAME" or "SunPKCS11-*". > >>>>> > >>>>> -- > >>>>> > >>>>> > >>>>> Look forward to your thoughts. > >>>>> > >>>>> Thanks.- > >>>>> > >>>>> > >>>>> -- > >>>>> [1] - > >>>>> > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Properties.html#load%28java.io.Reader%29 > >>>>> > >>>>> (?) - Thanks to Francisco Ferrari (@fferrari) for his contributions > to > >>>>> this proposal. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 2/24/23 14:49, Anthony Scarpino wrote: > >>>>>> Hi Martin, > >>>>>> > >>>>>> Interesting proposal. I think Alternative 1 is a better direction > to > >>>>>> explore from a code structure standpoint. If I remember correctly, > >>>>>> Preferred Provider is accessed when getting a service or instance > >>>>>> of the > >>>>>> algorithm. That happens on a per-operation basis. What you > >>>>>> describe is > >>>>>> something that would reshape contents of the ProviderList where > >>>>>> algorithms or services would not be in the list at all. That is > >>>>>> were I > >>>>>> think #2 gets too complex in trying to handle both in the same > >>>>>> property. > >>>>>> #2 may end up putting all checks in a per-operation check, > >>>>>> hindering > >>>>>> performance every time as the list grows. > >>>>>> > >>>>>> I agree this is mostly used in the FIPS situation or where someone > >>>>>> wants > >>>>>> to disable an algorithm completely, say MD5. In those cases it's > best > >>>>>> to just prevent the algorithm from ever being available. > >>>>>> > >>>>>> On the smaller details side that you list. I think the name > >>>>>> ".enabled" > >>>>>> doesn't fit, particularly as the first thing in the example > >>>>>> disables all > >>>>>> Ciphers :). I don't have any suggestions at this time. > >>>>>> > >>>>>> As far as the syntax. I think it maybe a bit difficult to parse in > >>>>>> code > >>>>>> and mental to disable all Ciphers, then enable just for SunJCE and > >>>>>> SUN. > >>>>>> The SUN '*" confused me until I realized you were enabling Ciphers. > >>>>>> Seems too easy to get wrong. I know you weren't making a formal > spec, > >>>>>> but we have to start somewhere. > >>>>>> > >>>>>> thanks > >>>>>> > >>>>>> Tony > >>>>>> > >>>>>> > >>>>>> On 2/17/23 10:52 AM, Martin Balao wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> We would like to discuss a limitation in the current configuration > >>>>>>> capabilities for security providers and possible solutions that we > >>>>>>> are > >>>>>>> exploring (?). > >>>>>>> > >>>>>>> As you know, current configuration capabilities in java.security > >>>>>>> allow > >>>>>>> users to install security providers, decide their priority in a > list > >>>>>>> (security.provider. properties) and even circumvent this > priority > >>>>>>> for specific algorithms (jdk.security.provider.preferred property). > >>>>>>> However, there is no granularity in terms of what service types and > >>>>>>> algorithms are enabled once a security provider is installed: it's > an > >>>>>>> all or nothing scheme. It is worth noting that security providers > can > >>>>>>> bring with them a diverse range of service types. As an example, > the > >>>>>>> SUN security provider comes with the following service types: > >>>>>>> SecureRandom, Signature, KeyPairGenerator, > >>>>>>> AlgorithmParameterGenerator, AlgorithmParameters, KeyFactory, > >>>>>>> MessageDigest, CertificateFactory, KeyStore, CertStore, Policy, > >>>>>>> Configuration, CertPathBuilder and CertPathValidator [1]. > >>>>>>> > >>>>>>> In some cases, the user may need to enforce that all cryptographic > >>>>>>> primitives come from a specific security provider. This could > happen, > >>>>>>> for example, when operating in a FIPS-compliant environment or > under > >>>>>>> strict security policies. To better illustrate, let's say that the > >>>>>>> user requires that all cryptographic operations are performed in a > >>>>>>> Hardware Security Module (HSM). On the OpenJDK side, this means > that > >>>>>>> the implementation for Cipher, Signature, Mac and other > cryptographic > >>>>>>> services must be the one in the SunPKCS11 security provider. Let's > >>>>>>> also suppose that other non-cryptographic services such as those > for > >>>>>>> certificates validation and TLS are required, and their > >>>>>>> implementation > >>>>>>> is in the SUN and SunJSSE security providers respectively. Setting > >>>>>>> SunPKCS11 at the highest priority of the list is not a strong > >>>>>>> guarantee to ensure that all cryptographic operations come from it: > >>>>>>> it's possible that an algorithm for Signature is not implemented in > >>>>>>> SunPKCS11 or in its underlying token but in the SUN security > >>>>>>> provider. > >>>>>>> Disabling the SUN security provider wouldn't be an option in this > >>>>>>> case > >>>>>>> because we need its certificates validation service. > >>>>>>> > >>>>>>> This problem goes beyond OpenJDK default security providers. Even > if > >>>>>>> we come up with a new layout for service types, algorithms and > >>>>>>> providers ?putting backward compatibility issues aside?, there is > >>>>>>> always the possibility that a 3rd party security provider does not > >>>>>>> follow any services grouping convention. It might also be the case > >>>>>>> that we need to disable a specific algorithm only ?i.e. for > >>>>>>> cryptographic policy reasons? and TLS or JAR signing properties > fall > >>>>>>> short. > >>>>>>> > >>>>>>> In our view, it would be beneficial to add more configuration > >>>>>>> flexibility and control to the existing API in which any security > >>>>>>> provider can be plugged in, in the form of deciding which service > >>>>>>> types and algorithms are enabled for each installed provider. > >>>>>>> > >>>>>>> There are 2 alternatives that we are exploring to tackle this > >>>>>>> problem. > >>>>>>> > >>>>>>> Alternative #1 > >>>>>>> =========================== > >>>>>>> > >>>>>>> Introduce a new security property to decide which service types and > >>>>>>> algorithms are enabled for each security provider. The default > value > >>>>>>> for this property would be empty, which keeps this feature disabled > >>>>>>> and all services from installed security providers available. > >>>>>>> > >>>>>>> As for the new property's syntax and semantics, we've been > >>>>>>> considering > >>>>>>> an allow-list along the lines of: > >>>>>>> > >>>>>>> jdk.security.provider.enabled = security-provider-1 { > >>>>>>> service-type-1 : > >>>>>>> alg-1, ... ; ... } , ... > >>>>>>> > >>>>>>> Note: we need a formal syntax specification, this is for > illustration > >>>>>>> only. > >>>>>>> > >>>>>>> As part of the syntax we are considering the use of wildcards (*) > to > >>>>>>> match multiple security providers, service types and algorithms, > and > >>>>>>> minus signs (-) to remove service types. When a service type is > >>>>>>> removed, the action applies to all algorithms and any attempt to > >>>>>>> specify them explicitly would be an error. The minus sign cannot be > >>>>>>> used at the algorithm level. We are also thinking that in case of a > >>>>>>> partial or total contradiction between conditions, the right-most > >>>>>>> value applies on top of the others. If a security provider, service > >>>>>>> type or algorithm does not exist, we can simply write a debug > warning > >>>>>>> and ignore it. As for the name of the algorithms, we can also > include > >>>>>>> Ciphers transformations. > >>>>>>> > >>>>>>> Example: > >>>>>>> > >>>>>>> jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : > >>>>>>> AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature } > >>>>>>> > >>>>>>> This would be interpreted as: > >>>>>>> > >>>>>>> * Irrespective of the provider (*), Cipher services should be > >>>>>>> removed (-). This rule would be superfluous in this case because > the > >>>>>>> property itself is an allow-list and there is nothing to the left > >>>>>>> that > >>>>>>> enables Cipher service types for any provider. > >>>>>>> * From the SunJCE security provider, Cipher services with > >>>>>>> AES/GCM/NoPadding and DES transformations are allowed, and > Signature > >>>>>>> services with any algorithm are allowed. Notice that there is a > >>>>>>> shortcut here: the algorithm list that follows the service name, > "': > >>>>>>> alg-1, ..." is optional. When omitted all the service's algorithms > >>>>>>> are > >>>>>>> enabled. > >>>>>>> * From the SUN security provider, every service type is > allowed > >>>>>>> except Signature (recall that a minus sign can only apply to a > >>>>>>> service, removing all associated algorithms). > >>>>>>> > >>>>>>> It's not the goal of this proposal to invalidate property values > that > >>>>>>> lead to inconsistent internal states, such as "the Cipher service > of > >>>>>>> SunJCE depends on AlgorithmParameters from SUN". This is because > the > >>>>>>> combinations for a check are virtually infinite: there can be 3rd > >>>>>>> party security providers with their own semantics and > >>>>>>> dependencies. In > >>>>>>> the same way, we cannot determine at start time any application > >>>>>>> dependencies. It's up to the user to analyze all types of > >>>>>>> dependencies > >>>>>>> before setting a value. > >>>>>>> > >>>>>>> > >>>>>>> Alternative #2 > >>>>>>> =========================== > >>>>>>> > >>>>>>> Introduce a boolean security property to turn the value of the > >>>>>>> existing jdk.security.provider.preferred property into the only > >>>>>>> combinations of algorithm, service and provider that are allowed: > >>>>>>> > >>>>>>> jdk.security.provider.preferredOnly = true > >>>>>>> > >>>>>>> The default value for the new property would be "false", keeping > the > >>>>>>> current "preferred" behavior in which all algorithms and services > >>>>>>> from > >>>>>>> installed security providers are available. > >>>>>>> > >>>>>>> Contrary to Alternative #1, the user has to explicitly list the > >>>>>>> algorithms and cannot rely on wildcards to express wide categories > >>>>>>> such as "all Cipher algorithms from SunJCE" or "all algorithms from > >>>>>>> SunJCE". The use of minus signs to remove service types or > algorithms > >>>>>>> wouldn't be available either. > >>>>>>> > >>>>>>> In order to mitigate the burden on users we can consider extending > >>>>>>> jdk.security.provider.preferred syntax as long as we keep > >>>>>>> backward-compatibility and stay within the boundaries of a > >>>>>>> "preferred" > >>>>>>> semantics. For example, we can accept a value of > >>>>>>> "jdk.security.provider.preferred=SunJCE" to mean that any service > and > >>>>>>> any algorithm from SunJCE is either preferred or allowed, > >>>>>>> depending on > >>>>>>> the value of jdk.security.provider.preferredOnly. This case would > >>>>>>> be a > >>>>>>> service type and algorithm wildcard. We can also define an > >>>>>>> algorithms-only wildcard, such as Cipher.*:SunJCE. > >>>>>>> > >>>>>>> Alternative #2 has the advantage of reusing most or all of the > >>>>>>> existing syntax. However, it's worth noticing that it implies an > >>>>>>> overloaded semantic that can turn confusing or inconvenient in some > >>>>>>> cases. As an example, a user that relies on the prioritized > security > >>>>>>> providers list for most of the algorithms and has only a few > >>>>>>> preferred > >>>>>>> exceptions, would need to express preferences by extension upon > >>>>>>> turning on this feature. Alternative #1 keeps preferences and > >>>>>>> availability as two separate concepts, in a more clear way. > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Martin.- > >>>>>>> > >>>>>>> -- > >>>>>>> [1] - > >>>>>>> > https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D > >>>>>>> (?) - Thanks to @fferrari for his contributions to this proposal. > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Fri Sep 1 17:45:59 2023 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 1 Sep 2023 19:45:59 +0200 Subject: Modification of Client hello TLS packet In-Reply-To: References: Message-ID: <55265998-F2DD-5F48-8D2E-0D80090F29C5@hxcore.ol> An HTML attachment was scrubbed... URL: From karl.scheibelhofer at gmx.net Fri Sep 1 19:15:00 2023 From: karl.scheibelhofer at gmx.net (Karl Scheibelhofer) Date: Fri, 1 Sep 2023 21:15:00 +0200 Subject: PEM KeyStore Implementation Message-ID: Hi, Working with Java and the JCA KeyStore for decades, I came across many situations where I thought it would be convenient to be able to load private keys and certificates in PEM format directly using the KeyStore API. Without the need to convert them to PKCS#12/JKS. You can find my implementation of a PEM KeyStore in https://github.com/KarlScheibelhofer/java-crypto-tools. I wondered if it would make sense to integrate such an implementation in one of the standard providers of OpenJDK - like the SUN provider. What do you think? Best regards Karl From jwaters at openjdk.org Mon Sep 4 04:26:52 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 4 Sep 2023 04:26:52 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <7ZF55XhZ0rnp3kL1VVR73r7_FINgAixdnoWg-xX0T8E=.8f6282f0-3de7-4ba3-8fa8-08bf2e190a7a@github.com> On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Bumping? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1704589862 From lkorinth at openjdk.org Mon Sep 4 11:04:44 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 4 Sep 2023 11:04:44 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com> On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name. What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1705068700 From mbaesken at openjdk.org Mon Sep 4 13:16:00 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Sep 2023 13:16:00 GMT Subject: RFR: JDK-8315644: increase timeout of sun/security/tools/jarsigner/Warning.java Message-ID: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> on some slow machines, sun/security/tools/jarsigner/Warning.java runs sometimes into timeouts (with fastdebug binaries). So the current timeout of the test should be increased. ------------- Commit messages: - JDK-8315644 Changes: https://git.openjdk.org/jdk/pull/15560/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15560&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315644 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15560.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15560/head:pull/15560 PR: https://git.openjdk.org/jdk/pull/15560 From clanger at openjdk.org Mon Sep 4 13:18:39 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 4 Sep 2023 13:18:39 GMT Subject: RFR: JDK-8315644: increase timeout of sun/security/tools/jarsigner/Warning.java In-Reply-To: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> References: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> Message-ID: On Mon, 4 Sep 2023 13:09:08 GMT, Matthias Baesken wrote: > on some slow machines, sun/security/tools/jarsigner/Warning.java runs sometimes into timeouts (with fastdebug binaries). > So the current timeout of the test should be increased. Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15560#pullrequestreview-1609533540 From mbaesken at openjdk.org Mon Sep 4 13:23:38 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Sep 2023 13:23:38 GMT Subject: RFR: JDK-8315644: increase timeout of sun/security/tools/jarsigner/Warning.java In-Reply-To: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> References: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> Message-ID: On Mon, 4 Sep 2023 13:09:08 GMT, Matthias Baesken wrote: > on some slow machines, sun/security/tools/jarsigner/Warning.java runs sometimes into timeouts (with fastdebug binaries). > So the current timeout of the test should be increased. Hi Christoph, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15560#issuecomment-1705265439 From lucy at openjdk.org Mon Sep 4 13:54:38 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 4 Sep 2023 13:54:38 GMT Subject: RFR: JDK-8315644: increase timeout of sun/security/tools/jarsigner/Warning.java In-Reply-To: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> References: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> Message-ID: On Mon, 4 Sep 2023 13:09:08 GMT, Matthias Baesken wrote: > on some slow machines, sun/security/tools/jarsigner/Warning.java runs sometimes into timeouts (with fastdebug binaries). > So the current timeout of the test should be increased. LGTM. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15560#pullrequestreview-1609594098 From duke at openjdk.org Mon Sep 4 15:03:40 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 4 Sep 2023 15:03:40 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 06:12:29 GMT, Smita Kamath wrote: > Hi All, > I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. > > Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: > > |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup > |-------------|------------|---------------|------------------|-----------| > |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 > full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 > small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 > small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 > full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 > full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 > small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 > small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 > full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 > small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 > small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 > full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 > full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 > small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 > small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 > full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 > small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 > small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 > full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 > full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 > small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 > small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 > full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 > small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 > small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 > full.AESGCMBench.decryptMultiPart | 65536 | 42649.816 | 47591.587 |1.11 > full.AESGCMBe... src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 590: > 588: private static int implGCMCrypt(byte[] in, int inOfs, int inLen, byte[] ct, > 589: int ctOfs, byte[] out, int outOfs, > 590: GCTR gctr, GHASH ghash, boolean encryption) { It looks to me that you don't need to introduce this "boolean encryption" here as it is simply (ct == out), which can easily be calculated in the intrinsics and that saves a lot of code change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1315041764 From mbaesken at openjdk.org Tue Sep 5 07:09:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 5 Sep 2023 07:09:48 GMT Subject: Integrated: JDK-8315644: increase timeout of sun/security/tools/jarsigner/Warning.java In-Reply-To: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> References: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> Message-ID: On Mon, 4 Sep 2023 13:09:08 GMT, Matthias Baesken wrote: > on some slow machines, sun/security/tools/jarsigner/Warning.java runs sometimes into timeouts (with fastdebug binaries). > So the current timeout of the test should be increased. This pull request has now been integrated. Changeset: 8bbebbba Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/8bbebbba8fb870987295cb5f96147a9f9c5bfa6c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8315644: increase timeout of sun/security/tools/jarsigner/Warning.java Reviewed-by: clanger, lucy ------------- PR: https://git.openjdk.org/jdk/pull/15560 From mbaesken at openjdk.org Tue Sep 5 07:09:47 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 5 Sep 2023 07:09:47 GMT Subject: RFR: JDK-8315644: increase timeout of sun/security/tools/jarsigner/Warning.java In-Reply-To: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> References: <7wF6QTrGcUCnWzFwuIrw9oS9ZC9GtXzQR_RQDnEQ_-k=.0d2ed5b6-61a8-4ecf-9401-9a4ad5b68a7b@github.com> Message-ID: <6ltmGET7I-cf9GSkUyGJOI2oMg9uFu2KXvppZ3hyR1k=.52ccaee9-e0e4-421b-969a-e7b9cb0a5ee1@github.com> On Mon, 4 Sep 2023 13:09:08 GMT, Matthias Baesken wrote: > on some slow machines, sun/security/tools/jarsigner/Warning.java runs sometimes into timeouts (with fastdebug binaries). > So the current timeout of the test should be increased. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15560#issuecomment-1706056069 From andrew at openjdk.org Tue Sep 5 10:17:31 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 5 Sep 2023 10:17:31 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so [v2] In-Reply-To: References: Message-ID: <809XWPj9BRMFRwTOLV6G6hXeFaZVp9KWYNr8FiWx9o4=.61c031f7-04f7-4a45-9f8b-5501bb682e26@github.com> > There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library. > > On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843) > > On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`. So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so` > > This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with. All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems. > > A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream. > > Testing: > > Test case: > ~~~ > import java.lang.reflect.Method; > > public class TestPlatformPCSC { > public static void main(String[] args) > throws Exception { > Class cls = Class.forName("sun.security.smartcardio.PlatformPCSC"); > Method m = cls.getDeclaredMethod("getLibraryName"); > m.setAccessible(true); > System.err.println(m.invoke(null)); > } > } > ~~~ > > 1. With `libpcsclite.so.1` available: > ~~~ > $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.d... Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: Drop outdated kfreebsd case and document arch template and arm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15409/files - new: https://git.openjdk.org/jdk/pull/15409/files/d0523302..a1bb209e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15409&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15409&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15409.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15409/head:pull/15409 PR: https://git.openjdk.org/jdk/pull/15409 From andrew at openjdk.org Tue Sep 5 10:19:38 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 5 Sep 2023 10:19:38 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so [v2] In-Reply-To: References: <7p4Yu7bY60i-wdyLGEuvxW2SYbd0mlFTW4u18Fg87lI=.d39275bc-b082-4fa0-99a7-ac4cadde8e89@github.com> Message-ID: <9SkmwVtOEA7J4ARY2JkoZ6RM76LEg1EyNMRddwwDIMo=.e13a1f00-5c3d-4cc3-9882-e301627838d7@github.com> On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe wrote: > Yes, that's a bit tricky. I was concerned about the JVM picking up the wrong library on a mulitarch system, since having multiple of these directories is the point of multiarch. > If the architecture is not 32-bit arm and the library is installed for that architecture, it should catch that first via the `/usr/lib/$ARCH-linux-gnu/libpcsclite.so` template and return. The only potential issue seems to be if, for some reason, an unusable arm32 pcsclite library is installed and not one for the architecture itself, which seems very unlikely. > But maybe its fine. The difference between the arm variants is that the float mode (soft vs hard) and I believe the former should always work, so if we accidentally pick it up, it should be no problem. Good to know. If there is a way to pick it up, I'd be happy to add it, but I'm not aware of it and don't have access to a Debian arm32 system to test on. > > The kfreebsd one I'd just drop. Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1706340448 From sviswanathan at openjdk.org Tue Sep 5 15:38:50 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 5 Sep 2023 15:38:50 GMT Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests having shared state In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma wrote: > In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems. > > org/openjdk/bench/java/io/DataInputStreamTest.java > org/openjdk/bench/java/lang/ArrayClone.java > org/openjdk/bench/java/lang/StringCompareToDifferentLength.java > org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java > org/openjdk/bench/java/lang/StringComparisons.java > org/openjdk/bench/java/lang/StringEquals.java > org/openjdk/bench/java/lang/StringFormat.java > org/openjdk/bench/java/lang/StringReplace.java > org/openjdk/bench/java/lang/StringSubstring.java > org/openjdk/bench/java/lang/StringTemplateFMT.java > org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java > org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java > org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java > org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java > org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java > org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java > org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java > org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java > org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java > org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java > org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java > org/openjdk/bench/java/security/CipherSuiteBench.java > org/openjdk/bench/java/time/GetYearBench.java > org/openjdk/bench/java/time/InstantBench.java > org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java > org/openjdk/bench/java/util/ListArgs.java > org/openjdk/bench/java/util/LocaleDefaults.java > org/openjdk/bench/java/util/TestAdler32.java > org/openjdk/bench/java/util/TestCRC32.java > org/openjdk/bench/java/util/TestCRC32C.java > org/openjdk/bench/java/util/regex/Exponential.java > org/openjdk/bench/java/util/regex/Primality.java > org/openjdk/bench/java/util/regex/Trim.java > org/openjdk/bench/javax/crypto/AESReinit.java > org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java > org/openjdk/bench/vm/compiler/Rotation.java > org/openjdk/bench/vm/compiler/x86/ConvertF2I.java > org/openjdk/bench/vm/compiler/x86/BasicRules.java > > Please review and provide your feedback. > > Thanks, > Swati @ericcaspole Could you please also review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15230#issuecomment-1706851997 From andrew at openjdk.org Tue Sep 5 15:54:39 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 5 Sep 2023 15:54:39 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so [v2] In-Reply-To: References: <7p4Yu7bY60i-wdyLGEuvxW2SYbd0mlFTW4u18Fg87lI=.d39275bc-b082-4fa0-99a7-ac4cadde8e89@github.com> Message-ID: On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe wrote: >>> Changes look fine. I submitted a mach5 test job just in case. Will approve once the test job passes. BTW, I added a noreg-other label since there is no regression test for this change. >> >> Thanks. Yes, I don't see how we can have a regression test for this one. My own testing was manual and involved moving the system library around as root... > >> > Hi @gnu-andrew, >> > in your last example, why does it look for both arm and x64 packages? And why for kFreeBsd? I see you have both hardcoded, why? >> > I would expect it only to attempt and pick up the architecture and OS the VM was built for. >> >> Good question. >> >> Because they don't fit the template `$ARCH-linux-gnu/libpcsclite.so` which would expand to `arm-linux-gnu/libpcsclite.so`. >> >> I don't know of a way off-hand to get the ABI or the kernel in use (`kfreebsd` is not a BSD variant, but the usual GNU userland paired with the FreeBSD kernel rather than Linux). The [Wikipedia page](https://en.wikipedia.org/wiki/Debian#Derivatives_and_flavors) actually says it's now discontinued, so maybe we can just drop that one. It probably shows how long ago I [originally wrote and tested these paths](https://icedtea.wildebeest.org/hg/release/icedtea7-forest-2.6/jdk/rev/ae5765c7b8e2)... :) >> >> In short, that was my lazy option for catching those cases that won't fit the common one. I'm open to suggestions. We could skip any template with `'arm'` in, I guess, if the architecture doesn't match. It is worth noting though, that this file is already common to all the UNIX platforms and doesn't do any OS checks, despite the last check being a MacOS framework. That also presumably means MacOS doesn't have any of the `/usr` libraries in turn . > > Yes, that's a bit tricky. I was concerned about the JVM picking up the wrong library on a mulitarch system, since having multiple of these directories is the point of multiarch. > > But maybe its fine. The difference between the arm variants is that the float mode (soft vs hard) and I believe the former should always work, so if we accidentally pick it up, it should be no problem. > > The kfreebsd one I'd just drop. @tstuefe if you're happy with the minor change I added, I'll push. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1706883089 From mullan at openjdk.org Tue Sep 5 17:21:47 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Sep 2023 17:21:47 GMT Subject: RFR: 8161536: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with ProviderException In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 20:45:06 GMT, Rajan Halade wrote: > This test is removed from ProblemList. I ran test locally and on CI with hundred iteration. Failure is not seen as [JDK-8240256](https://bugs.openjdk.org/browse/JDK-8240256) is fixed. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15497#pullrequestreview-1611578827 From rhalade at openjdk.org Tue Sep 5 17:54:46 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 5 Sep 2023 17:54:46 GMT Subject: Integrated: 8161536: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with ProviderException In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 20:45:06 GMT, Rajan Halade wrote: > This test is removed from ProblemList. I ran test locally and on CI with hundred iteration. Failure is not seen as [JDK-8240256](https://bugs.openjdk.org/browse/JDK-8240256) is fixed. This pull request has now been integrated. Changeset: 939d7c5d Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/939d7c5d8466f9e392beae2947a494ac28695cc1 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod 8161536: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with ProviderException Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/15497 From rriggs at openjdk.org Tue Sep 5 18:08:39 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 18:08:39 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com> References: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com> Message-ID: On Mon, 4 Sep 2023 11:01:23 GMT, Leo Korinth wrote: > What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name. There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added. @AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process. Every test writer should be aware that additional command line options may be mixed in. There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures. As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707072375 From duke at openjdk.org Tue Sep 5 20:29:52 2023 From: duke at openjdk.org (duke) Date: Tue, 5 Sep 2023 20:29:52 GMT Subject: Withdrawn: JDK-8305406: Add @spec tags in java.base/java.* (part 2) In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 19:46:32 GMT, Jonathan Gibbons wrote: > Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13336 From msheppar at openjdk.org Tue Sep 5 22:25:39 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 5 Sep 2023 22:25:39 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import > From talking to other HotSpot devs it is quite clear that the different names lead to mistakes when writing (copy-n-pasting) tests, so I'm happy that we try to figure out some way to make it more obvious when we prepend the extra test options and when we don't. > > I agree with @msheppar that `createTestJvm` isn't a good name and I wouldn't be opposed to changing that name instead of `createJavaProcessBuilder`. However, if we do rename that function I strongly urge us to also rename the corresponding `executeTestJvm` function. > > I also think it is too obscure that functions with _Test_ in the name prepend the extra test options, and those without _Test_ don't, so I'd like to get rid of that convention. > > I wouldn't be opposed to a change that: > > * Keeps the `createJavaProcessBuilder` name > > * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts` > > * Renames `executeTestJvm` to `executeJavaPrependTestOpts` > > * Removes `createTestJava` > > * Removes `executeTestJava` I think @stefank made a reasonable suggestion which was endorsed by @AlanBateman which would remove the misconception hurdle ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707391042 From erikj at openjdk.org Tue Sep 5 22:58:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 5 Sep 2023 22:58:17 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header Message-ID: There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. ------------- Commit messages: - JDK-8267174 Changes: https://git.openjdk.org/jdk/pull/15573/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15573&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8267174 Stats: 1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod Patch: https://git.openjdk.org/jdk/pull/15573.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15573/head:pull/15573 PR: https://git.openjdk.org/jdk/pull/15573 From valeriep at openjdk.org Tue Sep 5 23:05:39 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 5 Sep 2023 23:05:39 GMT Subject: RFR: 8313575: Refactor PKCS11Test tests In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 21:01:23 GMT, Rajan Halade wrote: > PKCS11Test is updated to remove testDefault and testDeimos. Sun Crypto Accelerator is not supported now and there is no default PKCS11 provider with default JDK configuration. Looks good. Thanks! ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15523#pullrequestreview-1612060225 From rhalade at openjdk.org Tue Sep 5 23:11:44 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 5 Sep 2023 23:11:44 GMT Subject: Integrated: 8313575: Refactor PKCS11Test tests In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 21:01:23 GMT, Rajan Halade wrote: > PKCS11Test is updated to remove testDefault and testDeimos. Sun Crypto Accelerator is not supported now and there is no default PKCS11 provider with default JDK configuration. This pull request has now been integrated. Changeset: 7a08e6bd Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/7a08e6bdd63c2b4d6283c0c45820024199a4614e Stats: 98 lines in 4 files changed: 0 ins; 94 del; 4 mod 8313575: Refactor PKCS11Test tests Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/15523 From cjplummer at openjdk.org Tue Sep 5 23:15:36 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 5 Sep 2023 23:15:36 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707426607 From jjg at openjdk.org Tue Sep 5 23:18:39 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 5 Sep 2023 23:18:39 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup ------------- PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612069262 From valeriep at openjdk.org Tue Sep 5 23:37:37 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 5 Sep 2023 23:37:37 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Security area looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612089791 From alanb at openjdk.org Wed Sep 6 07:53:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Sep 2023 07:53:36 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote: > One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup The IBM double byte charsets were re-implemented in JDK 7. I think the old implementations moved to the test tree so it could be used to test the new/replacement implementations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707845577 From dfuchs at openjdk.org Wed Sep 6 11:54:38 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 6 Sep 2023 11:54:38 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. jmx, jndi, and net changes LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613147541 From aivanov at openjdk.org Wed Sep 6 13:09:38 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 6 Sep 2023 13:09:38 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Client changes look good. I've looked through all the files, other files look good too. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613295743 From tprinzing at openjdk.org Wed Sep 6 15:57:41 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 6 Sep 2023 15:57:41 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> On Tue, 22 Aug 2023 07:31:36 GMT, Alan Bateman wrote: > > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops > > Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops. I think it's useful if trying to trace the calls (i.e. set to 0ms). Apparently the security manager was being used for that by some. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1708657617 From iris at openjdk.org Wed Sep 6 16:02:41 2023 From: iris at openjdk.org (Iris Clark) Date: Wed, 6 Sep 2023 16:02:41 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Thanks for fixing! ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613704179 From erikj at openjdk.org Wed Sep 6 16:09:41 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 6 Sep 2023 16:09:41 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 23:12:51 GMT, Chris Plummer wrote: > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. Do you think I should revert them? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708676439 From lkorinth at openjdk.org Wed Sep 6 16:24:45 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 6 Sep 2023 16:24:45 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import I think you are missing the point. If you take a look at [the parent bug of the sub task](https://bugs.openjdk.org/browse/JDK-8314823) you can see that the problem described is *not* that people are using `createTestJvm` in error. The problem is that they are (or possibly are) using `createJavaProcessBuilder` in error. Thus renaming `createTestJvm` might help a little at most for this specific problem. Renaming `createJavaProcessBuilder` most probably helps *more*. I guess the alternative of forcing the user to make a choice using an enum value will help even more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1708705105 From cjplummer at openjdk.org Wed Sep 6 16:52:42 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 6 Sep 2023 16:52:42 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:06:29 GMT, Erik Joelsson wrote: > > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. > > Do you think I should revert them? I'm not sure. I think you need to consult someone with expertise in this area. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708757719 From alanb at openjdk.org Wed Sep 6 17:45:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Sep 2023 17:45:41 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote: > > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. > > Do you think I should revert them? They are test classes now. If someone does want to copy them into their own repo then I assume they can take it from an old repo, maybe from when the "hat" tool existed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708828207 From mchung at openjdk.org Wed Sep 6 18:41:54 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 18:41:54 GMT Subject: RFR: 8315810: Reimplement ReflectionFactory::newConstructorForSerialization with method handles Message-ID: This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. ------------- Commit messages: - Reimplement ReflectionFactory::newConstructorForSerialization with method handle Changes: https://git.openjdk.org/jdk/pull/15600/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15600&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315810 Stats: 162 lines in 10 files changed: 122 ins; 11 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/15600.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15600/head:pull/15600 PR: https://git.openjdk.org/jdk/pull/15600 From hchao at openjdk.org Wed Sep 6 20:02:10 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 6 Sep 2023 20:02:10 GMT Subject: RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length [v2] In-Reply-To: References: Message-ID: > Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Set to default if a negative value is set ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15163/files - new: https://git.openjdk.org/jdk/pull/15163/files/e13a68fd..2b91946f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=00-01 Stats: 37 lines in 1 file changed: 18 ins; 8 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/15163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15163/head:pull/15163 PR: https://git.openjdk.org/jdk/pull/15163 From hchao at openjdk.org Wed Sep 6 20:02:10 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 6 Sep 2023 20:02:10 GMT Subject: RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length [v2] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 15:36:54 GMT, Mark Powers wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Set to default if a negative value is set > > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 115: > >> 113: "jdk.tls.maxCertificateChainLength", 10); >> 114: >> 115: // Limit the maximum certificate chain length accepted from clients > > Should these be moved to after line 89? Remain to stay after the related maxCertificateChainLength. > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 150: > >> 148: */ >> 149: static { >> 150: Integer clientLen = GetIntegerAction.privilegedGetProperty( > > I think you could call `privilegedGetProperty` with the default value as second argument. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1317760306 PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1317760395 From hchao at openjdk.org Wed Sep 6 20:02:11 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 6 Sep 2023 20:02:11 GMT Subject: RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length [v2] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 17:23:11 GMT, Jamil Nimeh wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Set to default if a negative value is set > > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 159: > >> 157: maxServerCertificateChainLength = (serverLen != null) ? >> 158: serverLen : maxCertificateChainLength; >> 159: } > > I wonder if we should take the opportunity here with these new properties as well as `jdk.tls.maxCertificateChainLength` to also equate negative numbers (and maybe zero) to be the default. Right now only property values that fail the internal parseInt conversion will evaluate to `null` and would be assigned the default I think. But a negative value I think would be taken as-is from the property. Should a negative max cert chain length get set to the default? If so, it might also make sense to give a warning about the offending value and note that it is being set to the default (similar to what `GetPropertyAction.privilegedGetTimeoutProp()` does). > If you think this is worthwhile, the CSR should probably be updated to reflect that also. Change made to set to the default when a negative value is set for these system properties. Updated CSR for this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1317760469 From jnimeh at openjdk.org Wed Sep 6 20:22:39 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 6 Sep 2023 20:22:39 GMT Subject: RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length [v2] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 20:02:10 GMT, Hai-May Chao wrote: >> Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Set to default if a negative value is set This looks good to me. Thanks for making that negative value update. ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15163#pullrequestreview-1614147348 From alanb at openjdk.org Thu Sep 7 06:48:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Sep 2023 06:48:40 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> References: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> Message-ID: On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote: > I think it's useful if trying to trace the calls (i.e. set to 0ms). Apparently the security manager was being used for that by some. The SM isn't called once connected so I don't think anyone could have every done that. Yes, you could set the threshold to 0ms to emit event for every read/write but I wonder how useful that would be, maybe I/O stats would be more interesting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1709568576 From djelinski at openjdk.org Thu Sep 7 06:52:39 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 7 Sep 2023 06:52:39 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 21:38:04 GMT, Daniel Jeli?ski wrote: >> Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. >> >> All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. >> >> SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. >> >> Tier1-3 tests pass. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Fix exception handling > - Fix indentation Can I get another review on this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15148#issuecomment-1709572452 From duke at openjdk.org Thu Sep 7 18:19:53 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 7 Sep 2023 18:19:53 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback Message-ID: Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` ------------- Commit messages: - removed jks as fallback keystore and replaced with pkcs12 Changes: https://git.openjdk.org/jdk/pull/15625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304956 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15625/head:pull/15625 PR: https://git.openjdk.org/jdk/pull/15625 From duke at openjdk.org Thu Sep 7 18:35:43 2023 From: duke at openjdk.org (Findoboutme32) Date: Thu, 7 Sep 2023 18:35:43 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback In-Reply-To: References: Message-ID: <_AVDZdvDwy8fCG1BmiI9gx9vnB5q1E7G52lMkgl9uFc=.b8043334-46f9-4a9f-89f1-6f9d573fb1a8@github.com> On Thu, 7 Sep 2023 18:12:28 GMT, Ben Perez wrote: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` Marked as reviewed by Findoboutme32 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/15625#pullrequestreview-1616027096 From coffeys at openjdk.org Thu Sep 7 19:17:39 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 7 Sep 2023 19:17:39 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback In-Reply-To: References: Message-ID: <33tWX0oSqff_KZ_phd9T0l2ojvgbSPVM7pmUDT_f8s8=.8fe0da92-1fc7-42e6-8d5c-1dfd275b2a9b@github.com> On Thu, 7 Sep 2023 18:12:28 GMT, Ben Perez wrote: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` looks fine. Could you add some test code (perhaps to an existing test) for this ? It should be trivial to test. I think you'll need a CSR also ------------- PR Comment: https://git.openjdk.org/jdk/pull/15625#issuecomment-1710650911 From mullan at openjdk.org Thu Sep 7 19:24:40 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 7 Sep 2023 19:24:40 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:12:28 GMT, Ben Perez wrote: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > looks fine. Could you add some test code (perhaps to an existing test) for this ? It should be trivial to test. > > I think you'll need a CSR also > > /csr Yes, I agree a CSR is needed since the specification behavior is being changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15625#issuecomment-1710657080 From coffeys at openjdk.org Thu Sep 7 19:24:42 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 7 Sep 2023 19:24:42 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:12:28 GMT, Ben Perez wrote: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` looks like this comment in the same file could be updated also: (jks -> pkcs12) /* * Constant to lookup in the Security properties file to determine * the default keystore type. * In the Security properties file, the default keystore type is given as: * 

     * keystore.type=jks
     *
*/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/15625#issuecomment-1710658508 From tprinzing at openjdk.org Thu Sep 7 21:50:17 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Thu, 7 Sep 2023 21:50:17 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v5] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: More changes from review: I didn't like the name of the helper method 'checkForCommit' because it doesn't indicate that it might commit the event. I also don't like 'commitEvent' because it might not. Since JFR events are sort of like a queue I went with a name from collections and called it 'offer' so using it is something like 'SocketReadEvent.offer(...)' which seems like it gets the idea across better. Also improved the javadoc for it. Removed the comments about being instrumented by JFR in Socket.SocketInputStream and Socket.SocketOutputStream. I went ahead and moved the event commiting out of the finally block so that we don't emit events when the read/write did not actually happen. The bugid JDK-8310979 will be used to determine if more should be done in this area. The implRead and implWrite were moved up with the other support methods for read/write. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14342/files - new: https://git.openjdk.org/jdk/pull/14342/files/d6f7df72..9fa27459 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=03-04 Stats: 151 lines in 5 files changed: 57 ins; 81 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From tprinzing at openjdk.org Thu Sep 7 21:57:40 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Thu, 7 Sep 2023 21:57:40 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 07:18:21 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/net/Socket.java line 1133: >> >>> 1131: return parent.getSoTimeout(); >>> 1132: } catch (Throwable t) { >>> 1133: // ignored - avoiding exceptions in jfr event data gathering >> >> This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away. > > Were you able to find out what the timeout is used for? No. I think it's a relic from the distant past though. I think the timeout field should be removed. It's not used on SocketChannel at all, and it doesn't seem useful on Socket. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1319152153 From svkamath at openjdk.org Thu Sep 7 23:25:38 2023 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 7 Sep 2023 23:25:38 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 15:00:23 GMT, Ferenc Rakoczi wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: >> >> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup >> |-------------|------------|---------------|------------------|-----------| >> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 >> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 >> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 >> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 >> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 >> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 >> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 >> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 >> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 >> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 >> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 >> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 >> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 >> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 >> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 >> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 >> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 >> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 >> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 >> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 >> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 >> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 >> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 >> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 >> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 >> full.AES... > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 590: > >> 588: private static int implGCMCrypt(byte[] in, int inOfs, int inLen, byte[] ct, >> 589: int ctOfs, byte[] out, int outOfs, >> 590: GCTR gctr, GHASH ghash, boolean encryption) { > > It looks to me that you don't need to introduce this "boolean encryption" here as it is simply (ct == out), which can easily be calculated in the intrinsics and that saves a lot of code change. @ferakocz Thank you for your comment. I will make the change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1319203520 From svkamath at openjdk.org Thu Sep 7 23:32:37 2023 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 7 Sep 2023 23:32:37 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 23:23:13 GMT, Smita Kamath wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 590: >> >>> 588: private static int implGCMCrypt(byte[] in, int inOfs, int inLen, byte[] ct, >>> 589: int ctOfs, byte[] out, int outOfs, >>> 590: GCTR gctr, GHASH ghash, boolean encryption) { >> >> It looks to me that you don't need to introduce this "boolean encryption" here as it is simply (ct == out), which can easily be calculated in the intrinsics and that saves a lot of code change. > > @ferakocz Thank you for your comment. I will make the change. @ascarpino Apologies for the delay in responding, I was away on vacation. There are fewer number of registers available in the AVX2 algorithm as compared to AVX512. That's why its essential for the intrinsic to know if it is encryption or decryption this time around. I will be implementing Ferenc's suggestion and remove the boolean variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1319206174 From jpai at openjdk.org Fri Sep 8 09:19:46 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 8 Sep 2023 09:19:46 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review comment - use SSLContextTemplate for SSLContext creation in test Please keep open, expecting a security-libs review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13669#issuecomment-1711349035 From anthony.scarpino at oracle.com Fri Sep 8 19:17:31 2023 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 8 Sep 2023 12:17:31 -0700 Subject: PEM KeyStore Implementation In-Reply-To: References: Message-ID: <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com> Hi Karl The keystore is interesting and may have some value. Was your use case mostly reading PEM keys and certificates generated elsewhere for use with a particular application, maybe webservers? Did you see value in writing to this keystore from Java? On the topic of PEM, I hope before the end of the year to have a PEM API JEP. I would be interested in your API feedback from your keystore experiences. I think if this keystore contribution was accepted, it should wait so it can use that API. thanks Tony On 9/1/23 12:15 PM, Karl Scheibelhofer wrote: > Hi, > > Working with Java and the JCA KeyStore for decades, I came across > many situations where I thought it would be convenient to be > able to load private keys and certificates in PEM format directly > using the KeyStore API. Without the need to convert them to PKCS#12/JKS. > > You can find my implementation of a PEM KeyStore in > https://github.com/KarlScheibelhofer/java-crypto-tools. > > I wondered if it would make sense to integrate such an implementation > in one of the standard providers of OpenJDK - like the SUN provider. > What do you think? > > Best regards > > Karl From mpowers at openjdk.org Fri Sep 8 19:48:58 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 8 Sep 2023 19:48:58 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts Message-ID: https://bugs.openjdk.org/browse/JDK-8296631 ------------- Commit messages: - second iteration - Merge - first iteration Changes: https://git.openjdk.org/jdk/pull/15644/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15644&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296631 Stats: 64 lines in 13 files changed: 44 ins; 2 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/15644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15644/head:pull/15644 PR: https://git.openjdk.org/jdk/pull/15644 From karl.scheibelhofer at gmx.net Sun Sep 10 08:04:03 2023 From: karl.scheibelhofer at gmx.net (Karl Scheibelhofer) Date: Sun, 10 Sep 2023 10:04:03 +0200 Subject: PEM KeyStore Implementation In-Reply-To: <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com> References: <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com> Message-ID: Hi Tony, The motivation was mostly about reading PEM keys and certificates generated somewhere else. This is common practice in enterprise environments I work in. Because corporate key material is subject to centralized key management, including generation, backup and rollover. PEM is the format most software products can handle. For Java applications, having a PEM KeyStore would reduce the often required additional step of converting PEM key and certificate in a Java Keystore/PKCS#12. Even truststores handling is easier with individual PEM certificates instead of a single PKCS#12 Truststore. Adding or deleting a single file instead of replacing the complete PKCS#12 store is less error prone and cleaner to track in version control. The additional benefit of a MAC in PKCS#12 adds little to no security in most cases. And being text based, PEM is more version control friendly than binary PKCS#12. But to enable sound support of PEM, I also implemented writing PEM keys and certificates. This way, one can use the JDK keytool to generate key and certificate signing requests in PEM format. Getting the certificate from the CA in PEM, one can use PEM throughout the process. Do you have any links or documentation on the PEM API JEP that you mentioned? Thank you for your feedback and best regards Karl Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino : > > Hi Karl > > The keystore is interesting and may have some value. Was your use case > mostly reading PEM keys and certificates generated elsewhere for use > with a particular application, maybe webservers? Did you see value in > writing to this keystore from Java? > > On the topic of PEM, I hope before the end of the year to have a PEM API > JEP. I would be interested in your API feedback from your keystore > experiences. I think if this keystore contribution was accepted, it > should wait so it can use that API. > > thanks > > Tony > > > On 9/1/23 12:15 PM, Karl Scheibelhofer wrote: > > Hi, > > > > Working with Java and the JCA KeyStore for decades, I came across > > many situations where I thought it would be convenient to be > > able to load private keys and certificates in PEM format directly > > using the KeyStore API. Without the need to convert them to PKCS#12/JKS. > > > > You can find my implementation of a PEM KeyStore in > > https://github.com/KarlScheibelhofer/java-crypto-tools. > > > > I wondered if it would make sense to integrate such an implementation > > in one of the standard providers of OpenJDK - like the SUN provider. > > What do you think? > > > > Best regards > > > > Karl From duke at openjdk.org Sun Sep 10 16:22:14 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 10 Sep 2023 16:22:14 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS Message-ID: Some codes in core libs are duplicated, including: java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS java.util.DecimalDigits::size -> java.lang.Long.stringSize We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: https://github.com/openjdk/jdk/pull/15555 ------------- Commit messages: - reduce duplicate Changes: https://git.openjdk.org/jdk/pull/15651/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315968 Stats: 114 lines in 3 files changed: 73 ins; 33 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From rriggs at openjdk.org Sun Sep 10 16:43:36 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Sun, 10 Sep 2023 16:43:36 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS In-Reply-To: References: Message-ID: On Sun, 10 Sep 2023 16:15:01 GMT, ??? wrote: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 Instead of packing more stuff into SharedSecrets, how about moving some common utilities into package jdk.internal.util or a new package jdk.internal.string. For example, Digits, HexDigits, DecimalDigits, OctalDigits. That would make access better without the overhead shared secrets. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1712866040 From redestad at openjdk.org Sun Sep 10 17:28:37 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 10 Sep 2023 17:28:37 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS In-Reply-To: References: Message-ID: On Sun, 10 Sep 2023 16:15:01 GMT, ??? wrote: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 Yes, moving java.util.Digits to jdk.internal.util was what I had in mind, too. SharedSecrets are only necessary when we have things that need to stay package-private, such as member functions on String. Static utilities like this are generally easier to maintain when they are public but in a non-exported package like jdk.internal.util. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1712887622 From duke at openjdk.org Sun Sep 10 17:59:10 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 10 Sep 2023 17:59:10 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v2] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: move java.util.DecimalDigits to jdk.internal.util.DecimalDigits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/41044955..518ccb75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=00-01 Stats: 565 lines in 12 files changed: 287 ins; 261 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From rriggs at openjdk.org Sun Sep 10 18:13:47 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Sun, 10 Sep 2023 18:13:47 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v2] In-Reply-To: References: Message-ID: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com> On Sun, 10 Sep 2023 17:59:10 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > move java.util.DecimalDigits to jdk.internal.util.DecimalDigits This would cleaner and easier to review, if you moved the classes together and did not refactor the functions. Only include the dependencies. Update the functions in a separate PR. (We can retitle the issue to match). src/java.base/share/classes/java/lang/Long.java line 45: > 43: import static java.lang.String.UTF16; > 44: > 45: import static jdk.internal.util.DecimalDigits.stringSize; Please don't use static import for methods. It makes it much harder to find where they come from. src/java.base/share/classes/java/util/Digits.java line 36: > 34: * @since 21 > 35: */ > 36: sealed interface Digits permits HexDigits, OctalDigits { Don't break up the trio, move all three classes and the interface to jdk.internal.util. I don't see the value in the INSTANCE values but keep it intact. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1618893492 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320839379 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320839614 From duke at openjdk.org Sun Sep 10 18:46:21 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 10 Sep 2023 18:46:21 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v3] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with two additional commits since the last revision: - move java.util.OctalDigits to jdk.internal.util.OctalDigits - none static import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/518ccb75..a2cf492e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=01-02 Stats: 183 lines in 7 files changed: 79 ins; 95 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Sun Sep 10 18:46:24 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 10 Sep 2023 18:46:24 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v2] In-Reply-To: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com> References: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com> Message-ID: On Sun, 10 Sep 2023 18:08:44 GMT, Roger Riggs wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> move java.util.DecimalDigits to jdk.internal.util.DecimalDigits > > src/java.base/share/classes/java/util/Digits.java line 36: > >> 34: * @since 21 >> 35: */ >> 36: sealed interface Digits permits HexDigits, OctalDigits { > > Don't break up the trio, move all three classes and the interface to jdk.internal.util. > I don't see the value in the INSTANCE values but keep it intact. HexDigits I will change after the PR #14745 is merged, Can you add comment /sponsor for me? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320843201 From duke at openjdk.org Sun Sep 10 18:46:25 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 10 Sep 2023 18:46:25 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v2] In-Reply-To: References: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com> Message-ID: On Sun, 10 Sep 2023 18:37:20 GMT, ??? wrote: >> src/java.base/share/classes/java/util/Digits.java line 36: >> >>> 34: * @since 21 >>> 35: */ >>> 36: sealed interface Digits permits HexDigits, OctalDigits { >> >> Don't break up the trio, move all three classes and the interface to jdk.internal.util. >> I don't see the value in the INSTANCE values but keep it intact. > > HexDigits I will change after the PR #14745 is merged, Can you add comment /sponsor for me? I want to remove the Digits interface and use static methods ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320843342 From redestad at openjdk.org Sun Sep 10 21:20:47 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 10 Sep 2023 21:20:47 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v2] In-Reply-To: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com> References: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com> Message-ID: On Sun, 10 Sep 2023 18:08:44 GMT, Roger Riggs wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> move java.util.DecimalDigits to jdk.internal.util.DecimalDigits > > src/java.base/share/classes/java/util/Digits.java line 36: > >> 34: * @since 21 >> 35: */ >> 36: sealed interface Digits permits HexDigits, OctalDigits { > > Don't break up the trio, move all three classes and the interface to jdk.internal.util. > I don't see the value in the INSTANCE values but keep it intact. I agree with @RogerRiggs that these should be moved together and with as few changes as possible. We can do redesigns in follow-ups. I'd be OK with adding static variants of each method as needed, leaving the instance methods unchanged. I'll note that these `java.util.Digits` came in as part of what's currently a preview feature (https://openjdk.org/jeps/430) and the author (@JimLaskey) might have plans that requires an implementation that could be passed around in the final version - so design changes should be coordinated with him. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320862759 From duke at openjdk.org Mon Sep 11 00:17:32 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 00:17:32 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v4] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: move java.util.Digits/HexDigits to jdk.internal.util.Digits/HexDigits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/a2cf492e..3d4fa486 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=02-03 Stats: 47 lines in 6 files changed: 31 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 01:12:25 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 01:12:25 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v5] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: remove java.util.Digits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/3d4fa486..0586c64f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=03-04 Stats: 61 lines in 1 file changed: 0 ins; 61 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From yyang at openjdk.org Mon Sep 11 01:35:50 2023 From: yyang at openjdk.org (Yi Yang) Date: Mon, 11 Sep 2023 01:35:50 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v5] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 01:12:25 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > remove java.util.Digits src/java.base/share/classes/java/lang/Integer.java line 459: > 457: } > 458: > 459: /** Would better to update related comments as well https://github.com/openjdk/jdk/blob/d2e11593006dc32fb8ebbaf12488b8758c8a19ee/src/hotspot/share/opto/stringopts.cpp#L1163-L1165 There are several occurrences in stringopt phase, grep to find them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320912610 From duke at openjdk.org Mon Sep 11 04:00:34 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 04:00:34 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v6] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with two additional commits since the last revision: - remove duplicate stringSize - update related comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/0586c64f..ebcecc34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=04-05 Stats: 15 lines in 2 files changed: 2 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From aturbanov at openjdk.org Mon Sep 11 06:33:05 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 11 Sep 2023 06:33:05 GMT Subject: RFR: 8315974: Make fields final in 'com.sun.crypto.provider' package Message-ID: A few classes in `com.sun.crypto.provider` package have non-final fields which could easily be marked `final`. ------------- Commit messages: - [PATCH]: Make fields final in com.sun.crypto.provider package Changes: https://git.openjdk.org/jdk/pull/15412/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15412&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315974 Stats: 116 lines in 33 files changed: 6 ins; 6 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/15412.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15412/head:pull/15412 PR: https://git.openjdk.org/jdk/pull/15412 From dholmes at openjdk.org Mon Sep 11 07:15:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Sep 2023 07:15:45 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: <-l07QgwUIOOMsXw9SniuLk856xxeIs8v6lwe8SWO_oI=.7c375b23-9f35-4d0d-a7bb-5fe513edb1d5@github.com> On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Looks good. I have often pointed out that the CPE was not relevant for test files but ... Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619274864 From aturbanov at openjdk.org Mon Sep 11 08:51:42 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 11 Sep 2023 08:51:42 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v6] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 04:00:34 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with two additional commits since the last revision: > > - remove duplicate stringSize > - update related comments src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 201: > 199: * @return index of the most significant digit or minus sign, if present > 200: */ > 201: public static int getChars(int i, int index, byte[] buf) { It's unused now. Do we expect usages to be added in following PRs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321206741 From redestad at openjdk.org Mon Sep 11 09:41:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 11 Sep 2023 09:41:41 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v6] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 08:49:18 GMT, Andrey Turbanov wrote: >> ??? has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove duplicate stringSize >> - update related comments > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 201: > >> 199: * @return index of the most significant digit or minus sign, if present >> 200: */ >> 201: public static int getChars(int i, int index, byte[] buf) { > > It's unused now. Do we expect usages to be added in following PRs? These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321272245 From duke at openjdk.org Mon Sep 11 10:35:43 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 10:35:43 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v6] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 09:38:44 GMT, Claes Redestad wrote: >> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 201: >> >>> 199: * @return index of the most significant digit or minus sign, if present >>> 200: */ >>> 201: public static int getChars(int i, int index, byte[] buf) { >> >> It's unused now. Do we expect usages to be added in following PRs? > > These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively. > It's unused now. Do we expect usages to be added in following PRs? I plan to provide the getChars method in this PR and use it in my other PR #15555. I also plan to submit another PR to optimize java.time toString, and I will also use this method. https://github.com/wenshao/jdk/commit/cc82e8c11aeb27c0f8581363f7133c85f6022ca1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321338873 From ihse at openjdk.org Mon Sep 11 10:37:45 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 11 Sep 2023 10:37:45 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Looks good to me. Thanks for doing this cleanup! ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619669362 From duke at openjdk.org Mon Sep 11 12:18:57 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 12:18:57 GMT Subject: RFR: 8315999: Improve Date toString performance Message-ID: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> improve date toString performance, includes: java.util.Date.toString java.util.Date.toGMTString java.time.Instant.toString java.time.LocalDate.toString java.time.LocalDateTime.toString java.time.LocalTime.toString ------------- Commit messages: - improve date toString performance, includes: Changes: https://git.openjdk.org/jdk/pull/15658/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315999 Stats: 663 lines in 12 files changed: 574 ins; 7 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Mon Sep 11 12:23:36 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 12:23:36 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v7] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/ebcecc34..b4fe2aa1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=05-06 Stats: 119 lines in 6 files changed: 0 ins; 111 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 12:23:38 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 12:23:38 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v6] In-Reply-To: References: Message-ID: <6hpcRUcyN77dLmHXAvGAC2UM4hUJNdeBvdnTPLH2SRQ=.44cf0e26-79ec-4b38-bf36-f9cebf388805@github.com> On Mon, 11 Sep 2023 10:33:10 GMT, ??? wrote: >> These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively. > >> It's unused now. Do we expect usages to be added in following PRs? > > I plan to provide the getChars method in this PR and use it in my other PR #15555. I also plan to submit another PR to optimize java.time toString, and I will also use this method. https://github.com/wenshao/jdk/commit/cc82e8c11aeb27c0f8581363f7133c85f6022ca1 > These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively. StringLatin1.getChars has been moved to DecimalDigits.getCharsLatin1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321461917 From duke at openjdk.org Mon Sep 11 12:32:38 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 12:32:38 GMT Subject: RFR: 8315999: Improve Date toString performance In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 12:12:17 GMT, ??? wrote: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString @liach can you help me to review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713782721 From duke at openjdk.org Mon Sep 11 12:51:38 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 12:51:38 GMT Subject: RFR: 8315999: Improve Date toString performance In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 12:12:17 GMT, ??? wrote: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString @cl4es can you help me to review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713812730 From liach at openjdk.org Mon Sep 11 13:45:40 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 11 Sep 2023 13:45:40 GMT Subject: RFR: 8315999: Improve Date toString performance In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 12:12:17 GMT, ??? wrote: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString I think you should make this a dependent of #15651, so you can change the base branch of pr to `openjdk:pr/15651` and you can base your work off that pull request too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713910800 From duke at openjdk.org Mon Sep 11 13:48:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 13:48:42 GMT Subject: RFR: 8315999: Improve Date toString performance In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 13:42:30 GMT, Chen Liang wrote: > I think you should make this a dependent of #15651, so you can change the base branch of pr to `openjdk:pr/15651` and you can base your work off that pull request too. After PR #15651 is merged, changes will be made based on the new API. Until then, you can help review other changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713918857 From redestad at openjdk.org Mon Sep 11 13:58:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 11 Sep 2023 13:58:41 GMT Subject: RFR: 8315999: Improve Date toString performance In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 12:12:17 GMT, ??? wrote: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString As @liach says this should be done on top of #15651. As it stands now a thorough reviews seems a bit premature. Correct me if I'm wrong but the gains come from inlining code into the various `toString` methods to reduce need to go through `DateTimeFormatter`s - which allocate `StringBuilder` and might go through chains of `CompositePrinterParser` and such.. It seems that before inlining and duplicating logic - making the code overall more fragile and harder to maintain - that we ought to see if we can get close enough by optimizing `DateTimeFormatter` and the corresponding builders to produce types that may optimize better. src/java.base/share/classes/java/time/Instant.java line 1355: > 1353: @Override > 1354: public String toString() { > 1355: return DateTimeFormatter.ISO_INSTANT.format(this); Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications. src/java.base/share/classes/java/time/LocalDate.java line 2181: > 2179: if (yearAbs < 1000) { > 2180: if (year < 0) { > 2181: buf[off] = '-'; `buf[off++] = '-';` src/java.base/share/classes/java/time/LocalDate.java line 2188: > 2186: ByteArrayLittleEndian.setInt( > 2187: buf, > 2188: year < 0 ? 1 : 0, `off,` src/java.base/share/classes/java/time/LocalDate.java line 2192: > 2190: } else { > 2191: if (year > 9999) { > 2192: buf[off] = '+'; `buf[off++] = '+';`? ------------- PR Review: https://git.openjdk.org/jdk/pull/15658#pullrequestreview-1620003157 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321554515 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321590202 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321591620 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321588790 From liach at openjdk.org Mon Sep 11 14:10:42 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 11 Sep 2023 14:10:42 GMT Subject: RFR: 8315999: Improve Date toString performance In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 13:45:43 GMT, ??? wrote: > After PR #15651 is merged, changes will be made based on the new API. Until then, you can help review other changes. I mean, OpenJDK's GitHub bots has a special handling system that allows you to include code from #15651 in this PR: 1. Merge your local [reduce_duplicate](https://github.com/wenshao/jdk/tree/reduce_duplicate) branch into your optimization date to string branch 2. Edit PR title image 3. Change PR branch image Then OpenJDK bot will automatically add that you have a prerequisite in the issue body, and after merging #15651, this PR will automatically target against master again. The main advantage is that PR's "File changed" on GitHub and webrevs will not include changes from #15651, so we can save review time and you don't have to update this PR after #15651 is merged. ------------------------------- OpenJDK?GitHub????????????????? 1??? #15651 ?[reduce_duplicate](https://github.com/wenshao/jdk/tree/reduce_duplicate)Git??????????[optim_for_date_to_string_2](https://github.com/wenshao/jdk/tree/optim_for_date_to_string_2)??????? 2??Pull Request??????"Edit"????????????? 3?????????`pr/15651` ????OpenJDK??????????????????????????integrated??????????????master? ??????"Files changed"??????????????????review?????????????????????? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713964226 From liach at openjdk.org Mon Sep 11 14:36:48 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 11 Sep 2023 14:36:48 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v7] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 12:23:36 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1 In short: I suggest splitting the change of moving `getChars` `stringSize` into another patch; they are sufficiently distinct and can shrink this PR's size by a half at least. src/java.base/share/classes/java/lang/StringLatin1.java line 35: > 33: import java.util.stream.Stream; > 34: import java.util.stream.StreamSupport; > 35: import jdk.internal.util.ArraysSupport; Suggestion: import jdk.internal.util.ArraysSupport; import jdk.internal.util.DecimalDigits; Assuming you will restore the `getChars` here. src/java.base/share/classes/java/lang/StringLatin1.java line 42: > 40: import static java.lang.String.checkIndex; > 41: import static java.lang.String.checkOffset; > 42: import static jdk.internal.util.DecimalDigits.digitPair; Suggestion: Redundant. src/java.base/share/classes/java/lang/StringUTF16.java line 45: > 43: > 44: import static jdk.internal.util.DecimalDigits.digitPair; > 45: Suggestion: Per previous comments. Remember to add another line of import jdk.internal.util.DecimalDigits; above! src/java.base/share/classes/java/lang/StringUTF16.java line 1549: > 1547: i = q; > 1548: > 1549: int packed = (int) digitPair(r); Suggestion: int packed = (int) DecimalDigits.digitPair(r); src/java.base/share/classes/java/lang/StringUTF16.java line 1558: > 1556: // We know there are at most two digits left at this point. > 1557: if (i < -9) { > 1558: int packed = (int) digitPair(-i); Suggestion: int packed = (int) DecimalDigits.digitPair(-i); src/java.base/share/classes/java/lang/StringUTF16.java line 1596: > 1594: q = i / 100; > 1595: > 1596: int packed = (int) digitPair((int)((q * 100) - i)); Suggestion: int packed = (int) DecimalDigits.digitPair((int)((q * 100) - i)); src/java.base/share/classes/java/lang/StringUTF16.java line 1610: > 1608: q2 = i2 / 100; > 1609: > 1610: int packed = (int) digitPair((q2 * 100) - i2); Suggestion: int packed = (int) DecimalDigits.digitPair((q2 * 100) - i2); src/java.base/share/classes/java/lang/StringUTF16.java line 1622: > 1620: charPos -= 2; > 1621: > 1622: int packed = (int) digitPair(-i2); Suggestion: int packed = (int) DecimalDigits.digitPair(-i2); src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 43: > 41: } > 42: > 43: public int digits(long value, byte[] buffer, int index, MethodHandle putCharMH) throws Throwable { `@Override` src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143: > 141: * code after loop unrolling. > 142: */ > 143: public static int stringSize(int x) { I suggest splitting the moves of `stringSize` `getChars` into a new PR dependent on this one; your future date and time optimizations can depend on that one, which exposes stringSize. Having the DecimalDigits package move and `stringSize` `getChars` moves together complicates the file changes, and it's hard to detect if there's any accidental typo/malicious code in the new additions. src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 68: > 66: > 67: @Override > 68: public int digits(long value, byte[] buffer, int index, MethodHandle putCharMH) throws Throwable { Can you revert these IDE reformatting changes? So that we don't pollute the changeset and the Git blame log, making reviews and reverting patches easier. For example, only 3 lines of changes are truly necessary in this class: Changing the package, `public ` before `final class OctalDigits` and `static final Digits INSTANCE`. ------------- PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1619894567 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648971 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321650127 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321646310 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321647751 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321647883 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648031 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648149 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648317 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321487786 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321644436 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321640635 From duke at openjdk.org Mon Sep 11 14:44:24 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 14:44:24 GMT Subject: RFR: 8315999: Improve Date toString performance [v2] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with one additional commit since the last revision: fix LocalDate.getChars offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/cc82e8c1..24adeb70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Mon Sep 11 14:44:30 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 14:44:30 GMT Subject: RFR: 8315999: Improve Date toString performance [v2] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 13:50:30 GMT, Claes Redestad wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> fix LocalDate.getChars offset > > src/java.base/share/classes/java/time/LocalDate.java line 2181: > >> 2179: if (yearAbs < 1000) { >> 2180: if (year < 0) { >> 2181: buf[off] = '-'; > > `buf[off++] = '-';` this place doesn't need off++ > src/java.base/share/classes/java/time/LocalDate.java line 2192: > >> 2190: } else { >> 2191: if (year > 9999) { >> 2192: buf[off] = '+'; > > `buf[off++] = '+';`? this place doesn't need off++ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321658186 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321658742 From redestad at openjdk.org Mon Sep 11 14:47:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 11 Sep 2023 14:47:41 GMT Subject: RFR: 8315999: Improve Date toString performance [v2] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 14:38:28 GMT, ??? wrote: >> src/java.base/share/classes/java/time/LocalDate.java line 2181: >> >>> 2179: if (yearAbs < 1000) { >>> 2180: if (year < 0) { >>> 2181: buf[off] = '-'; >> >> `buf[off++] = '-';` > > this place doesn't need off++ It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)` from line 2188. >> src/java.base/share/classes/java/time/LocalDate.java line 2192: >> >>> 2190: } else { >>> 2191: if (year > 9999) { >>> 2192: buf[off] = '+'; >> >> `buf[off++] = '+';`? > > this place doesn't need off++ Correct, though it's a bit opaque that `yearSize` includes room for the `'+'` that gets added on years > 9999 but that `jla.getChars` won't print that. This makes the logic somewhat fragile, which I think could be improved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321663810 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321666764 From duke at openjdk.org Mon Sep 11 14:57:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 14:57:42 GMT Subject: RFR: 8315999: Improve Date toString performance [v2] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com> On Mon, 11 Sep 2023 13:29:14 GMT, Claes Redestad wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> fix LocalDate.getChars offset > > src/java.base/share/classes/java/time/Instant.java line 1355: > >> 1353: @Override >> 1354: public String toString() { >> 1355: return DateTimeFormatter.ISO_INSTANT.format(this); > > Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? > > Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications. The performance of optimizing DateTimeFormatter cannot be as fast as using ixed-length buffer directly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321680823 From duke at openjdk.org Mon Sep 11 15:02:47 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 15:02:47 GMT Subject: RFR: 8315999: Improve Date toString performance [v2] In-Reply-To: <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com> Message-ID: <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com> On Mon, 11 Sep 2023 14:54:57 GMT, ??? wrote: >> src/java.base/share/classes/java/time/Instant.java line 1355: >> >>> 1353: @Override >>> 1354: public String toString() { >>> 1355: return DateTimeFormatter.ISO_INSTANT.format(this); >> >> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? >> >> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications. > > The performance of optimizing DateTimeFormatter cannot be as fast as using ixed-length buffer directly. Of course, the optimization of DateTimeFormatter is more general, and we can spend time doing it later. The format of toString is fixed, we can not use DateTimeFormatter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321686942 From duke at openjdk.org Mon Sep 11 15:47:50 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 15:47:50 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v8] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: 1. add override 2. none static import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/b4fe2aa1..4a1eefae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=06-07 Stats: 11 lines in 3 files changed: 3 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 15:52:21 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 15:52:21 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v9] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - fix merge conflict - Merge branch 'master' into reduce_duplicate # Conflicts: # src/java.base/share/classes/java/lang/StringUTF16.java - 1. add override 2. none static import - move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1 - remove duplicate stringSize - update related comments - remove java.util.Digits - move java.util.Digits/HexDigits to jdk.internal.util.Digits/HexDigits - move java.util.OctalDigits to jdk.internal.util.OctalDigits - none static import - ... and 2 more: https://git.openjdk.org/jdk/compare/d06a5643...9b9eeb2d ------------- Changes: https://git.openjdk.org/jdk/pull/15651/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=08 Stats: 692 lines in 15 files changed: 313 ins; 352 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 15:57:22 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 15:57:22 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v10] In-Reply-To: References: Message-ID: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com> > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: revert code format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/9b9eeb2d..2b909d96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=08-09 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 16:00:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 16:00:42 GMT Subject: RFR: 8315999: Improve Date toString performance [v2] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 14:44:24 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > fix LocalDate.getChars offset # benchmark script ## 1. Script bash configure make images sh make/devkit/createJMHBundle.sh bash configure --with-jmh=build/jmh/jars make test TEST="micro:java.time.ToStringBench.* ## 2. MacBookPro M1 Pro Benchmark ``` diff -Benchmark Mode Cnt Score Error Units (baseline) -ToStringBench.testInstantToString thrpt 15 3.900 ? 0.289 ops/ms -ToStringBench.testLocalDateTimeToString thrpt 15 11.081 ? 0.141 ops/ms -ToStringBench.testLocalDateToString thrpt 15 18.566 ? 1.852 ops/ms -ToStringBench.testLocalTimeToString thrpt 15 8.428 ? 1.066 ops/ms -ToStringBench.testZoneOffsetOffHours thrpt 15 115.342 ? 13.978 ops/ms -ToStringBench.testZonedDateTimeToString thrpt 15 4.669 ? 1.986 ops/ms +Benchmark Mode Cnt Score Error Units (PR cc82e8c1) +ToStringBench.testInstantToString thrpt 15 47.971 ? 0.131 ops/ms (+1130.02%) +ToStringBench.testLocalDateTimeToString thrpt 15 71.310 ? 0.633 ops/ms (+543.53%) +ToStringBench.testLocalDateToString thrpt 15 108.236 ? 1.613 ops/ms (+482.97%) +ToStringBench.testLocalTimeToString thrpt 15 128.264 ? 1.052 ops/ms (+1421.87%) +ToStringBench.testZoneOffsetOffHours thrpt 15 694.463 ? 2.671 ops/ms (+502.29%) +ToStringBench.testZonedDateTimeToString thrpt 15 46.975 ? 0.850 ops/ms (+906.10%) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1714168168 From duke at openjdk.org Mon Sep 11 16:15:40 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 16:15:40 GMT Subject: RFR: 8315999: Improve Date toString performance [v2] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 14:42:33 GMT, Claes Redestad wrote: >> this place doesn't need off++ > > It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)` from line 2188. The reason for not using off++ is that it can be executed out of order, which may result in better performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321781354 From duke at openjdk.org Mon Sep 11 16:36:25 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 16:36:25 GMT Subject: RFR: 8315999: Improve Date toString performance [v3] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? 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 four additional commits since the last revision: - base PR #15651 API - Merge remote-tracking branch 'origin/reduce_duplicate' into optim_for_date_to_string_2 - fix LocalDate.getChars offset - improve date toString performance, includes: java.util.Date.toString java.util.Date.toGMTString java.time.Instant.toString java.time.LocalDate.toString java.time.LocalDateTime.toString java.time.LocalTime.toString ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/24adeb70..ef500237 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=01-02 Stats: 2901 lines in 74 files changed: 1701 ins; 585 del; 615 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Mon Sep 11 16:40:44 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 16:40:44 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v7] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 14:28:28 GMT, Chen Liang wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1 > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143: > >> 141: * code after loop unrolling. >> 142: */ >> 143: public static int stringSize(int x) { > > I suggest splitting the moves of `stringSize` `getChars` into a new PR dependent on this one; your future date and time optimizations can depend on that one, which exposes stringSize. > > Having the DecimalDigits package move and `stringSize` `getChars` moves together complicates the file changes, and it's hard to detect if there's any accidental typo/malicious code in the new additions. If this PR is split into two PRs, the other two PRs I submitted #15658 #15555 cannot be based on this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321809367 From redestad at openjdk.org Mon Sep 11 18:59:46 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 11 Sep 2023 18:59:46 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v10] In-Reply-To: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com> References: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com> Message-ID: On Mon, 11 Sep 2023 15:57:22 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > revert code format src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 37: > 35: * @since 21 > 36: */ > 37: public final class OctalDigits implements Digits { Can you restore the order of methods here to minimize the number of lines of code are touched? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321956051 From duke at openjdk.org Mon Sep 11 19:01:29 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 11 Sep 2023 19:01:29 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v2] In-Reply-To: References: Message-ID: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Changed KEYSTORE_TYPE spec to indicate pkcs12 default ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15625/files - new: https://git.openjdk.org/jdk/pull/15625/files/74573641..23c357be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15625/head:pull/15625 PR: https://git.openjdk.org/jdk/pull/15625 From rriggs at openjdk.org Mon Sep 11 19:03:42 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 11 Sep 2023 19:03:42 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v10] In-Reply-To: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com> References: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com> Message-ID: On Mon, 11 Sep 2023 15:57:22 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > revert code format Changes requested by rriggs (Reviewer). src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1: > 1: /* Can git be convinced to show this as a rename instead of a delete and add? The history will be cleaner. src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 41: > 39: * Singleton instance of OctalDigits. > 40: */ > 41: public static final Digits INSTANCE = new OctalDigits(); The constructor should be after the field definitions. Don't let some tool reformat the code and move things around. ------------- PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1620644060 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321958613 PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321960820 From rriggs at openjdk.org Mon Sep 11 19:03:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 11 Sep 2023 19:03:44 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v7] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 16:36:55 GMT, ??? wrote: >> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143: >> >>> 141: * code after loop unrolling. >>> 142: */ >>> 143: public static int stringSize(int x) { >> >> I suggest splitting the moves of `stringSize` `getChars` into a new PR dependent on this one; your future date and time optimizations can depend on that one, which exposes stringSize. >> >> Having the DecimalDigits package move and `stringSize` `getChars` moves together complicates the file changes, and it's hard to detect if there's any accidental typo/malicious code in the new additions. > > If this PR is split into two PRs, the other two PRs I submitted #15658 #15555 cannot be based on this PR. I agree, do the package move separate from the refactoring. The other PRs can wait a bit or be committed as is and take part in the refactoring later. One step at a time please. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321957533 From redestad at openjdk.org Mon Sep 11 19:06:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 11 Sep 2023 19:06:42 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v10] In-Reply-To: References: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com> Message-ID: <_-7S7GhHC7J1aoj_lSPIULTtjhr2RdHsssbMnbHe4Wo=.0ffc1dc5-abee-42c9-a1cd-71b5637ed72a@github.com> On Mon, 11 Sep 2023 18:58:56 GMT, Roger Riggs wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> revert code format > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1: > >> 1: /* > > Can git be convinced to show this as a rename instead of a delete and add? > The history will be cleaner. I just looked it up and git actually doesn't have commands for renames like hg, but rather decides if something is a delete+add or a rename based on the amount of changes. Too many changes and it'll automatically look like a remove+add. Which is yet another argument for splitting up this in multiple PRs. One to move, one to refactor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321963536 From duke at openjdk.org Mon Sep 11 22:59:23 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 22:59:23 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v11] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with three additional commits since the last revision: - revert stringSize refactor - revert stringSize refactor - restore the order of OctalDigits methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/2b909d96..9bf9f787 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=09-10 Stats: 212 lines in 8 files changed: 108 ins; 83 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 23:05:08 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 23:05:08 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v12] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: DecimalDigits revert some changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/9bf9f787..196a3393 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=10-11 Stats: 26 lines in 1 file changed: 9 ins; 2 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 23:08:14 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 23:08:14 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v13] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: DecimalDigits revert some changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/196a3393..03952930 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=11-12 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 23:27:12 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 23:27:12 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v14] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: rebase & resolve DecimalDigits delete and add ------------- Changes: https://git.openjdk.org/jdk/pull/15651/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=13 Stats: 577 lines in 13 files changed: 274 ins; 279 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Mon Sep 11 23:34:41 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 23:34:41 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v10] In-Reply-To: <_-7S7GhHC7J1aoj_lSPIULTtjhr2RdHsssbMnbHe4Wo=.0ffc1dc5-abee-42c9-a1cd-71b5637ed72a@github.com> References: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com> <_-7S7GhHC7J1aoj_lSPIULTtjhr2RdHsssbMnbHe4Wo=.0ffc1dc5-abee-42c9-a1cd-71b5637ed72a@github.com> Message-ID: On Mon, 11 Sep 2023 19:03:45 GMT, Claes Redestad wrote: >> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1: >> >>> 1: /* >> >> Can git be convinced to show this as a rename instead of a delete and add? >> The history will be cleaner. > > I just looked it up and git actually doesn't have commands for renames like hg, but rather decides if something is a delete+add or a rename based on the amount of changes. Too many changes and it'll automatically look like a remove+add. > > Which is yet another argument for splitting up this in multiple PRs. One to move, one to refactor. Refactoring of stringSize has been restored, But the problem of 'delete & add' is still not solved, I tried rebase but it couldn't be solved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1322178111 From duke at openjdk.org Mon Sep 11 23:34:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 23:34:42 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v7] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 18:57:58 GMT, Roger Riggs wrote: >> If this PR is split into two PRs, the other two PRs I submitted #15658 #15555 cannot be based on this PR. > > I agree, do the package move separate from the refactoring. > The other PRs can wait a bit or be committed as is and take part in the refactoring later. > One step at a time please. Refactoring of stringSize has been restored ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1322178873 From serb at openjdk.org Mon Sep 11 23:49:08 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 11 Sep 2023 23:49:08 GMT Subject: RFR: 8316057: javax/crypto/CryptoPermissions/InconsistentEntries.java fails on read-only JDK Message-ID: I am not sure that it is a good thing to modify the JDK when many tests are executed in parallel. But for now, I updated the test, it will be skipped if the setup stage fails. ------------- Commit messages: - 8316057: javax/crypto/CryptoPermissions/InconsistentEntries.java fails on read-only JDK Changes: https://git.openjdk.org/jdk/pull/15674/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15674&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316057 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15674/head:pull/15674 PR: https://git.openjdk.org/jdk/pull/15674 From duke at openjdk.org Mon Sep 11 23:50:44 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 11 Sep 2023 23:50:44 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v15] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? 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: - use StringLatin1.PACKED_DIGITS and add getCharsLatin1 - rebase & resolve DecimalDigits delete and add ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/6cc34bed..70bf2297 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=13-14 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Tue Sep 12 00:00:24 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 00:00:24 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v16] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? 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 one new commit since the last revision: rebase & resolve DecimalDigits delete and add ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/70bf2297..9bccc890 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=14-15 Stats: 282 lines in 7 files changed: 145 ins; 123 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Tue Sep 12 00:06:41 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 00:06:41 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v17] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? 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 one new commit since the last revision: rebase & resolve DecimalDigits delete and add ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/9bccc890..27174f45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=15-16 Stats: 52 lines in 3 files changed: 11 ins; 35 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From liach at openjdk.org Tue Sep 12 00:52:52 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 12 Sep 2023 00:52:52 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v17] In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 00:06:41 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? 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 one new commit since the last revision: > > rebase & resolve DecimalDigits delete and add Marked as reviewed by liach (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1621068014 From duke at openjdk.org Tue Sep 12 01:00:39 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 01:00:39 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v18] In-Reply-To: References: Message-ID: > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: little-endian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/27174f45..93ed81da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=16-17 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Tue Sep 12 01:23:26 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 01:23:26 GMT Subject: RFR: 8315999: Improve Date toString performance [v4] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - rebase PR #15651 last version - base PR #15651 API - move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1 - remove duplicate stringSize - update related comments - none static import - move java.util.DecimalDigits to jdk.internal.util.DecimalDigits - fix LocalDate.getChars offset - improve date toString performance, includes: java.util.Date.toString java.util.Date.toGMTString java.time.Instant.toString java.time.LocalDate.toString java.time.LocalDateTime.toString java.time.LocalTime.toString ------------- Changes: https://git.openjdk.org/jdk/pull/15658/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=03 Stats: 766 lines in 17 files changed: 626 ins; 54 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Tue Sep 12 01:31:31 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 01:31:31 GMT Subject: RFR: 8315999: Improve Date toString performance [v5] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with two additional commits since the last revision: - revert un-related changes - revert un-related changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/b26cb857..2a617db5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=03-04 Stats: 79 lines in 5 files changed: 36 ins; 40 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Tue Sep 12 01:36:10 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 01:36:10 GMT Subject: RFR: 8315999: Improve Date toString performance [v6] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with one additional commit since the last revision: revert un-related changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/2a617db5..26d7c7c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=04-05 Stats: 14 lines in 1 file changed: 11 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From redestad at openjdk.org Tue Sep 12 10:14:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 12 Sep 2023 10:14:42 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v18] In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 01:00:39 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > little-endian Running some additional testing. This mostly looks fine. One issue is that you're swapping the byte-order in `DecimalDigits::DIGITS` but not in `OctalDigits` and `HexDigits`. I think we need to keep these internally consistent to avoid surprises. I also would like to see performance numbers of the byte order swap evaluated in isolation. I suspect the real effect is small and might be due to JIT noise rather than a real effect, and that this swap got rushed in without solid evidence that it helps. If there's no significant performance difference I would prefer if we kept `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most - and adjust code depending on `DecimalDigits::digitPair` to use `ByteArray` rather than `ByteArrayLittleEndian`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715419335 From redestad at openjdk.org Tue Sep 12 10:45:53 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 12 Sep 2023 10:45:53 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v18] In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 10:11:53 GMT, Claes Redestad wrote: > If there's no significant performance difference I would prefer if we kept `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most - and adjust code depending on `DecimalDigits::digitPair` to use `ByteArray` rather than `ByteArrayLittleEndian`. Just a datapoint but when I test implementing `HexFormat::toHexDigits` using either `ByteArray` or `ByteArrayLittleEndian` then the difference is in the noise: Name Cnt Base Error Test Error Unit Diff% HexFormatBench.toHexDigitsLong 15 1,950 ? 0,012 1,941 ? 0,016 us/op 0,5% (p = 0,081 ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715482633 From shade at openjdk.org Tue Sep 12 11:55:41 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 12 Sep 2023 11:55:41 GMT Subject: RFR: 8316057: javax/crypto/CryptoPermissions/InconsistentEntries.java fails on read-only JDK In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 23:20:04 GMT, Sergey Bylokhov wrote: > I am not sure that it is a good thing to modify the JDK when many tests are executed in parallel. But for now, I updated the test, it will be skipped if the setup stage fails. Whoa. Is this test running by default? I guess we are saved by the fact `POLICY_DIR` is in separate directory, so this probably does not affect other tests. But I agree, it is risky to modify tested JDK. Sean makes a [comment here](https://bugs.openjdk.org/browse/JDK-8286779?focusedCommentId=14520807#comment-14520807) about rewriting the test like this one: [java/security/Security/ConfigFileTest.java](https://github.com/openjdk/jdk/blob/8b4f9a88e606c4c6722061ce9946ce17340ff1df/test/jdk/java/security/Security/ConfigFileTest.java) -- is it easy enough to do here? ------------- PR Review: https://git.openjdk.org/jdk/pull/15674#pullrequestreview-1622063971 From duke at openjdk.org Tue Sep 12 13:05:19 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 13:05:19 GMT Subject: RFR: 8315999: Improve Date toString performance [v7] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with two additional commits since the last revision: - improved DateTimeFormatter.format - improved ISO_INSTANT format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/26d7c7c0..8b3f0637 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=05-06 Stats: 459 lines in 6 files changed: 393 ins; 44 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Tue Sep 12 13:13:43 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 13:13:43 GMT Subject: RFR: 8315999: Improve Date toString performance [v7] In-Reply-To: <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com> <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com> Message-ID: On Mon, 11 Sep 2023 14:59:25 GMT, ??? wrote: >> The performance of optimizing DateTimeFormatter cannot be as fast as using ixed-length buffer directly. > > Of course, the optimization of DateTimeFormatter is more general, and we can spend time doing it later. The format of toString is fixed, we can not use DateTimeFormatter. > Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? > > Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications. I submitted an optimization for the commonly used format of DateTimeFormatter::format ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323021409 From duke at openjdk.org Tue Sep 12 13:27:29 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 13:27:29 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v19] In-Reply-To: References: Message-ID: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> > Some codes in core libs are duplicated, including: > java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS > java.util.DecimalDigits::size -> java.lang.Long.stringSize > > We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: > https://github.com/openjdk/jdk/pull/15555 ??? has updated the pull request incrementally with one additional commit since the last revision: little-endian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15651/files - new: https://git.openjdk.org/jdk/pull/15651/files/93ed81da..c68c4e81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=17-18 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651 PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Tue Sep 12 13:27:53 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 13:27:53 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v18] In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 10:11:53 GMT, Claes Redestad wrote: > Running some additional testing. This mostly looks fine. > > One issue is that you're swapping the byte-order in `DecimalDigits::DIGITS` but not in `OctalDigits` and `HexDigits`. I think we need to keep these internally consistent to avoid surprises. > > I also would like to see performance numbers of the byte order swap evaluated in isolation. I suspect the real effect is small and might be due to JIT noise rather than a real effect, and that this swap got rushed in without solid evidence that it helps. > > If there's no significant performance difference I would prefer if we kept `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most - and adjust code depending on `DecimalDigits::digitPair` to use `ByteArray` rather than `ByteArrayLittleEndian`. I prefer to use little endian, most environments are little endian. Changes to HexDigit will have to wait until #PR 14745 is merged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715721750 From rriggs at openjdk.org Tue Sep 12 13:51:40 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Sep 2023 13:51:40 GMT Subject: RFR: 8315968: Consolidate java.util.Digits and StringLatin1::PACKED_DIGITS [v19] In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> References: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> Message-ID: <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com> On Tue, 12 Sep 2023 13:27:29 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > little-endian Please update this PR title and description to indicate this refactoring to move to jdk.internal.util. I can update the Jira title and description to match after that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715764494 From rriggs at openjdk.org Tue Sep 12 13:57:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Sep 2023 13:57:44 GMT Subject: RFR: 8315999: Improve Date toString performance [v7] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Tue, 12 Sep 2023 13:05:19 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with two additional commits since the last revision: > > - improved DateTimeFormatter.format > - improved ISO_INSTANT format You haven't make the case for these changes, please describe the use cases when performance is a significant constraint on application performance. The changes largely just add more code to maintain without otherwise adding sufficient value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1715774423 From duke at openjdk.org Tue Sep 12 14:15:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 14:15:42 GMT Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication [v19] In-Reply-To: <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com> References: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com> Message-ID: On Tue, 12 Sep 2023 13:49:09 GMT, Roger Riggs wrote: > Please update this PR title and description to indicate this refactoring to move to jdk.internal.util. I can update the Jira title and description to match after that. The title has been updated, please help update the title of JIRA ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715808794 From rriggs at openjdk.org Tue Sep 12 14:19:41 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Sep 2023 14:19:41 GMT Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication [v19] In-Reply-To: References: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com> Message-ID: On Tue, 12 Sep 2023 14:13:06 GMT, ??? wrote: > The title has been updated, please help update the title of JIRA The description needs an update too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715814638 From liach at openjdk.org Tue Sep 12 14:27:44 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 12 Sep 2023 14:27:44 GMT Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication [v19] In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> References: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> Message-ID: On Tue, 12 Sep 2023 13:27:29 GMT, ??? wrote: >> Some codes in core libs are duplicated, including: >> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS >> java.util.DecimalDigits::size -> java.lang.Long.stringSize >> >> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as: >> https://github.com/openjdk/jdk/pull/15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > little-endian I have updated the JBS bug title and explicitly stated the actions in this patch: 1. Move Digits to jdk.internal.util 2. Keep the tables in DecimalDigits and access via a new digitPair static method 3. Change the DecimalDigits' table to be LE (instead of BE) and update implementation ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715829791 From duke at openjdk.org Tue Sep 12 14:33:44 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 14:33:44 GMT Subject: RFR: 8315999: Improve Date toString performance [v7] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Tue, 12 Sep 2023 13:54:34 GMT, Roger Riggs wrote: > You haven't make the case for these changes, please describe the use cases when performance is a significant constraint on application performance. The changes largely just add more code to maintain without otherwise adding sufficient value. Many scenarios require this optimization, such as: 1. The open source project [datax](https://github.com/alibaba/datax) is a data integration engine we maintain. When the input is a Date but the target type is String, the Date must be converted to String. In the flame graph below, commons-lang's FastDateFormat::format method consumes most of the time. It will be similar if replaced by DateTimeFormatter::format. ![image](https://github.com/openjdk/jdk/assets/1166785/1063aacf-c770-4c2d-9920-297be65ac6b0) 2. JSON libraries such as gson/jackson/fastjson need to convert Date/Instant into String, and format/toString usually takes up a relatively large proportion of time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1715842265 From duke at openjdk.org Tue Sep 12 14:54:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 14:54:42 GMT Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication [v19] In-Reply-To: References: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com> Message-ID: <6T9e81P8e5rZ-n_QQZWs82MKWeC2PxxXjONvN377Un8=.155a3fe0-b325-49be-81cf-256473b8413d@github.com> On Tue, 12 Sep 2023 14:16:27 GMT, Roger Riggs wrote: > > The title has been updated, please help update the title of JIRA > > The description needs an update too. The description has also been updated ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715880514 From redestad at openjdk.org Tue Sep 12 15:35:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 12 Sep 2023 15:35:41 GMT Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication [v18] In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 13:24:56 GMT, ??? wrote: > I prefer to use little endian, most environments are little endian. Changes to HexDigit will have to wait until #PR 14745 is merged. I don't have a very strong opinion except that we should be consistent across these related implementations. If you could either include `OctalDigits` changes in #14745 or prepare a separate PR for it I'm OK with this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715954790 From redestad at openjdk.org Tue Sep 12 15:58:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 12 Sep 2023 15:58:42 GMT Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication [v19] In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> References: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> Message-ID: On Tue, 12 Sep 2023 13:27:29 GMT, ??? wrote: >> java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are duplicates, We need to move java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the jdk.internal.util package, and modify these classes to public class, so that classes in other packages can also access them. >> >> DecimalDigits::DIGITS provides a new digitPair static method, used to replace StringLatin1.PACKED_DIGITS access. >> >> In order to be consistent with the original StringLatin1.PACKED_DIGITS, OctalDigits::DIGITS and DecimalDigits::DIGITS are modified to little-endian. HexDigits::DIGITS will also be modified after PR #14745 is merged. >> >> These changes will be used by PR #15658 #15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > little-endian Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1622597772 From rriggs at openjdk.org Tue Sep 12 16:06:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Sep 2023 16:06:43 GMT Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication [v19] In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> References: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com> Message-ID: On Tue, 12 Sep 2023 13:27:29 GMT, ??? wrote: >> java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are duplicates, We need to move java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the jdk.internal.util package, and modify these classes to public class, so that classes in other packages can also access them. >> >> DecimalDigits::DIGITS provides a new digitPair static method, used to replace StringLatin1.PACKED_DIGITS access. >> >> In order to be consistent with the original StringLatin1.PACKED_DIGITS, OctalDigits::DIGITS and DecimalDigits::DIGITS are modified to little-endian. HexDigits::DIGITS will also be modified after PR #14745 is merged. >> >> These changes will be used by PR #15658 #15555 > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > little-endian Thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1622614379 From duke at openjdk.org Tue Sep 12 16:38:00 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 16:38:00 GMT Subject: Integrated: 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication In-Reply-To: References: Message-ID: On Sun, 10 Sep 2023 16:15:01 GMT, ??? wrote: > java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are duplicates, We need to move java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the jdk.internal.util package, and modify these classes to public class, so that classes in other packages can also access them. > > DecimalDigits::DIGITS provides a new digitPair static method, used to replace StringLatin1.PACKED_DIGITS access. > > In order to be consistent with the original StringLatin1.PACKED_DIGITS, OctalDigits::DIGITS and DecimalDigits::DIGITS are modified to little-endian. HexDigits::DIGITS will also be modified after PR #14745 is merged. > > These changes will be used by PR #15658 #15555 This pull request has now been integrated. Changeset: e0845163 Author: shaojin.wensj Committer: Claes Redestad URL: https://git.openjdk.org/jdk/commit/e0845163aa57cc8f68b11e1a553885676358f2a6 Stats: 530 lines in 10 files changed: 257 ins; 260 del; 13 mod 8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication Reviewed-by: rriggs, liach, redestad ------------- PR: https://git.openjdk.org/jdk/pull/15651 From duke at openjdk.org Tue Sep 12 17:17:23 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 17:17:23 GMT Subject: RFR: 8315999: Improve Date toString performance [v8] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? 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 18 additional commits since the last revision: - merge from master & revert DateTimeFormatterBuilder - Merge branch 'master' into optim_for_date_to_string_2 # Conflicts: # src/java.base/share/classes/java/lang/StringUTF16.java # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java - improved DateTimeFormatter.format - improved ISO_INSTANT format - revert un-related changes - revert un-related changes - revert un-related changes - rebase PR #15651 last version - base PR #15651 API - move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1 - ... and 8 more: https://git.openjdk.org/jdk/compare/1cd96ce2...9040ea0c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/8b3f0637..9040ea0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=06-07 Stats: 1245 lines in 45 files changed: 528 ins; 609 del; 108 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Tue Sep 12 17:23:00 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 12 Sep 2023 17:23:00 GMT Subject: RFR: 8315999: Improve Date toString performance [v9] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com> > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with one additional commit since the last revision: merge from master ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/9040ea0c..e4c5b67b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=07-08 Stats: 100 lines in 1 file changed: 100 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Tue Sep 12 18:01:50 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 12 Sep 2023 18:01:50 GMT Subject: RFR: 8315999: Improve Date toString performance [v9] In-Reply-To: <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com> Message-ID: On Tue, 12 Sep 2023 17:23:00 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > merge from master `LocalTime::getNanoChars(byte[],?int,?int)` can?use `DecimalDigits::digitTriple(int)` instead?of a?local?copy of?`DecimalDigits.DIGITS_K`: src/java.base/share/classes/java/time/LocalTime.java line 141: > 139: @Stable > 140: static final int[] DIGITS_K = new int[1000]; > 141: Suggestion: src/java.base/share/classes/java/time/LocalTime.java line 179: > 177: int c3 = i % 10 + '0'; > 178: DIGITS_K[i] = c0 + (c1 << 8) + (c2 << 16) + (c3 << 24); > 179: } Suggestion: src/java.base/share/classes/java/time/LocalTime.java line 1710: > 1708: buf, > 1709: off, > 1710: DIGITS_K[div2] & 0xffffff00 | '.' Suggestion: DecimalDigits.digitTriple(div2) & 0xffffff00 | '.' src/java.base/share/classes/java/time/LocalTime.java line 1722: > 1720: } > 1721: > 1722: v = DIGITS_K[rem2]; Suggestion: v = DecimalDigits.digitTriple(rem2); src/java.base/share/classes/java/time/LocalTime.java line 1724: > 1722: v = DIGITS_K[rem2]; > 1723: } else { > 1724: v = DIGITS_K[div - div2 * 1000]; Suggestion: v = DecimalDigits.digitTriple(div - div2 * 1000); src/java.base/share/classes/java/time/LocalTime.java line 1740: > 1738: buf, > 1739: off, > 1740: DIGITS_K[rem1] & 0xffffff00 | (v >> 24) Suggestion: DecimalDigits.digitTriple(rem1) & 0xffffff00 | (v >> 24) ------------- PR Review: https://git.openjdk.org/jdk/pull/15658#pullrequestreview-1622831447 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323381033 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323381182 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323379816 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323380364 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323380525 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323380651 From erikj at openjdk.org Tue Sep 12 20:18:51 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 12 Sep 2023 20:18:51 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Thanks for reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1716362585 From erikj at openjdk.org Tue Sep 12 20:18:52 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 12 Sep 2023 20:18:52 GMT Subject: Integrated: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: <0l5wbPPACAFDpuzCNnCNkr_RJ35CFXxPC9EpiVFt_Ao=.fbfbc877-43fd-4706-9d0d-bace4d004632@github.com> On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. This pull request has now been integrated. Changeset: 020255a7 Author: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/020255a72dc374ba0bdd44772047f14a8bfe69a9 Stats: 1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod 8267174: Many test files have the wrong Copyright header Reviewed-by: valeriep, aivanov, iris, dholmes, ihse ------------- PR: https://git.openjdk.org/jdk/pull/15573 From jlu at openjdk.org Tue Sep 12 22:04:12 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 12 Sep 2023 22:04:12 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native Message-ID: JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). ------------- Commit messages: - Update header / copyright for CurrencyFormat - Adjust CurrencyFormat test to read in .properties with UTF-8 - Convert unicode escape sequences to native - Add clarifying comment in Bug6204853 for lack of conversion - Read JDK properties files in UTF-8 during build process for LRB Changes: https://git.openjdk.org/jdk/pull/15694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 28966 lines in 488 files changed: 14 ins; 0 del; 28952 mod Patch: https://git.openjdk.org/jdk/pull/15694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694 PR: https://git.openjdk.org/jdk/pull/15694 From redestad at openjdk.org Tue Sep 12 22:56:49 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 12 Sep 2023 22:56:49 GMT Subject: RFR: 8315999: Improve Date toString performance [v9] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Mon, 11 Sep 2023 16:13:01 GMT, ??? wrote: >> It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)` from line 2188. > > The reason for not using off++ is that it can be executed out of order, which may result in better performance. I don't think that would outweigh the extra branch and the increased code size. I'd opt for simplicity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323687644 From liach at openjdk.org Tue Sep 12 23:16:40 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 12 Sep 2023 23:16:40 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu wrote: > JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 227: > 225: try (FileInputStream input = new FileInputStream(propertiesPath); > 226: // Read in JDK .properties files in UTF-8 > 227: InputStreamReader streamReader = new InputStreamReader(input, StandardCharsets.UTF_8) Can we just uses `Files.newBufferedReader(Path.of(propertiesPath))` instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1323716978 From redestad at openjdk.org Tue Sep 12 23:37:43 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 12 Sep 2023 23:37:43 GMT Subject: RFR: 8315999: Improve Date toString performance [v9] In-Reply-To: <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com> Message-ID: On Tue, 12 Sep 2023 17:23:00 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > merge from master I think there's still too much going on in this PR, and it should probably be split up into multiple PRs. I think some of this is going a bit overboard. For starters I don't want to see us adding a 1000-element lookup table for "`DecimalDigits::digitTriple`" without significant evidence that that is worth it at application level. As has been pointed out elsewhere lookup tables are prone to look great on microbenchmarks but may behave poorly and even regress real world applications by competing for cache. Any further additions needs to be justified with a thorough examination and benchmarks that better simulate noisy real world applications. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 77: > 75: > 76: static { > 77: int[] digits_k = new int[1000]; I'm very skeptical that adding a 1000 element lookup table for is worthwhile. That's a lookup table that'd span many cache lines, with plenty of cache misses. And even _if_ it is to be considered it should be split out and considered in isolation from this PR. What does the 2, 1 or 0 value you put in the lowest byte signify? ------------- Changes requested by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15658#pullrequestreview-1623337467 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323702300 From redestad at openjdk.org Tue Sep 12 23:37:45 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 12 Sep 2023 23:37:45 GMT Subject: RFR: 8315999: Improve Date toString performance [v9] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com> <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com> Message-ID: <_59sQtS1Sb6t7Gypojek3b1O4KbFTmeNuE84GULI4Go=.cbe5946a-c43a-49bf-946d-5ed4600f08b6@github.com> On Tue, 12 Sep 2023 13:10:42 GMT, ??? wrote: >> Of course, the optimization of DateTimeFormatter is more general, and we can spend time doing it later. The format of toString is fixed, we can not use DateTimeFormatter. > >> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? >> >> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications. > > I submitted an optimization for the commonly used format of DateTimeFormatter::format Do you have a link to that PR? Is there an RFE filed for it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323705970 From valeriep at openjdk.org Wed Sep 13 00:15:36 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 13 Sep 2023 00:15:36 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 19:41:47 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8296631 I will take a look. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15644#issuecomment-1716746989 From duke at openjdk.org Wed Sep 13 01:15:38 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 01:15:38 GMT Subject: RFR: 8315999: Improve Date toString performance [v10] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with one additional commit since the last revision: remove DIGITS_K ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/e4c5b67b..8c76799c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=08-09 Stats: 59 lines in 2 files changed: 6 ins; 38 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Wed Sep 13 01:15:41 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 01:15:41 GMT Subject: RFR: 8315999: Improve Date toString performance [v9] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com> Message-ID: <-Hqle78z33az2yUm0LBqSYw_P7pisqWDt0afZc2xY_M=.97b412fd-f5f5-4032-9e65-9820a3963888@github.com> On Tue, 12 Sep 2023 23:08:25 GMT, Claes Redestad wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> merge from master > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 77: > >> 75: >> 76: static { >> 77: int[] digits_k = new int[1000]; > > I'm very skeptical that adding a 1000 element lookup table for is worthwhile. That's a lookup table that'd span many cache lines, with plenty of cache misses. And even _if_ it is to be considered it should be split out and considered in isolation from this PR. > > What does the 2, 1 or 0 value you put in the lowest byte signify? DIGITS_K has been removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323808508 From duke at openjdk.org Wed Sep 13 01:19:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 01:19:42 GMT Subject: RFR: 8315999: Improve Date toString performance [v10] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: <4D-jfiuQtZ_VtVl1kzOT7W8XbwymgugJZQb58L54riY=.60f8ba07-2981-4422-8f26-64696b2bdbeb@github.com> On Wed, 13 Sep 2023 01:15:38 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > remove DIGITS_K > Do you have a link to that PR? Is there an RFE filed for it? @cl4es Optimization of DateTimeFormatter::format should be another PR, I created a [branche](https://github.com/wenshao/jdk/tree/optim_for_datetime_format) but the work is unfinished. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1716790719 From duke at openjdk.org Wed Sep 13 01:19:46 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 01:19:46 GMT Subject: RFR: 8315999: Improve Date toString performance [v9] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com> Message-ID: On Tue, 12 Sep 2023 17:53:47 GMT, ExE Boss wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> merge from master > > src/java.base/share/classes/java/time/LocalTime.java line 141: > >> 139: @Stable >> 140: static final int[] DIGITS_K = new int[1000]; >> 141: > > Suggestion: DIGITS_K has been removed > src/java.base/share/classes/java/time/LocalTime.java line 179: > >> 177: int c3 = i % 10 + '0'; >> 178: DIGITS_K[i] = c0 + (c1 << 8) + (c2 << 16) + (c3 << 24); >> 179: } > > Suggestion: DIGITS_K has been removed > src/java.base/share/classes/java/time/LocalTime.java line 1724: > >> 1722: v = DIGITS_K[rem2]; >> 1723: } else { >> 1724: v = DIGITS_K[div - div2 * 1000]; > > Suggestion: > > v = DecimalDigits.digitTriple(div - div2 * 1000); DIGITS_K has been removed > src/java.base/share/classes/java/time/LocalTime.java line 1740: > >> 1738: buf, >> 1739: off, >> 1740: DIGITS_K[rem1] & 0xffffff00 | (v >> 24) > > Suggestion: > > DecimalDigits.digitTriple(rem1) & 0xffffff00 | (v >> 24) DIGITS_K has been removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811383 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811309 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811510 PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811428 From duke at openjdk.org Wed Sep 13 02:48:17 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 02:48:17 GMT Subject: RFR: 8315999: Improve Date toString performance [v11] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with one additional commit since the last revision: restore ZoneOffset::buildId, reduce changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/8c76799c..8471814c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=09-10 Stats: 36 lines in 1 file changed: 0 ins; 23 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Wed Sep 13 02:54:09 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 02:54:09 GMT Subject: RFR: 8315999: Improve Date toString performance [v12] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with two additional commits since the last revision: - restore ZoneOffset::buildId, reduce changes - restore ZoneOffset::buildId, reduce changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/8471814c..d3ad4906 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=10-11 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Wed Sep 13 02:54:09 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 02:54:09 GMT Subject: RFR: 8315999: Improve Date toString performance [v12] In-Reply-To: <_59sQtS1Sb6t7Gypojek3b1O4KbFTmeNuE84GULI4Go=.cbe5946a-c43a-49bf-946d-5ed4600f08b6@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com> <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com> <_59sQtS1Sb6t7Gypojek3b1O4KbFTmeNuE84GULI4Go=.cbe5946a-c43a-49bf-946d-5ed4600f08b6@github.com> Message-ID: On Tue, 12 Sep 2023 23:10:43 GMT, Claes Redestad wrote: >>> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? >>> >>> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications. >> >> I submitted an optimization for the commonly used format of DateTimeFormatter::format > > Do you have a link to that PR? Is there an RFE filed for it? Optimization of DateTimeFormatter::format should be another PR, I created a [branche](https://github.com/wenshao/jdk/tree/optim_for_datetime_format) but the work is unfinished. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323870413 From duke at openjdk.org Wed Sep 13 14:22:35 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 14:22:35 GMT Subject: RFR: 8315999: Improve Date toString performance [v13] In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: > improve date toString performance, includes: > > java.util.Date.toString > java.util.Date.toGMTString > java.time.Instant.toString > java.time.LocalDate.toString > java.time.LocalDateTime.toString > java.time.LocalTime.toString ??? has updated the pull request incrementally with one additional commit since the last revision: simplify LocalDate::getChars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15658/files - new: https://git.openjdk.org/jdk/pull/15658/files/d3ad4906..b7a3528c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=11-12 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658 PR: https://git.openjdk.org/jdk/pull/15658 From duke at openjdk.org Wed Sep 13 14:22:36 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 14:22:36 GMT Subject: RFR: 8315999: Improve Date toString performance [v13] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Tue, 12 Sep 2023 22:53:34 GMT, Claes Redestad wrote: >> The reason for not using off++ is that it can be executed out of order, which may result in better performance. > > I don't think that would outweigh the extra branch and the increased code size. I'd opt for simplicity. I've simplified LocalDate::getChars based on your suggestion ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1324587746 From jlu at openjdk.org Wed Sep 13 17:38:28 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 13 Sep 2023 17:38:28 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: > JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Replace InputStreamReader with BufferedReader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15694/files - new: https://git.openjdk.org/jdk/pull/15694/files/0f3698a5..ceb48bbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00-01 Stats: 18 lines in 2 files changed: 6 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694 PR: https://git.openjdk.org/jdk/pull/15694 From naoto at openjdk.org Wed Sep 13 18:14:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 13 Sep 2023 18:14:41 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. >> >> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. >> >> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) >> >> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. >> >> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Replace InputStreamReader with BufferedReader Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15694#pullrequestreview-1625154951 From duke at openjdk.org Wed Sep 13 18:14:49 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 13 Sep 2023 18:14:49 GMT Subject: RFR: 4964430: Missing IllegalStateException exception requirement for javax.crypto.Cipher.doFinal Message-ID: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap` ------------- Commit messages: - Updated IllegalStateException requirement in update, doFinal, wrap, and unwrap Changes: https://git.openjdk.org/jdk/pull/15727/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15727&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4964430 Stats: 27 lines in 1 file changed: 12 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15727/head:pull/15727 PR: https://git.openjdk.org/jdk/pull/15727 From jlu at openjdk.org Wed Sep 13 18:46:38 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 13 Sep 2023 18:46:38 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 18:12:15 GMT, Naoto Sato wrote: > Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion. Thanks for the review; (In addition to testing), I ran a script to verify only white space escape sequences exist in JDK .properties files. (Excluding escape sequences in test files that should remain as is for the purpose of the test) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-1718139807 From rriggs at openjdk.org Wed Sep 13 19:24:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Sep 2023 19:24:46 GMT Subject: RFR: 8315999: Improve Date toString performance [v13] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Wed, 13 Sep 2023 14:22:35 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > simplify LocalDate::getChars Based on the use cases cited, if your library needs specific performance improvements for specific formats, they should be done in that library. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718186604 From rriggs at openjdk.org Wed Sep 13 19:28:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Sep 2023 19:28:46 GMT Subject: RFR: 8315999: Improve Date toString performance [v13] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Wed, 13 Sep 2023 14:22:35 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > simplify LocalDate::getChars As a consideration to core-libs-dev readers, push commits when you are convinced are ready for review and you don't intend to make more changes. It will improve the signal to noise ratio. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718192179 From svkamath at openjdk.org Wed Sep 13 20:25:22 2023 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 13 Sep 2023 20:25:22 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2] In-Reply-To: References: Message-ID: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> > Hi All, > I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. > > Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: > > |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup > |-------------|------------|---------------|------------------|-----------| > |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 > full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 > small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 > small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 > full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 > full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 > small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 > small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 > full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 > small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 > small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 > full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 > full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 > small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 > small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 > full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 > small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 > small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 > full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 > full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 > small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 > small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 > full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 > small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 > small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 > full.AESGCMBench.decryptMultiPart | 65536 | 42649.816 | 47591.587 |1.11 > full.AESGCMBe... Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Removed isEncrypt boolean variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15410/files - new: https://git.openjdk.org/jdk/pull/15410/files/33b1d980..2727c199 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=00-01 Stats: 43 lines in 8 files changed: 0 ins; 10 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/15410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15410/head:pull/15410 PR: https://git.openjdk.org/jdk/pull/15410 From duke at openjdk.org Wed Sep 13 21:20:07 2023 From: duke at openjdk.org (Ian Myers) Date: Wed, 13 Sep 2023 21:20:07 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java Message-ID: sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. ------------- Commit messages: - Updated Copyright and remove excess new line - Parallelize sun/security/util/math/TestIntegerModuloP.java Changes: https://git.openjdk.org/jdk/pull/15618/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15618&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315684 Stats: 62 lines in 1 file changed: 60 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15618/head:pull/15618 PR: https://git.openjdk.org/jdk/pull/15618 From duke at openjdk.org Wed Sep 13 21:20:07 2023 From: duke at openjdk.org (Ian Myers) Date: Wed, 13 Sep 2023 21:20:07 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:28:15 GMT, Aleksey Shipilev wrote: >> sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. >> >> TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** >> TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** >> >> This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. > > test/jdk/sun/security/util/math/TestIntegerModuloP.java line 103: > >> 101: */ >> 102: >> 103: > > Excess new line. Updated with Copyright and removed the excess line. Please see latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15618#discussion_r1318622985 From shade at openjdk.org Wed Sep 13 21:20:07 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Sep 2023 21:20:07 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:23:01 GMT, Ian Myers wrote: > sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. > > TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** > TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** > > This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. Please go https://github.com/ianrichr/jdk/actions and enable testing for your personal fork. Then please update copyright in the file to: * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved. ...and push another commit here. This will trigger testing too. This looks fine. I suggested @ianrichr what to do for this RFE, so I would like someone else to take a look too. Hi @robilad, could you help us with OCA verification here a bit? Thanks! test/jdk/sun/security/util/math/TestIntegerModuloP.java line 103: > 101: */ > 102: > 103: Excess new line. ------------- PR Review: https://git.openjdk.org/jdk/pull/15618#pullrequestreview-1615439495 Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15618#pullrequestreview-1615484644 PR Comment: https://git.openjdk.org/jdk/pull/15618#issuecomment-1715606358 PR Review Comment: https://git.openjdk.org/jdk/pull/15618#discussion_r1318610805 From duke at openjdk.org Wed Sep 13 21:25:48 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 21:25:48 GMT Subject: RFR: 8315999: Improve Date toString performance [v13] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Wed, 13 Sep 2023 19:21:34 GMT, Roger Riggs wrote: > Based on the use cases cited, if your library needs specific performance improvements for specific formats, they should be done in that library. I already do this in [fastjson2](https://github.com/alibaba/fastjson2) for now, but more libraries would benefit if improved in jdk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718334638 From duke at openjdk.org Wed Sep 13 22:03:45 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 22:03:45 GMT Subject: RFR: 8315999: Improve Date toString performance [v13] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Wed, 13 Sep 2023 14:22:35 GMT, ??? wrote: >> improve date toString performance, includes: >> >> java.util.Date.toString >> java.util.Date.toGMTString >> java.time.Instant.toString >> java.time.LocalDate.toString >> java.time.LocalDateTime.toString >> java.time.LocalTime.toString > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > simplify LocalDate::getChars > As a consideration to core-libs-dev readers, push commits when you are convinced are ready for review and you don't intend to make more changes. It will improve the signal to noise ratio. Thanks > As a consideration to core-libs-dev readers, push commits when you are convinced are ready for review and you don't intend to make more changes. It will improve the signal to noise ratio. Thanks Sorry, I will make sure to do more preparation before submitting any PRs in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718372907 From duke at openjdk.org Wed Sep 13 22:37:46 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 13 Sep 2023 22:37:46 GMT Subject: RFR: 8315999: Improve Date toString performance [v13] In-Reply-To: References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com> Message-ID: On Wed, 13 Sep 2023 21:22:43 GMT, ??? wrote: > Based on the use cases cited, if your library needs specific performance improvements for specific formats, they should be done in that library. Not only JSON libraries, toString optimization of Date/Instant/LocalDateTime and other classes will benefit in many places, such as logging in business systems, etc. Instant bizTime = ...; LOG.log(Level.INFO, "bizDate {0}", bizTime); ------------- PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718401009 From sviswanathan at openjdk.org Wed Sep 13 23:16:40 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 13 Sep 2023 23:16:40 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2] In-Reply-To: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> References: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> Message-ID: On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: >> >> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup >> |-------------|------------|---------------|------------------|-----------| >> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 >> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 >> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 >> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 >> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 >> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 >> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 >> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 >> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 >> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 >> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 >> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 >> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 >> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 >> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 >> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 >> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 >> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 >> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 >> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 >> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 >> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 >> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 >> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 >> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 >> full.AES... > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Removed isEncrypt boolean variable src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 362: > 360: // AVX2 AES-GCM related functions > 361: void initial_blocks(XMMRegister ctr, Register rounds, Register key, Register len, > 362: Register in, Register out, Register ct, Register subkeyHtbl, Register pos); You could rename it to gcm_intial_blocks_avx2(). src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 365: > 363: void gfmul_avx2(XMMRegister GH, XMMRegister HK); > 364: void generateHtbl_8_block_avx2(Register htbl, Register rscratch); > 365: void ghash8_encrypt8_parallel(Register key, Register subkeyHtbl, XMMRegister ctr_blockx, XMMRegister aad_hashx, Rename to ghash8_encrypt8_parallel_avx2(). src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 367: > 365: void ghash8_encrypt8_parallel(Register key, Register subkeyHtbl, XMMRegister ctr_blockx, XMMRegister aad_hashx, > 366: Register in, Register out, Register ct, Register pos, bool out_order, Register rounds); > 367: void ghash_last_8(Register subkeyHtbl); Rename to ghash_last_8_avx2. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 185: > 183: if (VM_Version::supports_avx2()) { > 184: StubRoutines::_galoisCounterMode_AESCrypt = generate_avx2_galoisCounterMode_AESCrypt(); > 185: } This could be moved to line 192. src/hotspot/cpu/x86/stubRoutines_x86.hpp line 40: > 38: // AVX512 intrinsics add more code in 64-bit VM, > 39: // Windows have more code to save/restore registers > 40: _compiler_stubs_code_size = 30000 LP64_ONLY(+30000) WINDOWS_ONLY(+2000), Since the stub is for 64 bit, the LP64_ONLY part needs to increase and not the base. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325143256 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325143499 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325143801 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325145931 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325144430 From sviswanathan at openjdk.org Thu Sep 14 00:21:39 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 14 Sep 2023 00:21:39 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2] In-Reply-To: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> References: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> Message-ID: On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: >> >> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup >> |-------------|------------|---------------|------------------|-----------| >> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 >> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 >> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 >> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 >> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 >> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 >> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 >> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 >> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 >> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 >> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 >> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 >> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 >> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 >> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 >> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 >> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 >> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 >> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 >> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 >> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 >> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 >> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 >> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 >> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 >> full.AES... > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Removed isEncrypt boolean variable src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3399: > 3397: __ vpshufb(xmm6, xmm6, t5, Assembler::AVX_128bit); //perform a 16Byte swap > 3398: __ vpshufb(xmm7, xmm7, t5, Assembler::AVX_128bit); //perform a 16Byte swap > 3399: __ vpshufb(xmm8, xmm8, t5, Assembler::AVX_128bit); //perform a 16Byte swap This could be written in a loop: for (int rnum = 1; rnum <= 8; rnum++) { __ vpshufb(as_XMMRegister(rnum), as_XMMRegister(rnum), t5, Assembler::AVX_128bit); } Similar technique can be used in some places below. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4040: > 4038: __ aesenc(xmm6, t_key); > 4039: __ aesenc(xmm7, t_key); > 4040: __ aesenc(xmm8, t_key); This code is repeated multiple times so can be generated through a method like aesenc_step_avx2(t_key); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325200254 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1325180777 From duke at openjdk.org Thu Sep 14 02:21:13 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Thu, 14 Sep 2023 02:21:13 GMT Subject: RFR: 8316235: Optimization for DateTimeFormatter::format Message-ID: In many scenarios, DateTimeFormatter::format is a slower operation. For example, the following business scenarios 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings. 2. In data integration scenarios, for projects like [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required. This PR provides format performance optimization for commonly used date patterns. ISO_INSTANT ISO_LOCAL_TIME ISO_LOCAL_DATE ISO_LOCAL_DATETIME HH:mm:ss HH:mm:ss.SSS yyyy-MM-dd yyyy-MM-dd HH:mm:ss yyyy-MM-dd'T'HH:mm:ss yyyy-MM-dd HH:mm:ss.SSS yyyy-MM-dd'T'HH:mm:ss.SSS ------------- Commit messages: - fix format LocalTime/LocalDateTime use utc - fix format ZonedDateTime & OffsetDateTime & OffsetTime use utc - sealed class CompositePrinterParser - use Pattern Matching switch - remove LocalTimePrinterParser::format support Instant - optimization support pattern 'yyyy-MM-dd HH:mm:ss.SSS' - remove digit_k - optimize DateTimeFormatter::format - fix InstantPrinterParser miss nanos - remove TimeCompositePrinterParser, fix build error - ... and 1 more: https://git.openjdk.org/jdk/compare/e0845163...564ae18b Changes: https://git.openjdk.org/jdk/pull/15722/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15722&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316235 Stats: 418 lines in 6 files changed: 341 ins; 51 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/15722.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15722/head:pull/15722 PR: https://git.openjdk.org/jdk/pull/15722 From duke at openjdk.org Thu Sep 14 02:21:13 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Thu, 14 Sep 2023 02:21:13 GMT Subject: RFR: 8316235: Optimization for DateTimeFormatter::format In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 14:56:15 GMT, ??? wrote: > In many scenarios, DateTimeFormatter::format is a slower operation. > > For example, the following business scenarios > 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings. > 2. In data integration scenarios, for projects like [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required. > > This PR provides format performance optimization for commonly used date patterns. > > ISO_INSTANT > ISO_LOCAL_TIME > ISO_LOCAL_DATE > ISO_LOCAL_DATETIME > HH:mm:ss > HH:mm:ss.SSS > yyyy-MM-dd > yyyy-MM-dd HH:mm:ss > yyyy-MM-dd'T'HH:mm:ss > yyyy-MM-dd HH:mm:ss.SSS > yyyy-MM-dd'T'HH:mm:ss.SSS Performance comparison data is as follows: ## 1. Script bash configure make images sh make/devkit/createJMHBundle.sh bash configure --with-jmh=build/jmh/jars make test TEST="micro:java.time.format.DateTimeFormatterBench.*" ## 2. MacBookPro benchmark -Benchmark (pattern) Mode Cnt Score Error Units (baseline) -DateTimeFormatterBench.formatInstants HH:mm:ss thrpt 15 14.888 ? 0.109 ops/ms -DateTimeFormatterBench.formatInstants HH:mm:ss.SSS thrpt 15 10.132 ? 0.046 ops/ms -DateTimeFormatterBench.formatInstants yyyy-MM-dd'T'HH:mm:ss thrpt 15 8.993 ? 0.039 ops/ms -DateTimeFormatterBench.formatInstants yyyy-MM-dd'T'HH:mm:ss.SSS thrpt 15 7.400 ? 0.035 ops/ms -DateTimeFormatterBench.formatZonedDateTime HH:mm:ss thrpt 15 21.460 ? 0.056 ops/ms -DateTimeFormatterBench.formatZonedDateTime HH:mm:ss.SSS thrpt 15 14.439 ? 0.264 ops/ms -DateTimeFormatterBench.formatZonedDateTime yyyy-MM-dd'T'HH:mm:ss thrpt 15 12.742 ? 0.055 ops/ms -DateTimeFormatterBench.formatZonedDateTime yyyy-MM-dd'T'HH:mm:ss.SSS thrpt 15 9.059 ? 0.124 ops/ms +Benchmark (pattern) Mode Cnt Score Error Units (optimized) +DateTimeFormatterBench.formatInstants HH:mm:ss thrpt 15 28.082 ? 0.284 ops/ms (+88.62%) +DateTimeFormatterBench.formatInstants HH:mm:ss.SSS thrpt 15 25.483 ? 0.109 ops/ms (+151.51%) +DateTimeFormatterBench.formatInstants yyyy-MM-dd'T'HH:mm:ss thrpt 15 19.950 ? 0.444 ops/ms (+121.83%) +DateTimeFormatterBench.formatInstants yyyy-MM-dd'T'HH:mm:ss.SSS thrpt 15 18.391 ? 0.327 ops/ms (+148.52%) +DateTimeFormatterBench.formatZonedDateTime HH:mm:ss thrpt 15 57.870 ? 0.641 ops/ms (+169.66%) +DateTimeFormatterBench.formatZonedDateTime HH:mm:ss.SSS thrpt 15 43.783 ? 0.300 ops/ms (+203.22%) +DateTimeFormatterBench.formatZonedDateTime yyyy-MM-dd'T'HH:mm:ss thrpt 15 36.220 ? 0.194 ops/ms (+184.25%) +DateTimeFormatterBench.formatZonedDateTime yyyy-MM-dd'T'HH:mm:ss.SSS thrpt 15 32.512 ? 0.583 ops/ms (+258.89%) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15722#issuecomment-1717870613 From duke at openjdk.org Thu Sep 14 02:21:14 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 14 Sep 2023 02:21:14 GMT Subject: RFR: 8316235: Optimization for DateTimeFormatter::format In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 14:56:15 GMT, ??? wrote: > In many scenarios, DateTimeFormatter::format is a slower operation. > > For example, the following business scenarios > 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings. > 2. In data integration scenarios, for projects like [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required. > > This PR provides format performance optimization for commonly used date patterns. > > ISO_INSTANT > ISO_LOCAL_TIME > ISO_LOCAL_DATE > ISO_LOCAL_DATETIME > HH:mm:ss > HH:mm:ss.SSS > yyyy-MM-dd > yyyy-MM-dd HH:mm:ss > yyyy-MM-dd'T'HH:mm:ss > yyyy-MM-dd HH:mm:ss.SSS > yyyy-MM-dd'T'HH:mm:ss.SSS src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2594: > 2592: } else { > 2593: return super.format(context, buf); > 2594: } This?can?use `instanceof?`: Suggestion: if (temporal instanceof LocalDateTime ldt) { date = ldt.toLocalDate(); } else if (temporal instanceof LocalDate ld) { date = ld; } else if (temporal instanceof ZonedDateTime zdt) { date = zdt.toLocalDate(); } else if (temporal instanceof OffsetDateTime odt) { date = odt.toLocalDate(); } else { return super.format(context, buf); } Or?even a?pattern?switch: Suggestion: switch (temporal) { case LocalDateTime ldt -> date = ldt.toLocalDate(); case LocalDate ld -> date = ld; case ZonedDateTime zdt -> date = zdt.toLocalDate(); case OffsetDateTime odt -> date = odt.toLocalDate(); default -> { return super.format(context, buf); } } src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2661: > 2659: } else { > 2660: return super.format(context, buf); > 2661: } This?can?use `instanceof?`: Suggestion: if (temporal instanceof LocalTime lt) { time = lt; } else if (temporal instanceof LocalDateTime ldt) { time = ldt.toLocalTime(); } else if (temporal instanceof ZonedDateTime zdt) { time = zdt.toLocalTime(); } else if (temporal instanceof OffsetDateTime odt) { time = odt.toLocalTime(); } else if (temporal instanceof OffsetTime ot) { time = ot.toLocalTime(); } else { return super.format(context, buf); } Or?even a?pattern?switch: Suggestion: switch (temporal) { case LocalTime lt -> time = lt; case LocalDateTime ldt -> time = ldt.toLocalTime(); case ZonedDateTime zdt -> time = zdt.toLocalTime(); case OffsetDateTime odt -> time = odt.toLocalTime(); case OffsetTime ot -> time = ot.toLocalTime(); default -> { return super.format(context, buf); } } src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2683: > 2681: * Composite printer and parser. > 2682: */ > 2683: static class CompositePrinterParser implements DateTimePrinterParser { This?class can?be?`sealed`: Suggestion: static sealed class CompositePrinterParser implements DateTimePrinterParser { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324933754 PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324937172 PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324941838 From duke at openjdk.org Thu Sep 14 02:21:14 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Thu, 14 Sep 2023 02:21:14 GMT Subject: RFR: 8316235: Optimization for DateTimeFormatter::format In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 18:52:21 GMT, ExE Boss wrote: >> In many scenarios, DateTimeFormatter::format is a slower operation. >> >> For example, the following business scenarios >> 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings. >> 2. In data integration scenarios, for projects like [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required. >> >> This PR provides format performance optimization for commonly used date patterns. >> >> ISO_INSTANT >> ISO_LOCAL_TIME >> ISO_LOCAL_DATE >> ISO_LOCAL_DATETIME >> HH:mm:ss >> HH:mm:ss.SSS >> yyyy-MM-dd >> yyyy-MM-dd HH:mm:ss >> yyyy-MM-dd'T'HH:mm:ss >> yyyy-MM-dd HH:mm:ss.SSS >> yyyy-MM-dd'T'HH:mm:ss.SSS > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2661: > >> 2659: } else { >> 2660: return super.format(context, buf); >> 2661: } > > This?can?use `instanceof?`: > Suggestion: > > if (temporal instanceof LocalTime lt) { > time = lt; > } else if (temporal instanceof LocalDateTime ldt) { > time = ldt.toLocalTime(); > } else if (temporal instanceof ZonedDateTime zdt) { > time = zdt.toLocalTime(); > } else if (temporal instanceof OffsetDateTime odt) { > time = odt.toLocalTime(); > } else if (temporal instanceof OffsetTime ot) { > time = ot.toLocalTime(); > } else { > return super.format(context, buf); > } > > > Or?even a?pattern?switch: > Suggestion: > > switch (temporal) { > case LocalTime lt -> time = lt; > case LocalDateTime ldt -> time = ldt.toLocalTime(); > case ZonedDateTime zdt -> time = zdt.toLocalTime(); > case OffsetDateTime odt -> time = odt.toLocalTime(); > case OffsetTime ot -> time = ot.toLocalTime(); > default -> { > return super.format(context, buf); > } > } It's a good idea to use the new switch syntax > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2683: > >> 2681: * Composite printer and parser. >> 2682: */ >> 2683: static class CompositePrinterParser implements DateTimePrinterParser { > > This?class can?be?`sealed`: > Suggestion: > > static sealed class CompositePrinterParser implements DateTimePrinterParser { Changes have been made based on your suggestions ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1325113374 PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1325112780 From jwaters at openjdk.org Thu Sep 14 03:25:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 14 Sep 2023 03:25:15 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v5] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into patch-10 - Document changes in awt_DnDDS.cpp - Remove negation in os_windows.cpp - Mismatched declaration in D3DGlyphCache.cpp - Fields in awt_TextComponent.cpp - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp - Qualifiers in awt_PrintDialog.h should be removed - Likewise for awt_DnDDT.cpp - awt_ole.h include order issue in awt_DnDDS.cpp - Revert awt_ole.h - ... and 15 more: https://git.openjdk.org/jdk/compare/11d431b2...1d3d6b5e ------------- Changes: https://git.openjdk.org/jdk/pull/15096/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=04 Stats: 802 lines in 17 files changed: 171 ins; 127 del; 504 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Thu Sep 14 03:26:04 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 14 Sep 2023 03:26:04 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Pinging ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1718706290 From mullan at openjdk.org Thu Sep 14 13:22:40 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 14 Sep 2023 13:22:40 GMT Subject: RFR: 4964430: Missing IllegalStateException exception requirement for javax.crypto.Cipher.doFinal In-Reply-To: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com> References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com> Message-ID: On Wed, 13 Sep 2023 18:08:35 GMT, Ben Perez wrote: > Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap` src/java.base/share/classes/javax/crypto/Cipher.java line 1855: > 1853: * @throws IllegalStateException if this {@code Cipher} object is in a > 1854: * wrong state (e.g., has not been initialized, or is not > 1855: * in ENCRYPT_MODE or DECRYPT_MODE.) Nit: I think you should remove the period at the end of these lines ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15727#discussion_r1325942248 From mullan at openjdk.org Thu Sep 14 15:05:52 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 14 Sep 2023 15:05:52 GMT Subject: RFR: 8312126: NullPointerException in CertStore.getCRLs after 8297955 Message-ID: <_VhiuO9MT7lq87Dq_4-h54mi9D1X2bqalr0Wm2squc8=.56efd2cc-f9ef-4438-a7eb-c3227a2dd8a6@github.com> Please review this fix for a regression in the LDAP CertStore implementation where a null CRL issuerName in an X509CRLSelector should be treated as a CertStoreException instead of a NullPointerException. A new test has been added but requires internal infrastructure so will only be in the closed. ------------- Commit messages: - Initial fix. Changes: https://git.openjdk.org/jdk/pull/15745/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15745&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312126 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15745/head:pull/15745 PR: https://git.openjdk.org/jdk/pull/15745 From duke at openjdk.org Thu Sep 14 18:43:10 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 14 Sep 2023 18:43:10 GMT Subject: RFR: 4964430: (spec) missing IllegalStateException exception requirement for javax.crypto.Cipher.doFinal [v2] In-Reply-To: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com> References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com> Message-ID: <0VHfX_zAjpEHPCWuF3vV6-PaEpSFvU4tmeGo-n3bN9A=.59e15728-a118-4d9b-90b1-060f75fef5c4@github.com> > Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Removed periods at end of IllegalStateException comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15727/files - new: https://git.openjdk.org/jdk/pull/15727/files/5a408805..ce5b77ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15727&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15727&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15727/head:pull/15727 PR: https://git.openjdk.org/jdk/pull/15727 From weijun at openjdk.org Thu Sep 14 19:33:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 14 Sep 2023 19:33:40 GMT Subject: RFR: 8312126: NullPointerException in CertStore.getCRLs after 8297955 In-Reply-To: <_VhiuO9MT7lq87Dq_4-h54mi9D1X2bqalr0Wm2squc8=.56efd2cc-f9ef-4438-a7eb-c3227a2dd8a6@github.com> References: <_VhiuO9MT7lq87Dq_4-h54mi9D1X2bqalr0Wm2squc8=.56efd2cc-f9ef-4438-a7eb-c3227a2dd8a6@github.com> Message-ID: On Thu, 14 Sep 2023 14:59:07 GMT, Sean Mullan wrote: > Please review this fix for a regression in the LDAP CertStore implementation where a null CRL issuerName in an X509CRLSelector should be treated as a CertStoreException instead of a NullPointerException. > > A new test has been added but requires internal infrastructure so will only be in the closed. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15745#pullrequestreview-1627615769 From jlu at openjdk.org Thu Sep 14 22:22:50 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 14 Sep 2023 22:22:50 GMT Subject: Integrated: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu wrote: > JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). This pull request has now been integrated. Changeset: b55e418a Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/b55e418a077791b39992042411cde97f68dc39fe Stats: 28964 lines in 488 files changed: 12 ins; 0 del; 28952 mod 8301991: Convert l10n properties resource bundles to UTF-8 native Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/15694 From valeriep at openjdk.org Thu Sep 14 23:21:39 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 14 Sep 2023 23:21:39 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 19:41:47 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8296631 test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java line 74: > 72: if (version == 0.0 || version >= 3.55) { > 73: useSqlite(true); > 74: } Instead of updating various tests with this block, how about doing this inside SecmodTest.initSecmod()? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15644#discussion_r1326607136 From mbaesken at openjdk.org Fri Sep 15 08:26:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 15 Sep 2023 08:26:55 GMT Subject: RFR: JDK-8316341: sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22 Message-ID: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> Currently sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22, it does not find the NSS libs because the new file system locations are not handled, unlike on Linux x86_64 . ------------- Commit messages: - JDK-8316341 Changes: https://git.openjdk.org/jdk/pull/15759/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15759&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316341 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15759/head:pull/15759 PR: https://git.openjdk.org/jdk/pull/15759 From dfuchs at openjdk.org Fri Sep 15 12:23:01 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 15 Sep 2023 12:23:01 GMT Subject: RFR: 8316031: SSLFlowDelegate should not log from synchronized block Message-ID: <3553Ecq1vew36P_0lSM-rp3i-Iitmqav4GA2ydIhGhs=.21d74038-3af0-442f-b8aa-452a702a7373@github.com> The java/net/httpclient/HttpClientLocalAddrTest.java has been observed failing relatively frequently in timeout - and the log shows a Carrier thread being pinned. Whether that's the root cause of the test failure is hard to say, but we should fix the code to avoid pinned threads. This is one path that had escaped my notice when I went through the HttpClient code before. ------------- Commit messages: - 8316031 Changes: https://git.openjdk.org/jdk/pull/15761/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15761&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316031 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15761.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15761/head:pull/15761 PR: https://git.openjdk.org/jdk/pull/15761 From djelinski at openjdk.org Fri Sep 15 12:50:39 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 15 Sep 2023 12:50:39 GMT Subject: RFR: 8316031: SSLFlowDelegate should not log from synchronized block In-Reply-To: <3553Ecq1vew36P_0lSM-rp3i-Iitmqav4GA2ydIhGhs=.21d74038-3af0-442f-b8aa-452a702a7373@github.com> References: <3553Ecq1vew36P_0lSM-rp3i-Iitmqav4GA2ydIhGhs=.21d74038-3af0-442f-b8aa-452a702a7373@github.com> Message-ID: On Fri, 15 Sep 2023 12:16:10 GMT, Daniel Fuchs wrote: > The java/net/httpclient/HttpClientLocalAddrTest.java has been observed failing relatively frequently in timeout - and the log shows a Carrier thread being pinned. > Whether that's the root cause of the test failure is hard to say, but we should fix the code to avoid pinned threads. This is one path that had escaped my notice when I went through the HttpClient code before. LGTM. Thanks! ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15761#pullrequestreview-1628880487 From mullan at openjdk.org Fri Sep 15 13:15:50 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 15 Sep 2023 13:15:50 GMT Subject: Integrated: 8312126: NullPointerException in CertStore.getCRLs after 8297955 In-Reply-To: <_VhiuO9MT7lq87Dq_4-h54mi9D1X2bqalr0Wm2squc8=.56efd2cc-f9ef-4438-a7eb-c3227a2dd8a6@github.com> References: <_VhiuO9MT7lq87Dq_4-h54mi9D1X2bqalr0Wm2squc8=.56efd2cc-f9ef-4438-a7eb-c3227a2dd8a6@github.com> Message-ID: <2ACd9CZpVdrDcDmJeNk7n2g0Y8KAItYdEsmUi2_xnQc=.0434e757-3e65-4825-9573-07255c41b5a4@github.com> On Thu, 14 Sep 2023 14:59:07 GMT, Sean Mullan wrote: > Please review this fix for a regression in the LDAP CertStore implementation where a null CRL issuerName in an X509CRLSelector should be treated as a CertStoreException instead of a NullPointerException. > > A new test has been added but requires internal infrastructure so will only be in the closed. This pull request has now been integrated. Changeset: 3c743cfe Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/3c743cfea00692d0b938cb1cbde936084eecf369 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8312126: NullPointerException in CertStore.getCRLs after 8297955 Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/15745 From lucy at openjdk.org Fri Sep 15 15:05:42 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 15 Sep 2023 15:05:42 GMT Subject: RFR: JDK-8316341: sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22 In-Reply-To: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> References: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> Message-ID: On Fri, 15 Sep 2023 08:21:00 GMT, Matthias Baesken wrote: > Currently sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22, it does not find the NSS libs because the new file system locations are not handled, unlike on Linux x86_64 . LGTM. Thanks for tracking down and fixing. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15759#pullrequestreview-1629168674 From dfuchs at openjdk.org Fri Sep 15 17:24:48 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 15 Sep 2023 17:24:48 GMT Subject: Integrated: 8316031: SSLFlowDelegate should not log from synchronized block In-Reply-To: <3553Ecq1vew36P_0lSM-rp3i-Iitmqav4GA2ydIhGhs=.21d74038-3af0-442f-b8aa-452a702a7373@github.com> References: <3553Ecq1vew36P_0lSM-rp3i-Iitmqav4GA2ydIhGhs=.21d74038-3af0-442f-b8aa-452a702a7373@github.com> Message-ID: <19RpR4g5RKmnG0IiLwAs1E-mRVX0-EF649zieMe1WYY=.30d46f29-5839-49f0-b9f4-acdab20b7999@github.com> On Fri, 15 Sep 2023 12:16:10 GMT, Daniel Fuchs wrote: > The java/net/httpclient/HttpClientLocalAddrTest.java has been observed failing relatively frequently in timeout - and the log shows a Carrier thread being pinned. > Whether that's the root cause of the test failure is hard to say, but we should fix the code to avoid pinned threads. This is one path that had escaped my notice when I went through the HttpClient code before. This pull request has now been integrated. Changeset: dc5ca1d3 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/dc5ca1d3798727fd29a6a40e9f7777cb7f85c004 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod 8316031: SSLFlowDelegate should not log from synchronized block Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/15761 From duke at openjdk.org Fri Sep 15 17:26:40 2023 From: duke at openjdk.org (Ian Myers) Date: Fri, 15 Sep 2023 17:26:40 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:23:01 GMT, Ian Myers wrote: > sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. > > TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** > TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** > > This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. Hi @wangweij and @XueleiFan, would either of you be willing to take a look at this PR? ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15618#issuecomment-1721611875 From rhalade at openjdk.org Fri Sep 15 17:31:15 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 15 Sep 2023 17:31:15 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v10] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into 8308592-certexpiry - Consolidate CA tests#3 - Consolidate CA tests#2 - Consolidate CA tests - Correct CRL checking - Merge branch 'master' into 8308592-certexpiry - Merge branch 'master' into 8308592-certexpiry - Merge branch 'master' into 8308592-certexpiry - fix typo in TeliaSoneraCA - Enable OCSP logging - ... and 9 more: https://git.openjdk.org/jdk/compare/dc5ca1d3...d941766a ------------- Changes: https://git.openjdk.org/jdk/pull/14252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=09 Stats: 6518 lines in 18 files changed: 1010 ins; 5508 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From rhalade at openjdk.org Fri Sep 15 17:32:49 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 15 Sep 2023 17:32:49 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v10] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Fri, 15 Sep 2023 17:31:15 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'master' into 8308592-certexpiry > - Consolidate CA tests#3 > - Consolidate CA tests#2 > - Consolidate CA tests > - Correct CRL checking > - Merge branch 'master' into 8308592-certexpiry > - Merge branch 'master' into 8308592-certexpiry > - Merge branch 'master' into 8308592-certexpiry > - fix typo in TeliaSoneraCA > - Enable OCSP logging > - ... and 9 more: https://git.openjdk.org/jdk/compare/dc5ca1d3...d941766a test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java line 26: > 24: /* > 25: * @test > 26: * @bug 8245654 8256895 The tests for `Certigna Root CA` is moved to `CAInterop` but `Certigna` CA test will continue to use old framework as there are no test URLs. This test is also update test for JDK-8256895 which was part of SSLCA.java test ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1327597264 From clanger at openjdk.org Fri Sep 15 18:17:39 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 15 Sep 2023 18:17:39 GMT Subject: RFR: JDK-8316341: sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22 In-Reply-To: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> References: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> Message-ID: On Fri, 15 Sep 2023 08:21:00 GMT, Matthias Baesken wrote: > Currently sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22, it does not find the NSS libs because the new file system locations are not handled, unlike on Linux x86_64 . Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15759#pullrequestreview-1629495724 From rhalade at openjdk.org Fri Sep 15 20:29:11 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 15 Sep 2023 20:29:11 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v11] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: Add SSL.com tests to ProblemList ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14252/files - new: https://git.openjdk.org/jdk/pull/14252/files/d941766a..72621998 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=09-10 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From weijun at openjdk.org Fri Sep 15 21:15:39 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 15 Sep 2023 21:15:39 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:23:01 GMT, Ian Myers wrote: > sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. > > TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** > TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** > > This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. Thanks for bringing this to my attention. If you believe the test change will make it run smoother, just do it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15618#issuecomment-1721869620 From shade at openjdk.org Mon Sep 18 05:57:39 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Sep 2023 05:57:39 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 21:13:01 GMT, Weijun Wang wrote: > Thanks for bringing this to my attention. If you believe the test change will make it run smoother, just do it. Would you like to formally approve this PR? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15618#issuecomment-1722793335 From mbaesken at openjdk.org Mon Sep 18 07:04:53 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 18 Sep 2023 07:04:53 GMT Subject: RFR: JDK-8316341: sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22 In-Reply-To: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> References: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> Message-ID: On Fri, 15 Sep 2023 08:21:00 GMT, Matthias Baesken wrote: > Currently sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22, it does not find the NSS libs because the new file system locations are not handled, unlike on Linux x86_64 . Hi Christoph and Lutz, thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15759#issuecomment-1722850076 From mbaesken at openjdk.org Mon Sep 18 07:04:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 18 Sep 2023 07:04:54 GMT Subject: Integrated: JDK-8316341: sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22 In-Reply-To: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> References: <_q26CWgSY7MXYSuGaIkuXN5VFD5cEKQJasNG8JGO0uc=.09676798-9f4b-4b2c-99ac-f85f8c182475@github.com> Message-ID: <-g5zX13yq9DlmeSGotEXD7wQh7frh24fyB05wA2tbJ8=.637acc52-beb7-410d-a34c-b35de2477341@github.com> On Fri, 15 Sep 2023 08:21:00 GMT, Matthias Baesken wrote: > Currently sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22, it does not find the NSS libs because the new file system locations are not handled, unlike on Linux x86_64 . This pull request has now been integrated. Changeset: aa0ebeed Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/aa0ebeedb18c5fafb4a86a53e1b1f59f330f0eed Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8316341: sun/security/pkcs11/PKCS11Test.java needs adjustment on Linux ppc64le Ubuntu 22 Reviewed-by: lucy, clanger ------------- PR: https://git.openjdk.org/jdk/pull/15759 From weijun at openjdk.org Mon Sep 18 14:28:41 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 18 Sep 2023 14:28:41 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:23:01 GMT, Ian Myers wrote: > sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. > > TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** > TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** > > This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15618#pullrequestreview-1631202084 From mpowers at openjdk.org Mon Sep 18 15:51:40 2023 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 18 Sep 2023 15:51:40 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Thu, 14 Sep 2023 23:18:39 GMT, Valerie Peng wrote: >> https://bugs.openjdk.org/browse/JDK-8296631 > > test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java line 74: > >> 72: if (version == 0.0 || version >= 3.55) { >> 73: useSqlite(true); >> 74: } > > Instead of updating various tests with this block, how about doing this inside SecmodTest.initSecmod()? Such a change would apply NSS version number checks to `TestNssDbSqlite` which currently doesn't have them. But wait! If `TestNssDbSqlite` has been running for years on all NSS versions, then it should be safe to make sqlite the default for all tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15644#discussion_r1328938101 From mullan at openjdk.org Mon Sep 18 18:21:43 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 18 Sep 2023 18:21:43 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v11] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Fri, 15 Sep 2023 20:29:11 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > Add SSL.com tests to ProblemList test/jdk/ProblemList.txt line 620: > 618: > 619: # jdk_security_infra > 620: security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#sslrootrsaca 8316381 generic-all Check if these URLs work now and can be avoided putting on ProblemList. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1329118580 From rhalade at openjdk.org Mon Sep 18 20:40:18 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Mon, 18 Sep 2023 20:40:18 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v12] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: <7v0CZJoQbNcPK5K6tHQQg7ijTH10K03Odx5BRsTARt4=.b0568aaf-7d80-4998-9539-2434d838c58d@github.com> > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Remove SSL root CA from ProblemList - Merge branch 'master' into 8308592-certexpiry - Add SSL.com tests to ProblemList - Merge branch 'master' into 8308592-certexpiry - Consolidate CA tests#3 - Consolidate CA tests#2 - Consolidate CA tests - Correct CRL checking - Merge branch 'master' into 8308592-certexpiry - Merge branch 'master' into 8308592-certexpiry - ... and 12 more: https://git.openjdk.org/jdk/compare/dcea9bf0...b3bb1d24 ------------- Changes: https://git.openjdk.org/jdk/pull/14252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=11 Stats: 6518 lines in 18 files changed: 1010 ins; 5508 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From mullan at openjdk.org Mon Sep 18 21:15:43 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 18 Sep 2023 21:15:43 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v12] In-Reply-To: <7v0CZJoQbNcPK5K6tHQQg7ijTH10K03Odx5BRsTARt4=.b0568aaf-7d80-4998-9539-2434d838c58d@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> <7v0CZJoQbNcPK5K6tHQQg7ijTH10K03Odx5BRsTARt4=.b0568aaf-7d80-4998-9539-2434d838c58d@github.com> Message-ID: <4fyJsdZEQhBH1U2C5kwhb8zxi3P5G7y0MCt0rR_wA1g=.45011a0e-d15b-4365-ae31-4e891213b892@github.com> On Mon, 18 Sep 2023 20:40:18 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Remove SSL root CA from ProblemList > - Merge branch 'master' into 8308592-certexpiry > - Add SSL.com tests to ProblemList > - Merge branch 'master' into 8308592-certexpiry > - Consolidate CA tests#3 > - Consolidate CA tests#2 > - Consolidate CA tests > - Correct CRL checking > - Merge branch 'master' into 8308592-certexpiry > - Merge branch 'master' into 8308592-certexpiry > - ... and 12 more: https://git.openjdk.org/jdk/compare/dcea9bf0...b3bb1d24 Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14252#pullrequestreview-1631980286 From alanb at openjdk.org Tue Sep 19 10:37:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 19 Sep 2023 10:37:41 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> References: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> Message-ID: On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote: >>> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops >> >> Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops. > >> > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops >> >> Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops. > > I think it's useful if trying to trace the calls (i.e. set to 0ms). Apparently the security manager was being used for that by some. > @tprinzing > Your change (at version [9fa2745](https://github.com/openjdk/jdk/commit/9fa2745960aea0bc45642081bac89fb5ef65809e)) is now ready to be sponsored by a Committer. @tprinzing I don't mind sponsoring but I think it would help if you could sync up the branch and provide a summary on the testing was done. The jdk_net and jdk_nio test groups are in tier2. The jdk_jfr test group is in tier3. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1725248917 From dfuchs at openjdk.org Tue Sep 19 15:18:44 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 19 Sep 2023 15:18:44 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v5] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 21:50:17 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > More changes from review: > > I didn't like the name of the helper method 'checkForCommit' because it > doesn't indicate that it might commit the event. I also don't like > 'commitEvent' because it might not. Since JFR events are sort of like a > queue I went with a name from collections and called it 'offer' so using > it is something like 'SocketReadEvent.offer(...)' which seems like it > gets the idea across better. Also improved the javadoc for it. > > Removed the comments about being instrumented by JFR in > Socket.SocketInputStream and Socket.SocketOutputStream. > > I went ahead and moved the event commiting out of the finally block so > that we don't emit events when the read/write did not actually happen. > The bugid JDK-8310979 will be used to determine if more should be done > in this area. > > The implRead and implWrite were moved up with the other support methods > for read/write. LGTM. Are there existing that will help verify that the read events and write events are still emitted as expected? If not shouldn't we write some? ------------- PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1633551891 From dfuchs at openjdk.org Tue Sep 19 15:18:45 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 19 Sep 2023 15:18:45 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 21:54:44 GMT, Tim Prinzing wrote: > No. I think it's a relic from the distant past though. I think the timeout field should be removed. It's not used on SocketChannel at all, and it doesn't seem useful on Socket. Should we log an RFE to that effect? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1330294609 From tprinzing at openjdk.org Tue Sep 19 15:35:11 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 19 Sep 2023 15:35:11 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v6] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8308995 - More changes from review: I didn't like the name of the helper method 'checkForCommit' because it doesn't indicate that it might commit the event. I also don't like 'commitEvent' because it might not. Since JFR events are sort of like a queue I went with a name from collections and called it 'offer' so using it is something like 'SocketReadEvent.offer(...)' which seems like it gets the idea across better. Also improved the javadoc for it. Removed the comments about being instrumented by JFR in Socket.SocketInputStream and Socket.SocketOutputStream. I went ahead and moved the event commiting out of the finally block so that we don't emit events when the read/write did not actually happen. The bugid JDK-8310979 will be used to determine if more should be done in this area. The implRead and implWrite were moved up with the other support methods for read/write. - less exception filtering when fetching socket read timeout - remove unused SOCKET_READ and SOCKET_WRITE configurations. - Merge branch 'master' into JDK-8308995 # Conflicts: # src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java - Avoid exceptions getting address/timeout for jfr event. Remove unused EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious whitespace. - some changes from review. read0() to implRead() write0() to implWrite() trailing whitespace - fix copyright date - Added micro benchmark to measure socket event overhead. - Some changes from review. Append a 0 to method names being wrapped. Use getHostString to avoid a reverse lookup when fetching the hostname of the remote address. - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4 ------------- Changes: https://git.openjdk.org/jdk/pull/14342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=05 Stats: 906 lines in 13 files changed: 519 ins; 379 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From rhalade at openjdk.org Tue Sep 19 16:14:56 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 19 Sep 2023 16:14:56 GMT Subject: Integrated: 8308592: Framework for CA interoperability testing In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: <9VvjmwwRRjMjpv5SRkgOuDY7k83Jg-27Ti4_bpqEjBs=.675ec912-3b9a-4839-aa52-9a424a2d9175@github.com> On Wed, 31 May 2023 18:03:57 GMT, Rajan Halade wrote: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. This pull request has now been integrated. Changeset: da57d2a1 Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/da57d2a1eb409ddc64117865c7d24ed518421cab Stats: 6518 lines in 18 files changed: 1010 ins; 5508 del; 0 mod 8308592: Framework for CA interoperability testing Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/14252 From duke at openjdk.org Tue Sep 19 17:09:56 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 19 Sep 2023 17:09:56 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Added test to check that when keystore.type is null it defaults to pkcs12 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15625/files - new: https://git.openjdk.org/jdk/pull/15625/files/23c357be..26978443 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=01-02 Stats: 56 lines in 2 files changed: 56 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15625/head:pull/15625 PR: https://git.openjdk.org/jdk/pull/15625 From kdriver at openjdk.org Tue Sep 19 17:19:41 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 19 Sep 2023 17:19:41 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 17:09:56 GMT, Ben Perez wrote: >> Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added test to check that when keystore.type is null it defaults to pkcs12 @haimaychao Are any accompanying changes needed in keytool? I took a quick look, but thought you might know better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15625#issuecomment-1726142945 From hchao at openjdk.org Tue Sep 19 18:46:40 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Tue, 19 Sep 2023 18:46:40 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: <7U9fESIF4jUEuslyO_Xgn-_tDoTcJKLBhOzJD-BLsR4=.8ceff76f-3448-44fa-ac56-4c5d12c075c7@github.com> On Tue, 19 Sep 2023 17:16:58 GMT, Kevin Driver wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Added test to check that when keystore.type is null it defaults to pkcs12 > > @haimaychao Are any accompanying changes needed in keytool? I took a quick look, but thought you might know better. @driverkt I took a look, and I think there is no change needed in keytool. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15625#issuecomment-1726295650 From anthony.scarpino at oracle.com Tue Sep 19 20:31:18 2023 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 19 Sep 2023 13:31:18 -0700 Subject: [External] : Re: PEM KeyStore Implementation In-Reply-To: References: <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com> Message-ID: <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com> There are no doc links yet. Tony On 9/10/23 1:04 AM, Karl Scheibelhofer wrote: > Hi Tony, > > The motivation was mostly about reading PEM keys and certificates > generated somewhere else. This is common practice in enterprise > environments I work in. Because corporate key material is subject to > centralized key management, including generation, backup and rollover. > PEM is the format most software products can handle. For Java > applications, having a PEM KeyStore would reduce the often required > additional step of converting PEM key and certificate in a Java > Keystore/PKCS#12. > Even truststores handling is easier with individual PEM certificates > instead of a single PKCS#12 Truststore. Adding or deleting a single > file instead of replacing the complete PKCS#12 store is less error > prone and cleaner to track in version control. The additional benefit > of a MAC in PKCS#12 adds little to no security in most cases. > And being text based, PEM is more version control friendly than binary PKCS#12. > > But to enable sound support of PEM, I also implemented writing PEM > keys and certificates. This way, one can use the JDK keytool to > generate key and certificate signing requests in PEM format. Getting > the certificate from the CA in PEM, one can use PEM throughout the > process. > > Do you have any links or documentation on the PEM API JEP that you mentioned? > > Thank you for your feedback and best regards > > Karl > > Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino > : >> >> Hi Karl >> >> The keystore is interesting and may have some value. Was your use case >> mostly reading PEM keys and certificates generated elsewhere for use >> with a particular application, maybe webservers? Did you see value in >> writing to this keystore from Java? >> >> On the topic of PEM, I hope before the end of the year to have a PEM API >> JEP. I would be interested in your API feedback from your keystore >> experiences. I think if this keystore contribution was accepted, it >> should wait so it can use that API. >> >> thanks >> >> Tony >> >> >> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote: >>> Hi, >>> >>> Working with Java and the JCA KeyStore for decades, I came across >>> many situations where I thought it would be convenient to be >>> able to load private keys and certificates in PEM format directly >>> using the KeyStore API. Without the need to convert them to PKCS#12/JKS. >>> >>> You can find my implementation of a PEM KeyStore in >>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ . >>> >>> I wondered if it would make sense to integrate such an implementation >>> in one of the standard providers of OpenJDK - like the SUN provider. >>> What do you think? >>> >>> Best regards >>> >>> Karl From anthony.scarpino at oracle.com Tue Sep 19 20:42:00 2023 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 19 Sep 2023 13:42:00 -0700 Subject: [External] : Re: RFD: Services lockdown for security providers In-Reply-To: References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com> <4b159d35-ee2e-952d-8e22-c035e5ed17ea@oracle.com> <1a0ad927-2da8-c881-a80f-b4928341375f@redhat.com> <7c07a7b1-6c68-9534-59e1-1813439d7f47@redhat.com> <85e89abd-eac3-87df-9e4b-1fa2c36a6286@oracle.com> Message-ID: Hi Martin, Thanks for the proposal. Your documents mostly describe the solution. Can you provide more of the motivations and use-cases for the change? Do you see non FIPS-140 applications using this feature? The feature does provide a comprehensive filtering system for JCA. The syntax, while powerful, seems like it would be somewhat error-prone and hard to use. We are also concerned that using the filter requires the sysadmin or developer to know about the service and algorithm details of every provider and which is required and which is not, all of which is not easily determined. thanks Tony On 9/1/23 9:30 AM, Martin Balao wrote: > Hi Sean, > > Thanks for clarifying your?idea. I understand your motivation and share > your concerns. I can think of how this application-specific?knowledge > can turn?into a library-specific one in?real?scenarios,?which may open > the door for undesired?dependencies. I also agree with being wary about > doing stack walks in a Security Manager style at time of use. We have to > give it some thought. Just in case, we reserved the characters ":" and > "," in our proposal for the Security Providers Filter [1] [2]. Extending > the filter syntax in the future (in a backward compatible way) should > not be a problem. > > Martin.- > > -- > [1] - https://bugs.openjdk.org/browse/JDK-8315487 > > [2] - https://github.com/openjdk/jdk/pull/15539 > > > > On Thu, Jul 13, 2023 at 1:01?PM Sean Mullan > wrote: > > > > On 7/13/23 12:27 PM, Martin Balao wrote: > > On 7/13/23 12:06, Sean Mullan wrote: > >> One other comment that I thought of - is that from a practical > >> standpoint, I think it will be hard to unilaterally disable an > algorithm > >> at the JCE layer unless it is so broken that almost no code ever > uses > >> it, say MD2 or RC2. There may be cases where a weak algorithm is > >> acceptable, for example using MD5 for a checksum. (For a real > example, > >> UUID.nameUUIDFromBytes uses MD5 to generate a UUID). > >> > >> If you have a single case in your application where a weak > algorithm is > >> ok to use, you won't be able to disable it across the board. > > > > Yes, I agree with this observation. In fact, our original > motivation was > > not to disable an algorithm across the board but a specific > > implementation of it ?i.e. blocking the implementation from > provider X, > > because we want the one from provider Y or prefer the algorithm > not to > > be available. What we also have in mind is using this enhancement in > > combination with security profiles that can enforce policies of > allowed > > algorithms, at the risk of requiring changes in an application to be > > compliant. > > > >> > >> At the risk of complicating your syntax and implementation, it > may be > >> worth exploring adding the name of a class to the syntax for > cases like > >> this. But my comment is more about thinking about this a bit > more first. > >> > >> Or perhaps adding some extensibility into the format would be a good > >> idea in case we want to add something like this down the line. > >> > > > > I have a couple of questions regarding this idea: > > > > 1) Isn't the class name an implementation detail? My concern is > not much > > on how to extend the syntax but on binding the filter value to > internal > > names. > > It is an application-specific detail. I would expect this to be applied > by applications that are most familiar with their usage, and not as > part > of a global configuration. > > > 2) Why wouldn't a combination of Security Provider + Service Type + > > Algorithm be enough to identify a specific implementation? > > Because that doesn't tell you who is calling the specific > provider/service and whether that use case is acceptable or not. Also > most code that calls JCE APIs doesn't specify a specific provider. > > Again, I think this needs more thought, and I am not suggesting this is > the best course of action, but one thought is a syntax something > like this: > > jdk.security.providers.filter=java.util.UUID.nameUUIDFromBytes:MessageDigest.MD5;!*.MessageDigest.MD5;* > > But, that would probably mean extending the implementation to do a > stack > walk to check if the specified class was one of the callers, which I am > very wary about doing something like this. But the overall issue still > remains for me. Maybe we should not be providing a way to unilaterally > disable algorithms unless it can be used more effectively in practice. > Otherwise I don't like the idea of telling a user they have to > re-enable > the algorithm even if they only have a single case where it is > acceptable. > > --Sean > > > Thanks, > > Martin.- > > > > > >> --Sean > >> > >> > >> On 7/13/23 11:44 AM, Martin Balao wrote: > >>> Hi Sean, > >>> > >>> Thanks for your feedback. > >>> > >>> Just to give some visibility, we have implemented most of the > >>> functionality and are now working on final adjustments, more tests > >>> coverage, documentation and internal reviews. The implementation is > >>> pretty much aligned to what we previously discussed, with the > exception > >>> of algorithm's alias that turned up to have more complexity than > >>> anticipated ?particularly in the legacy mode of registering > Services?. > >>> > >>> We will send a PR for public discussion in the coming weeks. > >>> > >>> Martin.- > >>> > >>> > >>> On 6/14/23 12:40, Sean Mullan wrote: > >>>> This proposal looks pretty good, although I think I would like > to see > >>>> more examples and a prototype if you have it. > >>>> > >>>> I think this would work well in conjunction with Sean Coffey's > >>>> enhancement to add a security category to the java > -XshowSettings option > >>>> [1]. This would help debug issues with the syntax. The provider > >>>> suboption could be enhanced (perhaps by default, perhaps with an > >>>> additional suboption) to show the services that are disabled, > ex, with > >>>> the property set to > >>>> > >>>> jdk.security.providers.filter=!*.MessageDigest.MD5; > >>>> !*.MessageDigest.MD2; *: > >>>> > >>>> it would show something like: > >>>> > >>>>? ? ??????? Provider name: SUN > >>>>? ? ??????? Provider information: ... > >>>>? ? ??????? Provider services: (type : algorithm) > >>>>? ? ??????????? ... > >>>>? ? ??????????? MessageDigest : MD2 (disabled) > >>>>? ? ??????????? MessageDigest : MD5 (disabled) > >>>>? ? ??????????? ... > >>>> > >>>> I would even add that as a debugging tip in the documenting of the > >>>> syntax. > >>>> > >>>> --Sean > >>>> > >>>> [1] https://github.com/openjdk/jdk/pull/14394 > > >>>> > >>>> On 5/24/23 5:03 PM, Martin Balao wrote: > >>>>> Hi, > >>>>> > >>>>> Thanks Anthony for your feedback. > >>>>> > >>>>> We've been exploring the syntax and semantics for this new > property > >>>>> further, with the goal of making it more consistent and > simple while > >>>>> retaining expressiveness power. We understand the importance > of clarity > >>>>> to minimize the risk of security providers, service types or > algorithms > >>>>> being unexpectedly enabled. > >>>>> > >>>>> In this new iteration of the proposal, we explore a filter > that has > >>>>> similarities to the serialization filter (jdk.serialFilter). > We think > >>>>> that it could be beneficial to leverage on a specification to > which the > >>>>> user is familiar already. > >>>>> > >>>>> > >>>>> General structure > >>>>> ==================== > >>>>> > >>>>> jdk.security.providers.filter=pattern-1; pattern-2; ...; > pattern-n > >>>>> > >>>>> The property jdk.security.providers.filter is an overrideable > Security > >>>>> property. Thus, a System property with the same name exists > and, when > >>>>> specified, overrides any value in its Security counterpart. > When not > >>>>> specified (value is null), filtering capabilities are completely > >>>>> disabled: all installed security providers, service types and > >>>>> algorithms > >>>>> are allowed. If any of these properties are set during run > time, the > >>>>> filter could be initialized already and the new value may not > take > >>>>> effect. > >>>>> > >>>>> When filtering capabilities are enabled, each service is checked > >>>>> against > >>>>> the filter before registration. Notice that this affects both the > >>>>> initial list of security providers as well as those dynamically > >>>>> installed during run time. Once a service is registered, > instances > >>>>> of it > >>>>> can be obtained and used without any other checks that could > affect > >>>>> performance. > >>>>> > >>>>> The registration of a service involves a combination of a > security > >>>>> provider, service type and algorithm. Each combination is > evaluated > >>>>> against the filter patterns, from left to right. When a > pattern matches > >>>>> ?or, in other words, the rule concerns the service to be > registered?, a > >>>>> decision is made: the service will be allowed or denied. When a > >>>>> decision > >>>>> is made, remaining patterns are not checked for the service under > >>>>> consideration. When all patterns are checked and a decision > is not > >>>>> made, > >>>>> the default behavior is to deny the service registration. > >>>>> > >>>>> Contrary to the serialization filter, white spaces between > patterns do > >>>>> not have any significance. > >>>>> > >>>>> > >>>>> Pattern matching > >>>>> ===================================================== > >>>>> > >>>>> pattern := ! security-provider.service-type.algorithm > >>>>> > >>>>> pattern := security-provider.service-type.algorithm > >>>>> > >>>>> A canonical pattern consists of 3 hierarchical levels > separated by ".". > >>>>>? ?? From left to right in lexicographic order, these levels > denote a > >>>>> security provider, a service type and an algorithm. If a > pattern starts > >>>>> with "!", the decision made upon matching is to deny the service > >>>>> registration. Otherwise, the service registration is allowed. > White > >>>>> spaces between "!" and the rest of the pattern do not have any > >>>>> significance. > >>>>> > >>>>> For a match to be successful, the security provider name, the > service > >>>>> type and the algorithm have to match the pattern exactly (case > >>>>> insensitive). If the service type of a security provider > interprets the > >>>>> algorithm as a transformation composed of different parts, > the full > >>>>> transformation has to be specified in the pattern: the filter > takes a > >>>>> conservative approach and does not make any assumptions of > what an > >>>>> algorithm name means. For example, "AES" as the algorithm of a > >>>>> canonical > >>>>> filter pattern will not match an "AES/ECB/PKCS5Padding" > transformation. > >>>>> > >>>>> If an algorithm alias is specified in the filter pattern, a > service > >>>>> registering the alias will be matched. > >>>>> > >>>>> For convenience, it's possible to specify patterns in > non-canonical > >>>>> forms: > >>>>> > >>>>> 1) At any level, the security provider, the service type or the > >>>>> algorithm name can contain wildcards ("*") to represent zero > or more > >>>>> repetitions of any character; > >>>>> > >>>>> 2) The .algorithm part can be omitted to imply all algorithms > under the > >>>>> security provider and service type; > >>>>> > >>>>> 3) The .service-type.algorithm part can be omitted to imply > all service > >>>>> types and algorithms under the security provider; and, > >>>>> > >>>>> 4) The non-canonical form #1 can be combined with either #2 > or #3. > >>>>> > >>>>> > >>>>> Security provider, service type and algorithm names escaping > >>>>> ================================================================= > >>>>> > >>>>> If the security provider, service type or algorithm name contains > >>>>> any of > >>>>> the characters "\", ".", ";" or "*", they have to be escaped by > >>>>> prepending the character "\". If the character "\" is found not > >>>>> escaping > >>>>> a character, it's silently discarded. > >>>>> > >>>>> White spaces are discarded at the beginning and end of names. > >>>>> > >>>>> It's worth mentioning that the described escaping rules apply > to the > >>>>> jdk.security.providers.filter property value as read in > >>>>> java.lang.System::getProperty or > java.security.Security::getProperty. > >>>>> Additional escaping might be needed depending on how the > property is > >>>>> passed. For example, Security properties require "\" > characters to be > >>>>> escaped. Thus, to match a provider name whose name is "\.", a > filter > >>>>> would require the "jdk.security.providers.filter=\\\\\\." > entry in the > >>>>> java.security file. See more about this in > java.util.Properties::load > >>>>> [1]. > >>>>> > >>>>> > >>>>> Examples (correct) > >>>>> ==================== > >>>>> > >>>>> -- > >>>>> > >>>>> Enable all security providers, service types and algorithms: > >>>>> > >>>>> jdk.security.providers.filter= > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=* > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=*.* > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=*.*.* > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the MD5 algorithm in MessageDigest > >>>>> services > >>>>> when implemented by the SUN security provider: > >>>>> > >>>>> jdk.security.providers.filter=!SUN.MessageDigest.MD5; * > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the MD5 algorithm in MessageDigest > >>>>> services, irrespective of the security provider: > >>>>> > >>>>> jdk.security.providers.filter=!*.MessageDigest.MD5; * > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for algorithms using MD5, > irrespective of the > >>>>> security provider and the service type: > >>>>> > >>>>> jdk.security.providers.filter=!*.*.*MD5*; * > >>>>> > >>>>> Notice that in this case there are wildcards at the beginning and > >>>>> end of > >>>>> the algorithm name. The reason is to match MD5 uses in > algorithms such > >>>>> as HmacMD5, MD5withRSA, PBEWithMD5AndDES, etc. > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the RC4 algorithm in Cipher > services when > >>>>> implemented by the SunJCE security provider: > >>>>> > >>>>> jdk.security.providers.filter=!SunJCE.Cipher.ARCFOUR; * > >>>>> > >>>>> or > >>>>> > >>>>> jdk.security.providers.filter=!SunJCE.Cipher.RC4; * > >>>>> > >>>>> or > >>>>> > >>>>> > jdk.security.providers.filter=!SunJCE.Cipher.1\.2\.840\.113549\.3\.4; * > >>>>> > >>>>> -- > >>>>> > >>>>> Enable the SUN security provider only, with all its service > types and > >>>>> algorithms. Other security providers must be disabled. > >>>>> > >>>>> jdk.security.providers.filter=SUN > >>>>> > >>>>> -- > >>>>> > >>>>> Enable the SUN security provider only, with all its service > types and > >>>>> algorithms except for MessageDigest. Other security providers > must be > >>>>> disabled. > >>>>> > >>>>> jdk.security.providers.filter=!SUN.MessageDigest; SUN > >>>>> > >>>>> -- > >>>>> > >>>>> > >>>>> Examples (mistakes) > >>>>> ==================== > >>>>> > >>>>> -- > >>>>> > >>>>> Enable everything except for the MD5 algorithm, irrespective > of the > >>>>> security provider and the service type: > >>>>> > >>>>> jdk.security.providers.filter=*; !*.*.MD5 > >>>>> > >>>>> This is wrong because the pattern "*" is matched first and a > decision > >>>>> allowing MD5 will be made immediately after. The pattern > "!*.*.MD5" > >>>>> will > >>>>> never be checked. > >>>>> > >>>>> -- > >>>>> > >>>>> Enable all SUN service types except for MessageDigest. > Disable other > >>>>> security providers. > >>>>> > >>>>> jdk.security.providers.filter=!SUN.MessageDigest > >>>>> > >>>>> While non-SUN security providers are effectively disabled, > this is > >>>>> wrong > >>>>> because SUN services other than MessageDigest will not match any > >>>>> pattern > >>>>> and, by default, the decision is to deny registration. > >>>>> > >>>>> -- > >>>>> > >>>>> Enable the SunPKCS11 security provider only. > >>>>> > >>>>> jdk.security.providers.filter=SunPKCS11 > >>>>> > >>>>> This is wrong because the SunPKCS11 provider has to be > identified by > >>>>> its > >>>>> name instead of its class. A possible name would have the form of > >>>>> SunPKCS11-NAME. In a filter, this can be matched either by > >>>>> "SunPKCS11-NAME" or "SunPKCS11-*". > >>>>> > >>>>> -- > >>>>> > >>>>> > >>>>> Look forward to your thoughts. > >>>>> > >>>>> Thanks.- > >>>>> > >>>>> > >>>>> -- > >>>>> [1] - > >>>>> > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Properties.html#load%28java.io.Reader%29 > >>>>> > >>>>> (?) - Thanks to Francisco Ferrari (@fferrari) for his > contributions to > >>>>> this proposal. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 2/24/23 14:49, Anthony Scarpino wrote: > >>>>>> Hi Martin, > >>>>>> > >>>>>> Interesting proposal.? I think Alternative 1 is a better > direction to > >>>>>> explore from a code structure standpoint.? If I remember > correctly, > >>>>>> Preferred Provider is accessed when getting a service or > instance > >>>>>> of the > >>>>>> algorithm.? That happens on a per-operation basis.? What you > >>>>>> describe is > >>>>>> something that would reshape contents of the ProviderList where > >>>>>> algorithms or services would not be in the list at all.? That is > >>>>>> were I > >>>>>> think #2 gets too complex in trying to handle both in the same > >>>>>> property. > >>>>>>? ?? ?#2 may end up putting all checks in a per-operation check, > >>>>>> hindering > >>>>>> performance every time as the list grows. > >>>>>> > >>>>>> I agree this is mostly used in the FIPS situation or where > someone > >>>>>> wants > >>>>>> to disable an algorithm completely, say MD5.? In those cases > it's best > >>>>>> to just prevent the algorithm from ever being available. > >>>>>> > >>>>>> On the smaller details side that you list.? I think the name > >>>>>> ".enabled" > >>>>>> doesn't fit, particularly as the first thing in the example > >>>>>> disables all > >>>>>> Ciphers :).? I don't have any suggestions at this time. > >>>>>> > >>>>>> As far as the syntax.? I think it maybe a bit difficult to > parse in > >>>>>> code > >>>>>> and mental to disable all Ciphers, then enable just for > SunJCE and > >>>>>> SUN. > >>>>>> The SUN '*" confused me until I realized you were enabling > Ciphers. > >>>>>> Seems too easy to get wrong.? I know you weren't making a > formal spec, > >>>>>> but we have to start somewhere. > >>>>>> > >>>>>> thanks > >>>>>> > >>>>>> Tony > >>>>>> > >>>>>> > >>>>>> On 2/17/23 10:52 AM, Martin Balao wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> We would like to discuss a limitation in the current > configuration > >>>>>>> capabilities for security providers and possible solutions > that we > >>>>>>> are > >>>>>>> exploring (?). > >>>>>>> > >>>>>>> As you know, current configuration capabilities in > java.security > >>>>>>> allow > >>>>>>> users to install security providers, decide their priority > in a list > >>>>>>> (security.provider. properties) and even circumvent this > priority > >>>>>>> for specific algorithms (jdk.security.provider.preferred > property). > >>>>>>> However, there is no granularity in terms of what service > types and > >>>>>>> algorithms are enabled once a security provider is > installed: it's an > >>>>>>> all or nothing scheme. It is worth noting that security > providers can > >>>>>>> bring with them a diverse range of service types. As an > example, the > >>>>>>> SUN security provider comes with the following service types: > >>>>>>> SecureRandom, Signature, KeyPairGenerator, > >>>>>>> AlgorithmParameterGenerator, AlgorithmParameters, KeyFactory, > >>>>>>> MessageDigest, CertificateFactory, KeyStore, CertStore, Policy, > >>>>>>> Configuration, CertPathBuilder and CertPathValidator [1]. > >>>>>>> > >>>>>>> In some cases, the user may need to enforce that all > cryptographic > >>>>>>> primitives come from a specific security provider. This > could happen, > >>>>>>> for example, when operating in a FIPS-compliant environment > or under > >>>>>>> strict security policies. To better illustrate, let's say > that the > >>>>>>> user requires that all cryptographic operations are > performed in a > >>>>>>> Hardware Security Module (HSM). On the OpenJDK side, this > means that > >>>>>>> the implementation for Cipher, Signature, Mac and other > cryptographic > >>>>>>> services must be the one in the SunPKCS11 security > provider. Let's > >>>>>>> also suppose that other non-cryptographic services such as > those for > >>>>>>> certificates validation and TLS are required, and their > >>>>>>> implementation > >>>>>>> is in the SUN and SunJSSE security providers respectively. > Setting > >>>>>>> SunPKCS11 at the highest priority of the list is not a strong > >>>>>>> guarantee to ensure that all cryptographic operations come > from it: > >>>>>>> it's possible that an algorithm for Signature is not > implemented in > >>>>>>> SunPKCS11 or in its underlying token but in the SUN security > >>>>>>> provider. > >>>>>>> Disabling the SUN security provider wouldn't be an option > in this > >>>>>>> case > >>>>>>> because we need its certificates validation service. > >>>>>>> > >>>>>>> This problem goes beyond OpenJDK default security > providers. Even if > >>>>>>> we come up with a new layout for service types, algorithms and > >>>>>>> providers ?putting backward compatibility issues aside?, > there is > >>>>>>> always the possibility that a 3rd party security provider > does not > >>>>>>> follow any services grouping convention. It might also be > the case > >>>>>>> that we need to disable a specific algorithm only ?i.e. for > >>>>>>> cryptographic policy reasons? and TLS or JAR signing > properties fall > >>>>>>> short. > >>>>>>> > >>>>>>> In our view, it would be beneficial to add more configuration > >>>>>>> flexibility and control to the existing API in which any > security > >>>>>>> provider can be plugged in, in the form of deciding which > service > >>>>>>> types and algorithms are enabled for each installed provider. > >>>>>>> > >>>>>>> There are 2 alternatives that we are exploring to tackle this > >>>>>>> problem. > >>>>>>> > >>>>>>> Alternative #1 > >>>>>>> =========================== > >>>>>>> > >>>>>>> Introduce a new security property to decide which service > types and > >>>>>>> algorithms are enabled for each security provider. The > default value > >>>>>>> for this property would be empty, which keeps this feature > disabled > >>>>>>> and all services from installed security providers available. > >>>>>>> > >>>>>>> As for the new property's syntax and semantics, we've been > >>>>>>> considering > >>>>>>> an allow-list along the lines of: > >>>>>>> > >>>>>>> jdk.security.provider.enabled = security-provider-1 { > >>>>>>> service-type-1 : > >>>>>>> alg-1, ... ; ... } , ... > >>>>>>> > >>>>>>> Note: we need a formal syntax specification, this is for > illustration > >>>>>>> only. > >>>>>>> > >>>>>>> As part of the syntax we are considering the use of > wildcards (*) to > >>>>>>> match multiple security providers, service types and > algorithms, and > >>>>>>> minus signs (-) to remove service types. When a service type is > >>>>>>> removed, the action applies to all algorithms and any > attempt to > >>>>>>> specify them explicitly would be an error. The minus sign > cannot be > >>>>>>> used at the algorithm level. We are also thinking that in > case of a > >>>>>>> partial or total contradiction between conditions, the > right-most > >>>>>>> value applies on top of the others. If a security provider, > service > >>>>>>> type or algorithm does not exist, we can simply write a > debug warning > >>>>>>> and ignore it. As for the name of the algorithms, we can > also include > >>>>>>> Ciphers transformations. > >>>>>>> > >>>>>>> Example: > >>>>>>> > >>>>>>> jdk.security.provider.enabled = * { -Cipher }, SunJCE { > Cipher : > >>>>>>> AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature } > >>>>>>> > >>>>>>> This would be interpreted as: > >>>>>>> > >>>>>>>? ????* Irrespective of the provider (*), Cipher services > should be > >>>>>>> removed (-). This rule would be superfluous in this case > because the > >>>>>>> property itself is an allow-list and there is nothing to > the left > >>>>>>> that > >>>>>>> enables Cipher service types for any provider. > >>>>>>>? ????* From the SunJCE security provider, Cipher services with > >>>>>>> AES/GCM/NoPadding and DES transformations are allowed, and > Signature > >>>>>>> services with any algorithm are allowed. Notice that there is a > >>>>>>> shortcut here: the algorithm list that follows the service > name, "': > >>>>>>> alg-1, ..." is optional. When omitted all the service's > algorithms > >>>>>>> are > >>>>>>> enabled. > >>>>>>>? ????* From the SUN security provider, every service type > is allowed > >>>>>>> except Signature (recall that a minus sign can only apply to a > >>>>>>> service, removing all associated algorithms). > >>>>>>> > >>>>>>> It's not the goal of this proposal to invalidate property > values that > >>>>>>> lead to inconsistent internal states, such as "the Cipher > service of > >>>>>>> SunJCE depends on AlgorithmParameters from SUN". This is > because the > >>>>>>> combinations for a check are virtually infinite: there can > be 3rd > >>>>>>> party security providers with their own semantics and > >>>>>>> dependencies. In > >>>>>>> the same way, we cannot determine at start time any application > >>>>>>> dependencies. It's up to the user to analyze all types of > >>>>>>> dependencies > >>>>>>> before setting a value. > >>>>>>> > >>>>>>> > >>>>>>> Alternative #2 > >>>>>>> =========================== > >>>>>>> > >>>>>>> Introduce a boolean security property to turn the value of the > >>>>>>> existing jdk.security.provider.preferred property into the only > >>>>>>> combinations of algorithm, service and provider that are > allowed: > >>>>>>> > >>>>>>> jdk.security.provider.preferredOnly = true > >>>>>>> > >>>>>>> The default value for the new property would be "false", > keeping the > >>>>>>> current "preferred" behavior in which all algorithms and > services > >>>>>>> from > >>>>>>> installed security providers are available. > >>>>>>> > >>>>>>> Contrary to Alternative #1, the user has to explicitly list the > >>>>>>> algorithms and cannot rely on wildcards to express wide > categories > >>>>>>> such as "all Cipher algorithms from SunJCE" or "all > algorithms from > >>>>>>> SunJCE". The use of minus signs to remove service types or > algorithms > >>>>>>> wouldn't be available either. > >>>>>>> > >>>>>>> In order to mitigate the burden on users we can consider > extending > >>>>>>> jdk.security.provider.preferred syntax as long as we keep > >>>>>>> backward-compatibility and stay within the boundaries of a > >>>>>>> "preferred" > >>>>>>> semantics. For example, we can accept a value of > >>>>>>> "jdk.security.provider.preferred=SunJCE" to mean that any > service and > >>>>>>> any algorithm from SunJCE is either preferred or allowed, > >>>>>>> depending on > >>>>>>> the value of jdk.security.provider.preferredOnly. This case > would > >>>>>>> be a > >>>>>>> service type and algorithm wildcard. We can also define an > >>>>>>> algorithms-only wildcard, such as Cipher.*:SunJCE. > >>>>>>> > >>>>>>> Alternative #2 has the advantage of reusing most or all of the > >>>>>>> existing syntax. However, it's worth noticing that it > implies an > >>>>>>> overloaded semantic that can turn confusing or inconvenient > in some > >>>>>>> cases. As an example, a user that relies on the prioritized > security > >>>>>>> providers list for most of the algorithms and has only a few > >>>>>>> preferred > >>>>>>> exceptions, would need to express preferences by extension upon > >>>>>>> turning on this feature. Alternative #1 keeps preferences and > >>>>>>> availability as two separate concepts, in a more clear way. > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Martin.- > >>>>>>> > >>>>>>> -- > >>>>>>> [1] - > >>>>>>> > https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D > >>>>>>> (?) - Thanks to @fferrari for his contributions to this > proposal. > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From tprinzing at openjdk.org Tue Sep 19 20:54:48 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 19 Sep 2023 20:54:48 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v6] In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into JDK-8308995 > - More changes from review: > > I didn't like the name of the helper method 'checkForCommit' because it > doesn't indicate that it might commit the event. I also don't like > 'commitEvent' because it might not. Since JFR events are sort of like a > queue I went with a name from collections and called it 'offer' so using > it is something like 'SocketReadEvent.offer(...)' which seems like it > gets the idea across better. Also improved the javadoc for it. > > Removed the comments about being instrumented by JFR in > Socket.SocketInputStream and Socket.SocketOutputStream. > > I went ahead and moved the event commiting out of the finally block so > that we don't emit events when the read/write did not actually happen. > The bugid JDK-8310979 will be used to determine if more should be done > in this area. > > The implRead and implWrite were moved up with the other support methods > for read/write. > - less exception filtering when fetching socket read timeout > - remove unused SOCKET_READ and SOCKET_WRITE configurations. > - Merge branch 'master' into JDK-8308995 > > # Conflicts: > # src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java > - Avoid exceptions getting address/timeout for jfr event. Remove unused > EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious > whitespace. > - some changes from review. > > read0() to implRead() > write0() to implWrite() > trailing whitespace > - fix copyright date > - Added micro benchmark to measure socket event overhead. > - Some changes from review. > > Append a 0 to method names being wrapped. Use getHostString to avoid > a reverse lookup when fetching the hostname of the remote address. > - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4 I sync'd master and updated the bug report with the successful test results. Created [JDK-8316558] to track potential timeout field removal. The existing JFR tests TestSocketChannelEvents and TestSocketEvents in jdk.jfr.event.io verify the events are still emitted as expected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1726449349 From hchao at openjdk.org Tue Sep 19 22:26:41 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Tue, 19 Sep 2023 22:26:41 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 17:09:56 GMT, Ben Perez wrote: >> Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added test to check that when keystore.type is null it defaults to pkcs12 Marked as reviewed by hchao (Committer). test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 42: > 40: private void runTest(String[] args) { > 41: if (!KeyStore.getDefaultType(). > 42: equalsIgnoreCase(DEFAULT_KEY_STORE_TYPE)) { nits: indent 8 spaces for line continuation (on #42 and #45) ------------- PR Review: https://git.openjdk.org/jdk/pull/15625#pullrequestreview-1634292564 PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1330766092 From valeriep at openjdk.org Tue Sep 19 23:57:42 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 19 Sep 2023 23:57:42 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 15:49:10 GMT, Mark Powers wrote: >> test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java line 74: >> >>> 72: if (version == 0.0 || version >= 3.55) { >>> 73: useSqlite(true); >>> 74: } >> >> Instead of updating various tests with this block, how about doing this inside SecmodTest.initSecmod()? > > Such a change would apply NSS version number checks to `TestNssDbSqlite` which currently doesn't have them. But wait! If `TestNssDbSqlite` has been running for years on all NSS versions, then it should be safe to make sqlite the default for all tests. Yes, for new NSS releases, it should be safe to set sqlite to true by default. The tests which relies on sqlite like `TestNssDbSqlite` can always call useSqlite(true) regardless of default. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15644#discussion_r1330812595 From valeriep at openjdk.org Wed Sep 20 06:05:44 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 20 Sep 2023 06:05:44 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 17:09:56 GMT, Ben Perez wrote: >> Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added test to check that when keystore.type is null it defaults to pkcs12 test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 2: > 1: /* > 2: * Copyright (c) 2023 Oracle and/or its affiliates. All rights reserved. Where did you get the copyright from? IIRC, there should be a coma after the year and also copyright for the test file should not have the "Classpath" thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1331040799 From valeriep at openjdk.org Wed Sep 20 06:13:44 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 20 Sep 2023 06:13:44 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 17:09:56 GMT, Ben Perez wrote: >> Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added test to check that when keystore.type is null it defaults to pkcs12 test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 34: > 32: * KeyStore.getDefaultType() value is related to property value. Expect a full > 33: * match the value 'keystore.type' and the value of the > 34: * KeyStore.getDefaultType() I don't quite get the summary... Isn't the property value set to null? How can it be full match to KeyStore.getDefaultType()? test/jdk/java/security/KeyStore/PKCS12/java.security line 1: > 1: # override keystore.type property and make it not exist nit: maybe the comment is easier to understand if changed to "do not set keystore.type property, so default value will be used". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1331044517 PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1331045976 From karl.scheibelhofer at gmx.net Wed Sep 20 09:26:32 2023 From: karl.scheibelhofer at gmx.net (Karl Scheibelhofer) Date: Wed, 20 Sep 2023 11:26:32 +0200 Subject: [External] : Re: PEM KeyStore Implementation In-Reply-To: <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com> References: <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com> <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com> Message-ID: Hi Tony! When the PEM API implementation becomes available it would make sense to use it inside the PEM Keystore implementation. It will reduce the code (the internal classes PemReader und PemWriter may become obsolete), but it does not affect the functionality of the PEM keystore. Users of the PEM Keystore won't experience a difference. Let me know when there is something for the PEM API and I will see if I can assist. I would suggest starting with PEM Keystore now and not wait for the PEM API, because the time schedule for it seems vague. I would try to refactor my current PEM Keystore implementation to integrate in the OpenJDK sun.security.provider package. I do not expect any API changes or other compatibility issues with existing code. Then consult this group for feedback before creating a pull request. When the PEM API becomes available, rework the PEM Keystore implementation to use it internally. What do you think? Best regards Karl Scheibelhofer Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino : > > There are no doc links yet. > > Tony > > On 9/10/23 1:04 AM, Karl Scheibelhofer wrote: > > Hi Tony, > > > > The motivation was mostly about reading PEM keys and certificates > > generated somewhere else. This is common practice in enterprise > > environments I work in. Because corporate key material is subject to > > centralized key management, including generation, backup and rollover. > > PEM is the format most software products can handle. For Java > > applications, having a PEM KeyStore would reduce the often required > > additional step of converting PEM key and certificate in a Java > > Keystore/PKCS#12. > > Even truststores handling is easier with individual PEM certificates > > instead of a single PKCS#12 Truststore. Adding or deleting a single > > file instead of replacing the complete PKCS#12 store is less error > > prone and cleaner to track in version control. The additional benefit > > of a MAC in PKCS#12 adds little to no security in most cases. > > And being text based, PEM is more version control friendly than binary PKCS#12. > > > > But to enable sound support of PEM, I also implemented writing PEM > > keys and certificates. This way, one can use the JDK keytool to > > generate key and certificate signing requests in PEM format. Getting > > the certificate from the CA in PEM, one can use PEM throughout the > > process. > > > > Do you have any links or documentation on the PEM API JEP that you mentioned? > > > > Thank you for your feedback and best regards > > > > Karl > > > > Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony Scarpino > > : > >> > >> Hi Karl > >> > >> The keystore is interesting and may have some value. Was your use case > >> mostly reading PEM keys and certificates generated elsewhere for use > >> with a particular application, maybe webservers? Did you see value in > >> writing to this keystore from Java? > >> > >> On the topic of PEM, I hope before the end of the year to have a PEM API > >> JEP. I would be interested in your API feedback from your keystore > >> experiences. I think if this keystore contribution was accepted, it > >> should wait so it can use that API. > >> > >> thanks > >> > >> Tony > >> > >> > >> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote: > >>> Hi, > >>> > >>> Working with Java and the JCA KeyStore for decades, I came across > >>> many situations where I thought it would be convenient to be > >>> able to load private keys and certificates in PEM format directly > >>> using the KeyStore API. Without the need to convert them to PKCS#12/JKS. > >>> > >>> You can find my implementation of a PEM KeyStore in > >>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ . > >>> > >>> I wondered if it would make sense to integrate such an implementation > >>> in one of the standard providers of OpenJDK - like the SUN provider. > >>> What do you think? > >>> > >>> Best regards > >>> > >>> Karl From dfuchs at openjdk.org Wed Sep 20 11:26:46 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 20 Sep 2023 11:26:46 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v6] In-Reply-To: References: Message-ID: <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com> On Tue, 19 Sep 2023 20:51:41 GMT, Tim Prinzing wrote: > The existing JFR tests TestSocketChannelEvents and TestSocketEvents in jdk.jfr.event.io verify the events are still emitted as expected. Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1727528861 From alanb at openjdk.org Wed Sep 20 11:26:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 20 Sep 2023 11:26:47 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v6] In-Reply-To: <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com> References: <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com> Message-ID: <8dq0EZ2nZuSs-fQhlpSODsL6J_5ueLLBYK4tQy3EHTo=.bb1aa2d6-a760-4857-9671-b530d0aa4883@github.com> On Wed, 20 Sep 2023 11:21:51 GMT, Daniel Fuchs wrote: > Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests? I don't think so as these tests are just used to check that changes haven't broken anything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1727532006 From tprinzing at openjdk.org Wed Sep 20 12:37:02 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 20 Sep 2023 12:37:02 GMT Subject: Integrated: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk This pull request has now been integrated. Changeset: b275bdd9 Author: Tim Prinzing Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/b275bdd9b55b567cfe60c389d5ef8b70615928f4 Stats: 906 lines in 13 files changed: 519 ins; 379 del; 8 mod 8308995: Update Network IO JFR events to be static mirror events Reviewed-by: egahlin, alanb ------------- PR: https://git.openjdk.org/jdk/pull/14342 From mpowers at openjdk.org Wed Sep 20 15:10:14 2023 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 20 Sep 2023 15:10:14 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData Message-ID: https://bugs.openjdk.org/browse/JDK-8315042 ------------- Commit messages: - first iteration Changes: https://git.openjdk.org/jdk/pull/15844/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15844&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315042 Stats: 23 lines in 2 files changed: 16 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15844.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15844/head:pull/15844 PR: https://git.openjdk.org/jdk/pull/15844 From mpowers at openjdk.org Wed Sep 20 15:29:39 2023 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 20 Sep 2023 15:29:39 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 23:55:09 GMT, Valerie Peng wrote: >> Such a change would apply NSS version number checks to `TestNssDbSqlite` which currently doesn't have them. But wait! If `TestNssDbSqlite` has been running for years on all NSS versions, then it should be safe to make sqlite the default for all tests. > > Yes, for new NSS releases, it should be safe to set sqlite to true by default. The tests which relies on sqlite like `TestNssDbSqlite` can always call useSqlite(true) regardless of default. @valeriepeng Thanks for the review! I'll set sqlite to true by default and retest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15644#discussion_r1331809271 From duke at openjdk.org Wed Sep 20 15:43:48 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 20 Sep 2023 15:43:48 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 06:02:52 GMT, Valerie Peng wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Added test to check that when keystore.type is null it defaults to pkcs12 > > test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023 Oracle and/or its affiliates. All rights reserved. > > Where did you get the copyright from? IIRC, there should be a coma after the year and also copyright for the test file should not have the "Classpath" thing. I copied it from the CheckDefaults test - is there a more up to date one I should be using? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1331829846 From duke at openjdk.org Wed Sep 20 15:52:26 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 20 Sep 2023 15:52:26 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v4] In-Reply-To: References: Message-ID: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Changed test description, fixed indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15625/files - new: https://git.openjdk.org/jdk/pull/15625/files/26978443..6bd599c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=02-03 Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15625/head:pull/15625 PR: https://git.openjdk.org/jdk/pull/15625 From duke at openjdk.org Wed Sep 20 15:52:30 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 20 Sep 2023 15:52:30 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 06:08:11 GMT, Valerie Peng wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Added test to check that when keystore.type is null it defaults to pkcs12 > > test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 34: > >> 32: * KeyStore.getDefaultType() value is related to property value. Expect a full >> 33: * match the value 'keystore.type' and the value of the >> 34: * KeyStore.getDefaultType() > > I don't quite get the summary... Actually the test does not set any value to the "keystore.type" property. Thus, it seems a little strange to expect a full match to KeyStore.getDefaultType()? Changed to "Set keystore.type as null and check that KeyStore.getDefaultType() returns pkcs12" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1331836703 From karl.scheibelhofer.75 at gmail.com Fri Sep 1 14:58:09 2023 From: karl.scheibelhofer.75 at gmail.com (Karl Scheibelhofer) Date: Fri, 01 Sep 2023 14:58:09 -0000 Subject: PEM KeyStore Implementation Message-ID: Hi, Working with Java and the JCA KeyStore for many years, I came across many situations where I thought it would be really convenient to be able to load private keys and certificates in PEM format directly using the KeyStore API. Since I found no implementation I developed my own. You can find it in https://github.com/KarlScheibelhofer/java-crypto-tools. I wondered if it would make sense to integrate such an implementation in one of the standard providers of OpenJDK - like the SUN provider. What do you think? Best regards Karl Scheibelhofer From valeriep at openjdk.org Wed Sep 20 17:15:42 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 20 Sep 2023 17:15:42 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 15:00:28 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8315042 test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 2: > 1: /* > 2: * Copyright (c) 2004, 2023 Oracle and/or its affiliates. All rights reserved. missing a coma after 2023. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1331952408 From valeriep at openjdk.org Wed Sep 20 17:59:43 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 20 Sep 2023 17:59:43 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v3] In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 15:40:47 GMT, Ben Perez wrote: >> test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2023 Oracle and/or its affiliates. All rights reserved. >> >> Where did you get the copyright from? IIRC, there should be a coma after the year and also copyright for the test file should not have the "Classpath" thing. > > I copied it from the CheckDefaults test - is there a more up to date one I should be using? You can check around tests under the same directory for references. There is a recent fix which sweep through copyright typos and `CheckDefaults` happen to be one of them. You had the old one here and should be updated. Besides there is always a coma after the year convention-wise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1331998085 From weijun.wang at oracle.com Wed Sep 20 18:06:12 2023 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 20 Sep 2023 18:06:12 +0000 Subject: KrbException exception does not contain error string although error is well-known In-Reply-To: <4d81f4c8-d2a1-45c2-898a-a918f5ddc6ba@siemens.com> References: <4d81f4c8-d2a1-45c2-898a-a918f5ddc6ba@siemens.com> Message-ID: I'll look into it. Thanks! Do you have a patch? :-) --Max > On Aug 9, 2023, at 3:30 AM, Osipov, Michael (SMD IT IN) wrote: > > Folks, Max, > > consider the following code snippet configured with the Krb5LoginModule: >> LoginContext lc = new LoginContext(loginEntryName); >> lc.login(); > > then a LoginException is thrown with the following stacktrace: >> 2023-08-01T00:09:31.601 SCHWERWIEGEND [https-openssl-apr-8444-exec-5417] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal Exception acquiring directory server connection >> javax.naming.NamingException: null (29) [Root exception is javax.security.auth.login.LoginException: null (29)] >> at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:625) >> at net.sf.michaelo.dirctxsrc.DirContextSource.getDirContext(DirContextSource.java:685) >> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.open(ActiveDirectoryRealm.java:572) >> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.acquire(ActiveDirectoryRealm.java:506) >> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:432) >> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:461) >> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:426) >> at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:497) >> at net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator.doAuthenticate(SpnegoAuthenticator.java:163) >> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:564) >> ... >> at java.lang.Thread.run(Thread.java:750) >> Caused by: javax.security.auth.login.LoginException: null (29) >> at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:810) >> at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) >> at sun.reflect.GeneratedMethodAccessor10719.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) >> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) >> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) >> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) >> at java.security.AccessController.doPrivileged(Native Method) >> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) >> at javax.security.auth.login.LoginContext.login(LoginContext.java:587) >> at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:574) >> ... 23 more >> Caused by: KrbException: null (29) >> at sun.security.krb5.KrbAsRep.(KrbAsRep.java:76) >> at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:335) >> at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:488) >> at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:782) >> ... 35 more >> Caused by: KrbException: Identifier doesn't match expected value (906) >> at sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) >> at sun.security.krb5.internal.ASRep.init(ASRep.java:64) >> at sun.security.krb5.internal.ASRep.(ASRep.java:59) >> at sun.security.krb5.KrbAsRep.(KrbAsRep.java:60) >> ... 38 more > > I am trying to obtain a TGT to authenticate thorugh SASL GSSAPI to Active Directory via LDAP. This happened to me now repeatedly in the last couple of days around midnight. Looking up error code 29 says KDC_ERR_SVC_UNAVAILABLE, obviously the AD DC server is maintenance mode. What bugs me is that KDC_ERR_SVC_UNAVAILABLE(29) is documented in Krb5.java, has an error message and KrbException.java does use it, but no error message is mapped to the code. > > Request: Maybe someone (Max?) log an improvement request with JBS to > add missing error codes 26--28, 51 from [1] and > > public static final int KRB_AP_ERR_NOREALM = 62; > > public static final int KRB_AP_ERR_GEN_CRED = 63; > > look incorrect. Plus the mapping in errMsgList for those. > > Note: Tried with OpenJDK 8. > > Best regards, > > Michael > > [1] https://www.rfc-editor.org/rfc/rfc4120#section-7.5.9 From mullan at openjdk.org Wed Sep 20 19:02:46 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 20 Sep 2023 19:02:46 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v4] In-Reply-To: References: Message-ID: <7BdfBMICMs5hlWwi83BFD-Z_5GBIf0Bg_8KdtPDBrLI=.7b5a4fb3-c63e-4c92-b166-80cdd653eefa@github.com> On Wed, 20 Sep 2023 15:52:26 GMT, Ben Perez wrote: >> Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed test description, fixed indentation test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 34: > 32: * KeyStore.getDefaultType() returns pkcs12 > 33: * @run main/othervm CheckDefaults > 34: * -Djava.security.properties=./java.security It is probably safer to specify the path as `${test.src}/java.security` here. Also, I typically put the JVM arguments before the test name, so `@run main/othervm -Djava.security.properties=${test.src}/java.security CheckDefaults` test/jdk/java/security/KeyStore/PKCS12/CheckNullDefault.java line 38: > 36: public class CheckNullDefault { > 37: private static final String DEFAULT_KEY_STORE_TYPE = "pkcs12"; > 38: private void runTest(String[] args) { The `runTest` method seems unnecessary. I think you can write this test entirely within the `static main` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1332055771 PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1332058211 From mullan at openjdk.org Wed Sep 20 20:00:08 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 20 Sep 2023 20:00:08 GMT Subject: RFR: 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 Message-ID: Please review this change to ensure this test is tested on different TLS protocols (1.0, 1.1, 1.2) I added a protocol parameter to the test arguments so that different protocols are tested. I also removed the boolean exportable argument as it wasn't doing anything. ------------- Commit messages: - Changed tests so that they test all 3 applicable protocols (1.0, 1.1, 1.2). Changes: https://git.openjdk.org/jdk/pull/15846/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15846&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313229 Stats: 30 lines in 1 file changed: 4 ins; 4 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/15846.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15846/head:pull/15846 PR: https://git.openjdk.org/jdk/pull/15846 From jnimeh at openjdk.org Wed Sep 20 20:16:40 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 20 Sep 2023 20:16:40 GMT Subject: RFR: 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 19:51:28 GMT, Sean Mullan wrote: > Please review this change to ensure this test is tested on different TLS protocols (1.0, 1.1, 1.2) > > I added a protocol parameter to the test arguments so that different protocols are tested. I also removed the boolean exportable argument as it wasn't doing anything. test/jdk/sun/security/ssl/DHKeyExchange/DHEKeySizing.java line 35: > 33: * @library /javax/net/ssl/templates > 34: * @run main/othervm -Djdk.tls.client.enableSessionTicketExtension=false > 35: * DHEKeySizing TLS_DHE_RSA_WITH_AES_128_CBC_SHA 1645 267 TLSv1 Just curious why the server key exchange length went up in size by a couple bytes. Was 1643 incorrect before this change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15846#discussion_r1332124810 From valeriep at openjdk.org Wed Sep 20 22:05:08 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 20 Sep 2023 22:05:08 GMT Subject: RFR: 8315944: SunJCE provider should not zeroize the deserialized key values Message-ID: This PR reverts part of the changes under JDK-8312306 which zero-out the deserialized key bytes after an internal copy has been made. If considering the deserialized key bytes as input arguments, such cleaning action may be too aggressive. Thus, on second thought, I am reverting to earlier behavior. No regression test since the changes are trivial. Thanks! Valerie ------------- Commit messages: - 8315944: SunJCE provider should not zeroize the deserialized key values Changes: https://git.openjdk.org/jdk/pull/15848/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15848&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315944 Stats: 12 lines in 3 files changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15848.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15848/head:pull/15848 PR: https://git.openjdk.org/jdk/pull/15848 From valeriep at openjdk.org Wed Sep 20 22:18:40 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 20 Sep 2023 22:18:40 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 19:41:47 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8296631 Just curious, there are already test/jdk/sun/security/pkcs11/Secmod/cert9.db and test/jdk/sun/security/pkcs11/Secmod/key4.db, what are the reasons for updating them? Since it's binary file, I can't tell what changes they are for... In addition, do we need to check all PKCS11 tests which have key3.db and cert8.db and add corresponding key4.db/cert9.db? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15644#issuecomment-1728497094 From mpowers at openjdk.org Thu Sep 21 00:34:49 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 21 Sep 2023 00:34:49 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 19:41:47 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8296631 Without updating `Secmod/cert9.db` and `Secmod/key4.db`, both `Secmod/JksSetPrivateKey` and `Secmod/GetPrivateKey` will fail. The old values must have been incorrect. This was not noticed because `cert8.db` and `key3.db` were used if there were a `libnssdbm3` on the machine. In OL9, there is no `libnssdbm3`, so the failures appeared. Regarding your second question, every `cert8/key3` pair has a `cert9/key4` pair except for `pkcs11/tls` tests which only have `cert8/key3`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15644#issuecomment-1728593341 From ihse at openjdk.org Thu Sep 21 09:20:52 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 21 Sep 2023 09:20:52 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 8 Aug 2023 19:57:12 GMT, Thomas Stuefe wrote: >> Julian Waters 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 22 additional commits since the last revision: >> >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - Earlier fix in awt_ole.h was not complete >> - Merge branch 'openjdk:master' into patch-10 >> - Likewise for awt_Frame.cpp >> - ... and 12 more: https://git.openjdk.org/jdk/compare/3ab6ec2a...51230f3d > > src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 216: > >> 214: { >> 215: PDATA pData; >> 216: JNI_CHECK_PEER_GOTO(canvas, ret); > > Here, and other places: why this scope? ~~I am curious about this, too. What aspect of the code is different from the pedantic compiler perspective?~~ edit: Found the answer further down in the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1332748161 From ihse at openjdk.org Thu Sep 21 09:20:55 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 21 Sep 2023 09:20:55 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v5] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 8 Aug 2023 19:59:52 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into patch-10 >> - Document changes in awt_DnDDS.cpp >> - Remove negation in os_windows.cpp >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - ... and 15 more: https://git.openjdk.org/jdk/compare/11d431b2...1d3d6b5e > > src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 34: > >> 32: #include "sun_awt_windows_WDropTargetContextPeer.h" >> 33: #include "awt_Container.h" >> 34: #include "awt_ole.h" > > Why? Is this related to the `#define malloc Do_Not_Use_Malloc` issue? If so, the required ordering of includes should be documented here as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1332749949 From ihse at openjdk.org Thu Sep 21 09:32:54 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 21 Sep 2023 09:32:54 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 14 Sep 2023 03:23:55 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Document changes in awt_DnDDS.cpp > > Pinging @TheShermanTanker In my experience, getting reviews from all areas for issues like this that cuts through the entire JDK can be difficult. Another approach, which requires more work from your side, but hopefully less from the reviewers' (and thus makes it easier for them to review) is to split this PR into multiple ones: One for each area (basically, area == mailing list) that just makes the changes to the code necessary to (in the future) turn on /permissive-. And then finally a small "finishing" PR which just touches the makefile and enables the flag, when all code is fixed. As a side effect, it is also 100% clear that all parts of the code has been correctly reviewed, since then reviewers do not need to leave conditions on their reviews ("i only looked at the foo parts"). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1729204060 From duke at openjdk.org Thu Sep 21 12:53:11 2023 From: duke at openjdk.org (Michal Sobierski) Date: Thu, 21 Sep 2023 12:53:11 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests Message-ID: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. Comparison of before and after parallelization: time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" before: 270.72s user 4.88s system 108% cpu 4:14.43 total after: 410.76s user 7.50s system 555% cpu 1:15.23 total time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" before: 63.67s user 4.67s system 161% cpu 42.424 total after: 130.36s user 7.47s system 585% cpu 23.526 total time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" before: 281.99s user 5.54s system 108% cpu 4:24.09 total after: 386.98s user 8.62s system 496% cpu 1:19.73 total time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" before: 65.86s user 5.05s system 156% cpu 45.215 total after: 135.90s user 7.66s system 585% cpu 24.502 total ------------- Commit messages: - 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests Changes: https://git.openjdk.org/jdk/pull/15860/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15860&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316415 Stats: 97 lines in 1 file changed: 80 ins; 13 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15860.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15860/head:pull/15860 PR: https://git.openjdk.org/jdk/pull/15860 From duke at openjdk.org Thu Sep 21 13:26:14 2023 From: duke at openjdk.org (Michal Sobierski) Date: Thu, 21 Sep 2023 13:26:14 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: > sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. > > Comparison of before and after parallelization: > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" > before: 270.72s user 4.88s system 108% cpu 4:14.43 total > after: 410.76s user 7.50s system 555% cpu 1:15.23 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" > before: 63.67s user 4.67s system 161% cpu 42.424 total > after: 130.36s user 7.47s system 585% cpu 23.526 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" > before: 281.99s user 5.54s system 108% cpu 4:24.09 total > after: 386.98s user 8.62s system 496% cpu 1:19.73 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" > before: 65.86s user 5.05s system 156% cpu 45.215 total > after: 135.90s user 7.66s system 585% cpu 24.502 total Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: Better approach to parallelize sun/security/rsa/SignedObjectChain.java time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" before: 270.72s user 4.88s system 108% cpu 4:14.43 total after: 375.46s user 4.59s system 539% cpu 1:10.41 total time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" before: 63.67s user 4.67s system 161% cpu 42.424 total after: 67.31s user 4.48s system 417% cpu 17.183 total time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" before: 281.99s user 5.54s system 108% cpu 4:24.09 total after: 413.51s user 5.08s system 613% cpu 1:08.25 total time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" before: 65.86s user 5.05s system 156% cpu 45.215 total after: 83.25s user 4.82s system 469% cpu 18.741 total ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15860/files - new: https://git.openjdk.org/jdk/pull/15860/files/e6d9a0f7..0040ba31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15860&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15860&range=00-01 Stats: 95 lines in 1 file changed: 12 ins; 78 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15860.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15860/head:pull/15860 PR: https://git.openjdk.org/jdk/pull/15860 From mullan at openjdk.org Thu Sep 21 13:29:10 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 21 Sep 2023 13:29:10 GMT Subject: RFR: 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 [v2] In-Reply-To: References: Message-ID: > Please review this change to ensure this test is tested on different TLS protocols (1.0, 1.1, 1.2) > > I added a protocol parameter to the test arguments so that different protocols are tested. I also removed the boolean exportable argument as it wasn't doing anything. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Only adjust sever hello size for TLS_DHE_RSA_WITH_AES_128_CBC_SHA with TLSv1.2. Fix some typos. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15846/files - new: https://git.openjdk.org/jdk/pull/15846/files/8068ea61..8a36dbf5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15846&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15846&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15846.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15846/head:pull/15846 PR: https://git.openjdk.org/jdk/pull/15846 From mullan at openjdk.org Thu Sep 21 13:32:43 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 21 Sep 2023 13:32:43 GMT Subject: RFR: 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 [v2] In-Reply-To: References: Message-ID: <0_-aTuwwNgdIgEqYVdifn1YF-2f3u6IiVkhEIprB6oI=.81c3ec13-46db-4c53-a760-1e928460a47e@github.com> On Wed, 20 Sep 2023 20:13:35 GMT, Jamil Nimeh wrote: >> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: >> >> Only adjust sever hello size for TLS_DHE_RSA_WITH_AES_128_CBC_SHA with TLSv1.2. >> Fix some typos. > > test/jdk/sun/security/ssl/DHKeyExchange/DHEKeySizing.java line 35: > >> 33: * @library /javax/net/ssl/templates >> 34: * @run main/othervm -Djdk.tls.client.enableSessionTicketExtension=false >> 35: * DHEKeySizing TLS_DHE_RSA_WITH_AES_128_CBC_SHA 1645 267 TLSv1 > > Just curious why the server key exchange length went up in size by a couple bytes. Was 1643 incorrect before this change? Good question. Part of this is a cut-and-paste error. The only change to 1645 bytes should be for line 64. The previous version of this test used TLS 1.0 for all the tests. When testing this on different protocols, I noticed the server hello for this cipher suite takes 2 extra bytes on TLSv1.2, and this was enough to cause the test to fail even with the 6 extra bytes for KEY_LEN_BIAS. - I don't know the exact reason why it takes a few extra bytes though. I fixed this in the latest commit - only line 64 should be different now for the server hello length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15846#discussion_r1333060926 From shade at openjdk.org Thu Sep 21 13:39:43 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Sep 2023 13:39:43 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: On Thu, 21 Sep 2023 13:26:14 GMT, Michal Sobierski wrote: >> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. >> >> Comparison of before and after parallelization: >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" >> before: 270.72s user 4.88s system 108% cpu 4:14.43 total >> after: 410.76s user 7.50s system 555% cpu 1:15.23 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" >> before: 63.67s user 4.67s system 161% cpu 42.424 total >> after: 130.36s user 7.47s system 585% cpu 23.526 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" >> before: 281.99s user 5.54s system 108% cpu 4:24.09 total >> after: 386.98s user 8.62s system 496% cpu 1:19.73 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> before: 65.86s user 5.05s system 156% cpu 45.215 total >> after: 135.90s user 7.66s system 585% cpu 24.502 total > > Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: > > Better approach to parallelize sun/security/rsa/SignedObjectChain.java > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" > before: 270.72s user 4.88s system 108% cpu 4:14.43 total > after: 375.46s user 4.59s system 539% cpu 1:10.41 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC" > before: 63.67s user 4.67s system 161% cpu 42.424 total > after: 67.31s user 4.48s system 417% cpu 17.183 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" > before: 281.99s user 5.54s system 108% cpu 4:24.09 total > after: 413.51s user 5.08s system 613% cpu 1:08.25 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC" > before: 65.86s user 5.05s system 156% cpu 45.215 total > after: 83.25s user 4.82s system 469% cpu 18.741 total Looks nice. A few stylistic comments: test/jdk/sun/security/rsa/SignedObjectChain.java line 58: > 56: boolean result = Arrays.stream(tests).parallel().allMatch(Chain::runTest); > 57: > 58: if(result) { Suggestion: if (result) { test/jdk/sun/security/rsa/SignedObjectChain.java line 65: > 63: } > 64: } > 65: Do we need a newline here? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15860#pullrequestreview-1637857260 PR Review Comment: https://git.openjdk.org/jdk/pull/15860#discussion_r1333071875 PR Review Comment: https://git.openjdk.org/jdk/pull/15860#discussion_r1333072133 From shade at openjdk.org Thu Sep 21 14:08:41 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Sep 2023 14:08:41 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: On Thu, 21 Sep 2023 13:26:14 GMT, Michal Sobierski wrote: >> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. >> >> Comparison of before and after parallelization: >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" >> before: 270.72s user 4.88s system 108% cpu 4:14.43 total >> after: 410.76s user 7.50s system 555% cpu 1:15.23 total >> after second commit: 375.46s user 4.59s system 539% cpu 1:10.41 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" >> before: 63.67s user 4.67s system 161% cpu 42.424 total >> after: 130.36s user 7.47s system 585% cpu 23.526 total >> after second commit: 67.31s user 4.48s system 417% cpu 17.183 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" >> before: 281.99s user 5.54s system 108% cpu 4:24.09 total >> after: 386.98s user 8.62s system 496% cpu 1:19.73 total >> after second commit: 413.51s user 5.08s system 613% cpu 1:08.25 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> before: 65.86s user 5.05s system 156% cpu 45.215 total >> after: 135.90s user 7.66s system 585% cpu 24.502 total >> after second commit: 83.25s user 4.82s system 469% cpu 18.741 total > > Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: > > Better approach to parallelize sun/security/rsa/SignedObjectChain.java > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" > before: 270.72s user 4.88s system 108% cpu 4:14.43 total > after: 375.46s user 4.59s system 539% cpu 1:10.41 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC" > before: 63.67s user 4.67s system 161% cpu 42.424 total > after: 67.31s user 4.48s system 417% cpu 17.183 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" > before: 281.99s user 5.54s system 108% cpu 4:24.09 total > after: 413.51s user 5.08s system 613% cpu 1:08.25 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC" > before: 65.86s user 5.05s system 156% cpu 45.215 total > after: 83.25s user 4.82s system 469% cpu 18.741 total Shows a very good improvement here as well: % time CONF=linux-x86_64-server-fastdebug make test TEST=sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:TieredStopAtLevel=1" Baseline: CONF=linux-x86_64-server-fastdebug make test 333.34s user 5.04s system 111% cpu 5:02.33 total CONF=linux-x86_64-server-fastdebug make test 292.03s user 5.27s system 114% cpu 4:20.71 total CONF=linux-x86_64-server-fastdebug make test 330.51s user 5.23s system 111% cpu 5:00.18 total Patched: CONF=linux-x86_64-server-fastdebug make test 309.72s user 4.92s system 505% cpu 1:02.25 total CONF=linux-x86_64-server-fastdebug make test 275.63s user 5.02s system 540% cpu 51.82 total CONF=linux-x86_64-server-fastdebug make test 299.18s user 5.06s system 546% cpu 55.64 total ------------- PR Comment: https://git.openjdk.org/jdk/pull/15860#issuecomment-1729655487 From weijun at openjdk.org Thu Sep 21 14:34:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 21 Sep 2023 14:34:40 GMT Subject: RFR: 8315944: SunJCE provider should not zeroize the deserialized key values In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 21:56:50 GMT, Valerie Peng wrote: > This PR reverts part of the changes under JDK-8312306 which zero-out the deserialized key bytes after an internal copy has been made. If considering the deserialized key bytes as input arguments, such cleaning action may be too aggressive. Thus, on second thought, I am reverting to earlier behavior. No regression test since the changes are trivial. > > Thanks! > Valerie Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15848#pullrequestreview-1637998897 From mpowers at openjdk.org Thu Sep 21 15:40:22 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 21 Sep 2023 15:40:22 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8296631 Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge - comment from Valerie - second iteration - Merge - first iteration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15644/files - new: https://git.openjdk.org/jdk/pull/15644/files/3885f00a..1439d191 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15644&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15644&range=00-01 Stats: 76304 lines in 2157 files changed: 24515 ins; 18737 del; 33052 mod Patch: https://git.openjdk.org/jdk/pull/15644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15644/head:pull/15644 PR: https://git.openjdk.org/jdk/pull/15644 From duke at openjdk.org Thu Sep 21 15:55:24 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 21 Sep 2023 15:55:24 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v5] In-Reply-To: References: Message-ID: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Fixed copyright, refactored test to get rid of runTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15625/files - new: https://git.openjdk.org/jdk/pull/15625/files/6bd599c8..f9433dff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=03-04 Stats: 15 lines in 1 file changed: 0 ins; 8 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15625/head:pull/15625 PR: https://git.openjdk.org/jdk/pull/15625 From mpowers at openjdk.org Thu Sep 21 16:03:05 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 21 Sep 2023 16:03:05 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8315042 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: comment from Valerie ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15844/files - new: https://git.openjdk.org/jdk/pull/15844/files/28c6ce20..6e7176fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15844&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15844&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15844.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15844/head:pull/15844 PR: https://git.openjdk.org/jdk/pull/15844 From weijun at openjdk.org Thu Sep 21 16:15:45 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 21 Sep 2023 16:15:45 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 16:03:05 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8315042 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > comment from Valerie test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 1: > 1: /* I would suggest write a new test, and you can use the `Utils.runAndCheckException` to make it simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1333314129 From jnimeh at openjdk.org Thu Sep 21 17:01:45 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 21 Sep 2023 17:01:45 GMT Subject: RFR: 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 [v2] In-Reply-To: <0_-aTuwwNgdIgEqYVdifn1YF-2f3u6IiVkhEIprB6oI=.81c3ec13-46db-4c53-a760-1e928460a47e@github.com> References: <0_-aTuwwNgdIgEqYVdifn1YF-2f3u6IiVkhEIprB6oI=.81c3ec13-46db-4c53-a760-1e928460a47e@github.com> Message-ID: On Thu, 21 Sep 2023 13:30:07 GMT, Sean Mullan wrote: >> test/jdk/sun/security/ssl/DHKeyExchange/DHEKeySizing.java line 35: >> >>> 33: * @library /javax/net/ssl/templates >>> 34: * @run main/othervm -Djdk.tls.client.enableSessionTicketExtension=false >>> 35: * DHEKeySizing TLS_DHE_RSA_WITH_AES_128_CBC_SHA 1645 267 TLSv1 >> >> Just curious why the server key exchange length went up in size by a couple bytes. Was 1643 incorrect before this change? > > Good question. Part of this is a cut-and-paste error. The only change to 1645 bytes should be for line 64. The previous version of this test used TLS 1.0 for all the tests. When testing this on different protocols, I noticed the server hello for this cipher suite takes 2 extra bytes on TLSv1.2, and this was enough to cause the test to fail even with the 6 extra bytes for KEY_LEN_BIAS. - I don't know the exact reason why it takes a few extra bytes though. > > I fixed this in the latest commit - only line 64 should be different now for the server hello length. An extra two bytes for a server hello could be due to the assertion of a SH extension that was not asserted in earlier versions of the protocol or something along those lines. Since that 1645 bytes relates to "Server Hello Series" (I assume that means the entire SH flight of messages) there could be a two-byte variance in a number of places. The fix looks good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15846#discussion_r1333365888 From jnimeh at openjdk.org Thu Sep 21 17:01:41 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 21 Sep 2023 17:01:41 GMT Subject: RFR: 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 [v2] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 13:29:10 GMT, Sean Mullan wrote: >> Please review this change to ensure this test is tested on different TLS protocols (1.0, 1.1, 1.2) >> >> I added a protocol parameter to the test arguments so that different protocols are tested. I also removed the boolean exportable argument as it wasn't doing anything. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Only adjust sever hello size for TLS_DHE_RSA_WITH_AES_128_CBC_SHA with TLSv1.2. > Fix some typos. LGTM ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15846#pullrequestreview-1638329315 From mpowers at openjdk.org Thu Sep 21 17:28:43 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 21 Sep 2023 17:28:43 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 16:12:47 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> comment from Valerie > > test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 1: > >> 1: /* > > I would suggest write a new test, and you can use the `Utils.runAndCheckException` to make it simpler. I can do that. My primary motivation for using the existing test was that `UnexpectedNPE.java` is the perfect name for my test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1333391229 From mullan at openjdk.org Thu Sep 21 17:34:48 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 21 Sep 2023 17:34:48 GMT Subject: Integrated: 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 In-Reply-To: References: Message-ID: <5ij2TrNjUhp3NHU7yb0a_aTLRwCgQ0b7zRYvcXeUf0U=.cb938f22-66f4-4a43-a51c-c1045b62bbba@github.com> On Wed, 20 Sep 2023 19:51:28 GMT, Sean Mullan wrote: > Please review this change to ensure this test is tested on different TLS protocols (1.0, 1.1, 1.2) > > I added a protocol parameter to the test arguments so that different protocols are tested. I also removed the boolean exportable argument as it wasn't doing anything. This pull request has now been integrated. Changeset: c698b45a Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/c698b45a7bcb0eedeed979d482f8ab15cf16baaa Stats: 31 lines in 1 file changed: 4 ins; 4 del; 23 mod 8313229: DHEKeySizing.java should be modified to use TLS versions TLSv1, TLSv1.1, TLSv1.2 Reviewed-by: jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/15846 From mullan at openjdk.org Thu Sep 21 19:10:41 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 21 Sep 2023 19:10:41 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v5] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 15:55:24 GMT, Ben Perez wrote: >> Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright, refactored test to get rid of runTest test/jdk/java/security/KeyStore/PKCS12/java.security line 2: > 1: # do not set keystore.type property, so default value will be used > 2: #keystore.type= I think this should not be commented out, otherwise you are still getting the `keystore.type=pkcs12` setting from the `java.security` file in the JDK. To make sure this is working, try temporarily setting this to "foobar" or something random and see if the test fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1333494954 From valeriep at openjdk.org Thu Sep 21 19:18:56 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 21 Sep 2023 19:18:56 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 17:25:34 GMT, Mark Powers wrote: >> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 1: >> >>> 1: /* >> >> I would suggest write a new test, and you can use the `Utils.runAndCheckException` to make it simpler. > > I can do that. My primary motivation for using the existing test was that `UnexpectedNPE.java` is the perfect name for my test. Why not just updating UnexpectedNPE test with `Utils.runAndCheckException` calls? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1333501852 From duke at openjdk.org Thu Sep 21 19:43:29 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 21 Sep 2023 19:43:29 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v6] In-Reply-To: References: Message-ID: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Changed @run arguments to completely override java.security ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15625/files - new: https://git.openjdk.org/jdk/pull/15625/files/f9433dff..2dd1b2fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15625&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15625/head:pull/15625 PR: https://git.openjdk.org/jdk/pull/15625 From duke at openjdk.org Thu Sep 21 19:46:15 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 21 Sep 2023 19:46:15 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v5] In-Reply-To: References: Message-ID: <_xhxUIEq1j-Wx854cNCyYfHniJKfIUJOm48q6_WgSMc=.b90d2143-a64a-48e2-9c20-8b4211d3d194@github.com> On Thu, 21 Sep 2023 19:08:16 GMT, Sean Mullan wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright, refactored test to get rid of runTest > > test/jdk/java/security/KeyStore/PKCS12/java.security line 2: > >> 1: # do not set keystore.type property, so default value will be used >> 2: #keystore.type= > > I think this should not be commented out, otherwise you are still getting the `keystore.type=pkcs12` setting from the `java.security` file in the JDK. To make sure this is working, try temporarily setting this to "foobar" or something random and see if the test fails. Good catch - uncommenting did in fact break the test. To fix, I changed the `@run` flag to be `-Djava.security.properties==${test.src}/java.security CheckDefaults`. By using `==` as opposed to `=` the java.security file is completely overwritten ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15625#discussion_r1333527691 From abakhtin at openjdk.org Thu Sep 21 22:20:12 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Thu, 21 Sep 2023 22:20:12 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method [v2] In-Reply-To: <_NuXb0JAz7W1LzTmNQqxrBr8luIeIk1NdXwikbi4254=.3fad487f-41ab-4862-9075-0418893fc100@github.com> References: <_NuXb0JAz7W1LzTmNQqxrBr8luIeIk1NdXwikbi4254=.3fad487f-41ab-4862-9075-0418893fc100@github.com> Message-ID: On Thu, 24 Aug 2023 21:24:51 GMT, Alexey Bakhtin wrote: >> JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. >> >> This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Rename system property CSR is submitted: https://bugs.openjdk.org/browse/JDK-8315562 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1730372031 From wetmore at openjdk.org Fri Sep 22 00:26:16 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 22 Sep 2023 00:26:16 GMT Subject: RFR: 8315944: SunJCE provider should not zeroize the deserialized key values In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 21:56:50 GMT, Valerie Peng wrote: > This PR reverts part of the changes under JDK-8312306 which zero-out the deserialized key bytes after an internal copy has been made. If considering the deserialized key bytes as input arguments, such cleaning action may be too aggressive. Thus, on second thought, I am reverting to earlier behavior. No regression test since the changes are trivial. > > Thanks! > Valerie I would like to research/understand the reachabilityFence stuff a bit more, but if you need to get this in, this is ok with me. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15848#pullrequestreview-1638900785 From jwaters at openjdk.org Fri Sep 22 02:30:25 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 22 Sep 2023 02:30:25 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 14 Sep 2023 03:23:55 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Document changes in awt_DnDDS.cpp > > Pinging > @TheShermanTanker In my experience, getting reviews from all areas for issues like this that cuts through the entire JDK can be difficult. Another approach, which requires more work from your side, but hopefully less from the reviewers' (and thus makes it easier for them to review) is to split this PR into multiple ones: One for each area (basically, area == mailing list) that just makes the changes to the code necessary to (in the future) turn on /permissive-. And then finally a small "finishing" PR which just touches the makefile and enables the flag, when all code is fixed. > > As a side effect, it is also 100% clear that all parts of the code has been correctly reviewed, since then reviewers do not need to leave conditions on their reviews ("i only looked at the foo parts"). I understand, will split this into multiple changes after I answer all queries above ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1730719188 From weijun at openjdk.org Fri Sep 22 13:06:12 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 22 Sep 2023 13:06:12 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 19:15:52 GMT, Valerie Peng wrote: >> I can do that. My primary motivation for using the existing test was that `UnexpectedNPE.java` is the perfect name for my test. > > Why not just updating UnexpectedNPE test with `Utils.runAndCheckException` calls? I was just thinking the tests are quite different. Now I re-read it and maybe we can change the old code to call `generateCRLs` as well. The existing `encoded_x` are very simple and only invalid SEQUENCES, which is not at the level of X.509 or PKCS7. Therefore I'm OK with reusing this test without the `generateCRL` flag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1334351960 From egahlin at openjdk.org Fri Sep 22 13:06:34 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 22 Sep 2023 13:06:34 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v6] In-Reply-To: References: Message-ID: <5tdptBPPCTyNYn8wbZ1_bN52j8C-YRkWpmMksczutQs=.2700421a-3722-4d42-b186-482e38dba8d7@github.com> On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into JDK-8308995 > - More changes from review: > > I didn't like the name of the helper method 'checkForCommit' because it > doesn't indicate that it might commit the event. I also don't like > 'commitEvent' because it might not. Since JFR events are sort of like a > queue I went with a name from collections and called it 'offer' so using > it is something like 'SocketReadEvent.offer(...)' which seems like it > gets the idea across better. Also improved the javadoc for it. > > Removed the comments about being instrumented by JFR in > Socket.SocketInputStream and Socket.SocketOutputStream. > > I went ahead and moved the event commiting out of the finally block so > that we don't emit events when the read/write did not actually happen. > The bugid JDK-8310979 will be used to determine if more should be done > in this area. > > The implRead and implWrite were moved up with the other support methods > for read/write. > - less exception filtering when fetching socket read timeout > - remove unused SOCKET_READ and SOCKET_WRITE configurations. > - Merge branch 'master' into JDK-8308995 > > # Conflicts: > # src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java > - Avoid exceptions getting address/timeout for jfr event. Remove unused > EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious > whitespace. > - some changes from review. > > read0() to implRead() > write0() to implWrite() > trailing whitespace > - fix copyright date > - Added micro benchmark to measure socket event overhead. > - Some changes from review. > > Append a 0 to method names being wrapped. Use getHostString to avoid > a reverse lookup when fetching the hostname of the remote address. > - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4 The new implementation calls getSocketRemoteAddress() and getSOTimeout() regardless if the event duration exceeds the threshold or not. This adds unnecessary overhead. Most socket write/reads are not committed, only those that take more than 20 ms (by default). I think you need something like this: if (SocketRead.shouldCommit(...)) { ... } ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1731379349 From mullan at openjdk.org Fri Sep 22 13:20:14 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 22 Sep 2023 13:20:14 GMT Subject: RFR: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback [v6] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 19:43:29 GMT, Ben Perez wrote: >> Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed @run arguments to completely override java.security Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15625#pullrequestreview-1639940575 From bpb at openjdk.org Fri Sep 22 15:54:18 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 22 Sep 2023 15:54:18 GMT Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v4] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 17:02:15 GMT, Brian Burkhalter wrote: >> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6478546: do-while -> while-do in writeBytes; remove NULL and bounds checks in native Still need to derive a valid value for the maximum read/write size by benchmarks which are not just measuring the file system cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1731651137 From mpowers at openjdk.org Fri Sep 22 15:59:19 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 22 Sep 2023 15:59:19 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: References: Message-ID: <0Jtj5m9CVwndzrSuE8g0m3NeHZRVaotMa9D2ZwhuOZQ=.92f10025-dc4f-40c4-8c8a-6df1c25b1783@github.com> On Fri, 22 Sep 2023 13:02:57 GMT, Weijun Wang wrote: >> Why not just updating UnexpectedNPE test with `Utils.runAndCheckException` calls? > > I was just thinking the tests are quite different. Now I re-read it and maybe we can change the old code to call `generateCRLs` as well. The existing `encoded_x` are very simple and only invalid SEQUENCES, which is not at the level of X.509 or PKCS7. > > Therefore I'm OK with reusing this test without the `generateCRL` flag. And leave `Utils.runAndCheckException` out of the fix? I'm fine either way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1334564687 From duke at openjdk.org Fri Sep 22 17:35:29 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 22 Sep 2023 17:35:29 GMT Subject: Integrated: 8304956: Update =?UTF-8?B?S2V5U3RvcmUuZ2V0RGVmYXVsdFR5cGXigIsoKQ==?= specification to return pkcs12 as fallback In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:12:28 GMT, Ben Perez wrote: > Replaced "jks" with "pkcs12" in both the spec and fallback for `KeyStore.getDefaultType()` This pull request has now been integrated. Changeset: 53516aed Author: Ben Perez Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/53516aed38c63df6e9722d65ce54acddd9735636 Stats: 51 lines in 3 files changed: 46 ins; 1 del; 4 mod 8304956: Update KeyStore.getDefaultType?() specification to return pkcs12 as fallback Reviewed-by: hchao, mullan ------------- PR: https://git.openjdk.org/jdk/pull/15625 From weijun at openjdk.org Fri Sep 22 17:39:13 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 22 Sep 2023 17:39:13 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: <0Jtj5m9CVwndzrSuE8g0m3NeHZRVaotMa9D2ZwhuOZQ=.92f10025-dc4f-40c4-8c8a-6df1c25b1783@github.com> References: <0Jtj5m9CVwndzrSuE8g0m3NeHZRVaotMa9D2ZwhuOZQ=.92f10025-dc4f-40c4-8c8a-6df1c25b1783@github.com> Message-ID: On Fri, 22 Sep 2023 15:56:08 GMT, Mark Powers wrote: >> I was just thinking the tests are quite different. Now I re-read it and maybe we can change the old code to call `generateCRLs` as well. The existing `encoded_x` are very simple and only invalid SEQUENCES, which is not at the level of X.509 or PKCS7. >> >> Therefore I'm OK with reusing this test without the `generateCRL` flag. > > And leave `Utils.runAndCheckException` out of the fix? I'm fine either way. I'm OK either way too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1334660937 From valeriep at openjdk.org Fri Sep 22 19:14:20 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 22 Sep 2023 19:14:20 GMT Subject: RFR: 8315944: SunJCE provider should not zeroize the deserialized key values In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 21:56:50 GMT, Valerie Peng wrote: > This PR reverts part of the changes under JDK-8312306 which zero-out the deserialized key bytes after an internal copy has been made. If considering the deserialized key bytes as input arguments, such cleaning action may be too aggressive. Thus, on second thought, I am reverting to earlier behavior. No regression test since the changes are trivial. > > Thanks! > Valerie Based on feedbacks from the corelib team, these serialized bytes are only used internally and zero them out should be safe and won't cause any breakage/undesirable side-effects. Thus, this PR is withdrawn. Thanks Max and Brad for helping to review. Withdraw ------------- PR Comment: https://git.openjdk.org/jdk/pull/15848#issuecomment-1731920414 PR Comment: https://git.openjdk.org/jdk/pull/15848#issuecomment-1731921380 From valeriep at openjdk.org Fri Sep 22 19:14:20 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 22 Sep 2023 19:14:20 GMT Subject: Withdrawn: 8315944: SunJCE provider should not zeroize the deserialized key values In-Reply-To: References: Message-ID: <1K7n_2WHo8Fi7kVkuzlEvySjxGfATLeBYCHPGr7lqjg=.0073942e-2273-4f13-a340-4466d5b3facc@github.com> On Wed, 20 Sep 2023 21:56:50 GMT, Valerie Peng wrote: > This PR reverts part of the changes under JDK-8312306 which zero-out the deserialized key bytes after an internal copy has been made. If considering the deserialized key bytes as input arguments, such cleaning action may be too aggressive. Thus, on second thought, I am reverting to earlier behavior. No regression test since the changes are trivial. > > Thanks! > Valerie This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15848 From weijun.wang at oracle.com Fri Sep 22 19:58:29 2023 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Fri, 22 Sep 2023 19:58:29 +0000 Subject: KrbException exception does not contain error string although error is well-known In-Reply-To: References: <4d81f4c8-d2a1-45c2-898a-a918f5ddc6ba@siemens.com> Message-ID: <354DB53F-9220-4CC2-9EAD-CECA9504D0C1@oracle.com> I'd fix it in one commit. https://bugs.openjdk.org/browse/JDK-8316771 filed. Thanks, Max > On Sep 22, 2023, at 10:35 AM, Osipov, Michael (IN IT IN) wrote: > > Nothing at hand, at the moment. I was first waiting for you to confirm the issue. I think two distinct PRs are necessary here with two JBS issues? > > M > > On 2023-09-20 20:06, Wei-Jun Wang wrote: >> I'll look into it. Thanks! >> Do you have a patch? :-) >> --Max >>> On Aug 9, 2023, at 3:30 AM, Osipov, Michael (SMD IT IN) wrote: >>> >>> Folks, Max, >>> >>> consider the following code snippet configured with the Krb5LoginModule: >>>> LoginContext lc = new LoginContext(loginEntryName); >>>> lc.login(); >>> >>> then a LoginException is thrown with the following stacktrace: >>>> 2023-08-01T00:09:31.601 SCHWERWIEGEND [https-openssl-apr-8444-exec-5417] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal Exception acquiring directory server connection >>>> javax.naming.NamingException: null (29) [Root exception is javax.security.auth.login.LoginException: null (29)] >>>> at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:625) >>>> at net.sf.michaelo.dirctxsrc.DirContextSource.getDirContext(DirContextSource.java:685) >>>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.open(ActiveDirectoryRealm.java:572) >>>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.acquire(ActiveDirectoryRealm.java:506) >>>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:432) >>>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:461) >>>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:426) >>>> at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:497) >>>> at net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator.doAuthenticate(SpnegoAuthenticator.java:163) >>>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:564) >>>> ... >>>> at java.lang.Thread.run(Thread.java:750) >>>> Caused by: javax.security.auth.login.LoginException: null (29) >>>> at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:810) >>>> at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) >>>> at sun.reflect.GeneratedMethodAccessor10719.invoke(Unknown Source) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) >>>> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) >>>> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) >>>> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) >>>> at javax.security.auth.login.LoginContext.login(LoginContext.java:587) >>>> at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:574) >>>> ... 23 more >>>> Caused by: KrbException: null (29) >>>> at sun.security.krb5.KrbAsRep.(KrbAsRep.java:76) >>>> at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:335) >>>> at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:488) >>>> at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:782) >>>> ... 35 more >>>> Caused by: KrbException: Identifier doesn't match expected value (906) >>>> at sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) >>>> at sun.security.krb5.internal.ASRep.init(ASRep.java:64) >>>> at sun.security.krb5.internal.ASRep.(ASRep.java:59) >>>> at sun.security.krb5.KrbAsRep.(KrbAsRep.java:60) >>>> ... 38 more >>> >>> I am trying to obtain a TGT to authenticate thorugh SASL GSSAPI to Active Directory via LDAP. This happened to me now repeatedly in the last couple of days around midnight. Looking up error code 29 says KDC_ERR_SVC_UNAVAILABLE, obviously the AD DC server is maintenance mode. What bugs me is that KDC_ERR_SVC_UNAVAILABLE(29) is documented in Krb5.java, has an error message and KrbException.java does use it, but no error message is mapped to the code. >>> >>> Request: Maybe someone (Max?) log an improvement request with JBS to >>> add missing error codes 26--28, 51 from [1] and >>>> public static final int KRB_AP_ERR_NOREALM = 62; >>>> public static final int KRB_AP_ERR_GEN_CRED = 63; >>> >>> look incorrect. Plus the mapping in errMsgList for those. >>> >>> Note: Tried with OpenJDK 8. >>> >>> Best regards, >>> >>> Michael >>> >>> [1] https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc4120*section-7.5.9__;Iw!!ACWV5N9M2RV99hQ!NAnnEyD5OZ3aXFClFAbzuSz344ZIBcwaUSH0iXe_005rJuCa-xP9-BARuknsTOZNP-MFJSjAiIMQm8mI7AyLsisF4Mg$ From sviswanathan at openjdk.org Fri Sep 22 20:51:18 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 22 Sep 2023 20:51:18 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2] In-Reply-To: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> References: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> Message-ID: On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: >> >> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup >> |-------------|------------|---------------|------------------|-----------| >> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 >> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 >> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 >> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 >> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 >> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 >> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 >> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 >> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 >> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 >> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 >> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 >> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 >> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 >> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 >> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 >> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 >> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 >> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 >> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 >> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 >> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 >> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 >> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 >> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 >> full.AES... > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Removed isEncrypt boolean variable src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3627: > 3625: __ cmpl(rounds, 52); > 3626: __ jcc(Assembler::greaterEqual, aes_192); > 3627: __ jmp(last_aes_rnd); Could be replaced with __ jcc(Assembler::below, last_aes_rnd); src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3649: > 3647: __ cmpl(rounds, 60); > 3648: __ jcc(Assembler::aboveEqual, aes_256); > 3649: __ jmp(last_aes_rnd); Could be replaced with __ jcc(Assembler::below, last_aes_rnd); src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4199: > 4197: //The entire message was encrypted processed in initial and now need to be hashed > 4198: __ cmpl(len, 0); > 4199: __ jcc(Assembler::equal, encrypt_done); We should check for len to be atleast 128 here as the block following processes 128 bytes: __ cmpl(len, 128); __ jcc(Assembler::less, encrypt_done); src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4241: > 4239: __ jcc(Assembler::equal, encrypt_done); > 4240: > 4241: __ bind(encrypt_done); This is a fall through case: __ cmpl(r14, 0); __ jcc(Assembler::equal, encrypt_done); The above two instructions can be removed. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4246: > 4244: __ bind(ghash_done); > 4245: __ movdqu(xmm15, ExternalAddress(counter_mask_linc1_addr()), rbx /*rscratch*/); > 4246: __ vpaddd(xmm9, xmm9, xmm15, Assembler::AVX_128bit); We could do the following here: __ vpaddd(xmm9, xmm9, ExternalAddress(counter_mask_linc1_addr()), Assembler::AVX_128bit, rbx); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334673738 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334674168 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334660702 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334657499 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334665625 From sviswanathan at openjdk.org Fri Sep 22 21:35:21 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 22 Sep 2023 21:35:21 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2] In-Reply-To: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> References: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> Message-ID: On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: >> >> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup >> |-------------|------------|---------------|------------------|-----------| >> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 >> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 >> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 >> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 >> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 >> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 >> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 >> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 >> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 >> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 >> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 >> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 >> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 >> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 >> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 >> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 >> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 >> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 >> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 >> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 >> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 >> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 >> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 >> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 >> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 >> full.AES... > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Removed isEncrypt boolean variable src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 3929: > 3927: __ vpaddd(xmm6, xmm5, t5, Assembler::AVX_128bit); > 3928: __ vpaddd(xmm7, xmm6, t5, Assembler::AVX_128bit); > 3929: __ vpaddd(xmm8, xmm7, t5, Assembler::AVX_128bit); This could be done more efficiently as follows: __ movdqu(t5, ExternalAddress(counter_mask_linc1_addr()), rbx /*rscratch*/); __ movdqu(t6, ExternalAddress(counter_mask_linc2_addr()), rbx /*rscratch*/); __ vpaddd(xmm2, xmm1, t5, Assembler::AVX_128bit); __ vpaddd(xmm3, xmm1, t6, Assembler::AVX_128bit); __ vpaddd(xmm4, xmm2, t6, Assembler::AVX_128bit); __ vpaddd(xmm5, xmm3, t6, Assembler::AVX_128bit); __ vpaddd(xmm6, xmm4, t6, Assembler::AVX_128bit); __ vpaddd(xmm7, xmm5, t6, Assembler::AVX_128bit); __ vpaddd(xmm8, xmm6, t6, Assembler::AVX_128bit); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334831118 From sviswanathan at openjdk.org Fri Sep 22 21:57:11 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 22 Sep 2023 21:57:11 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2] In-Reply-To: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> References: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> Message-ID: <41YkWu3U3uGBxtk_WBxpe5Ph5Qc6azAji7NEeGBPvP4=.9ae8b950-ce12-4d7b-a5f0-6b7054afe382@github.com> On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: >> >> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup >> |-------------|------------|---------------|------------------|-----------| >> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 >> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 >> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 >> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 >> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 >> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 >> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 >> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 >> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 >> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 >> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 >> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 >> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 >> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 >> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 >> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 >> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 >> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 >> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 >> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 >> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 >> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 >> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 >> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 >> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 >> full.AES... > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Removed isEncrypt boolean variable src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4045: > 4043: __ cmpl(rounds, 52); > 4044: __ jcc(Assembler::greaterEqual, aes_192); > 4045: __ jmp(last_aes_rnd); This could be replaced by: __ jcc(Assembler::less, last_aes_rnd); src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4068: > 4066: __ cmpl(rounds, 60); > 4067: __ jcc(Assembler::aboveEqual, aes_256); > 4068: __ jmp(last_aes_rnd); This could be replaced by: __ jcc(Assembler::less, last_aes_rnd); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334835575 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1334835717 From valeriep at openjdk.org Fri Sep 22 23:48:09 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 22 Sep 2023 23:48:09 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v2] In-Reply-To: References: <0Jtj5m9CVwndzrSuE8g0m3NeHZRVaotMa9D2ZwhuOZQ=.92f10025-dc4f-40c4-8c8a-6df1c25b1783@github.com> Message-ID: On Fri, 22 Sep 2023 17:36:11 GMT, Weijun Wang wrote: >> And leave `Utils.runAndCheckException` out of the fix? I'm fine either way. > > I'm OK either way too. +1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1334884534 From valeriep at openjdk.org Sat Sep 23 00:02:10 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Sat, 23 Sep 2023 00:02:10 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 00:31:37 GMT, Mark Powers wrote: > Without updating `Secmod/cert9.db` and `Secmod/key4.db`, both `Secmod/JksSetPrivateKey` and `Secmod/GetPrivateKey` will fail. The old values must have been incorrect. This was not noticed because `cert8.db` and `key3.db` were used if there were a `libnssdbm3` on the machine. In OL9, there is no `libnssdbm3`, so the failures appeared. > > Regarding your second question, every `cert8/key3` pair has a `cert9/key4` pair except for `pkcs11/tls` tests which only have `cert8/key3`. Thanks for the explanation~ Then what happens to the `pkcs11/tls/tls12` test which does not have cert9.db/key4.db? Will they continue to work against newer NSS releases with default sqlite=true? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15644#issuecomment-1732135896 From duke at openjdk.org Sat Sep 23 04:43:18 2023 From: duke at openjdk.org (duke) Date: Sat, 23 Sep 2023 04:43:18 GMT Subject: Withdrawn: JDK-8311892: TrustManagerFactory loading an invalid keystore yield vague exception In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 18:09:26 GMT, Craig Andrews wrote: > When loading the default JVM trust store, if the JVM trust store contains an invalid certificate, the exception contains insufficient information to determine which certificate is invalid, making it very difficult to fix the problem. > > To reproduce the issue: > 1. Modify the default JVM trust store to contain invalid information. A very easy way to do this on openjdk / red hat systems is to edit /etc/pki/ca-trust/extracted/java/cacerts and add garbage text to the file. > 2. Run this code: > > TrustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); > // initializing the trust store with a null KeyStore will load the default JVM trust store > tmf.init((KeyStore) null); > > > This stack trace results: > > Caused by: java.security.KeyStoreException: problem accessing trust store > at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73) > at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:282) > ... 81 common frames omitted > Caused by: java.io.IOException: toDerInputStream rejects tag type 97 > at java.base/sun.security.util.DerValue.toDerInputStream(DerValue.java:1155) > at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2013) > at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:221) > at java.base/java.security.KeyStore.load(KeyStore.java:1473) > at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:390) > at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:336) > at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:57) > at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49) > ... 83 common frames omitted > > > Throwing an exception with a more detailed error message facilitates debugging and ultimately fixing such problems. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14834 From mpowers at openjdk.org Mon Sep 25 03:40:47 2023 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 25 Sep 2023 03:40:47 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v3] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8315042 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: comment from Weijun ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15844/files - new: https://git.openjdk.org/jdk/pull/15844/files/6e7176fd..b481ec44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15844&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15844&range=01-02 Stats: 39 lines in 1 file changed: 8 ins; 22 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/15844.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15844/head:pull/15844 PR: https://git.openjdk.org/jdk/pull/15844 From duke at openjdk.org Mon Sep 25 12:29:16 2023 From: duke at openjdk.org (Ian Myers) Date: Mon, 25 Sep 2023 12:29:16 GMT Subject: RFR: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 05:55:20 GMT, Aleksey Shipilev wrote: >> Thanks for bringing this to my attention. If you believe the test change will make it run smoother, just do it. > >> Thanks for bringing this to my attention. If you believe the test change will make it run smoother, just do it. > > Would you like to formally approve this PR? Thanks! @shipilev can you sponsor this? ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15618#issuecomment-1733610673 From duke at openjdk.org Mon Sep 25 13:15:28 2023 From: duke at openjdk.org (Ian Myers) Date: Mon, 25 Sep 2023 13:15:28 GMT Subject: Integrated: 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:23:01 GMT, Ian Myers wrote: > sun/security/util/math/TestIntegerModuloP.java runs in tier2 and takes about 600 seconds to run. Thus, it drags the execution time of tier2 on large machines. We can split the run configurations a bit so that test is more parallel. > > TestIntegerModuloP.java current run time: **235.02s user 6.60s system 119% cpu 3:22.69 total** > TestIntegerModuloP.java parallelized run time: **328.75s user 14.57s system 755% cpu 45.467 total** > > This change splits TestIntegerModuloP.java's previously serialized test into 11 separate tests that run in parallel. This pull request has now been integrated. Changeset: 0f77d250 Author: Ian Myers Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/0f77d250b67ae0678756f986607eb239641dfb9e Stats: 62 lines in 1 file changed: 60 ins; 0 del; 2 mod 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java Reviewed-by: shade, weijun ------------- PR: https://git.openjdk.org/jdk/pull/15618 From weijun at openjdk.org Mon Sep 25 15:33:24 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 25 Sep 2023 15:33:24 GMT Subject: RFR: JDK-8315042 NPE in PKCS7.parseOldSignedData [v3] In-Reply-To: References: Message-ID: On Mon, 25 Sep 2023 03:40:47 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8315042 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > comment from Weijun test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 27: > 25: * @test > 26: * @library /test/lib > 27: * @bug 5052433 8315042 Usually we put `@bug` before `@library`. test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 39: > 37: public class UnexpectedNPE { > 38: CertificateFactory cf = null ; > 39: private static final String in = "MAsGCSqGSMP7TQEHAjI1Bgn///////8wCwUyAQ=="; Just embed the string inside the definition of `decodedBytes`. No need to create a field for it. test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 41: > 39: private static final String in = "MAsGCSqGSMP7TQEHAjI1Bgn///////8wCwUyAQ=="; > 40: > 41: public UnexpectedNPE() {} Useless constructor. test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 47: > 45: byte[] encoded_2 = { 0x30, 0x01, 0x00, 0x00 }; > 46: byte[] encoded_3 = { 0x30, 0x01, 0x00 }; > 47: byte[] decodedBytes = Base64.getDecoder().decode(in); Maybe rename to `encoded_4`? test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 49: > 47: byte[] decodedBytes = Base64.getDecoder().decode(in); > 48: > 49: UnexpectedNPE unpe = new UnexpectedNPE() ; Just modify `run` to static. No class instance needed. test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 60: > 58: if (cf == null) { > 59: try { > 60: cf = CertificateFactory.getInstance("X.509", "SUN"); Make `cf` static and move the line above to `main`. Or, make it a local variable in `main` and pass it to all `run` calls. test/jdk/sun/security/x509/X509CRLImpl/UnexpectedNPE.java line 76: > 74: > 75: System.out.println("CRLException has not been thrown"); > 76: return false; I think only `generateCRLs` is enough here since neither bug is about X.509 encoding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1336058841 PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1336054466 PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1336055352 PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1336055601 PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1336055142 PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1336055988 PR Review Comment: https://git.openjdk.org/jdk/pull/15844#discussion_r1336058145 From shade at openjdk.org Mon Sep 25 17:56:12 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Sep 2023 17:56:12 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: On Thu, 21 Sep 2023 13:26:14 GMT, Michal Sobierski wrote: >> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. >> >> Comparison of before and after parallelization: >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" >> before: 270.72s user 4.88s system 108% cpu 4:14.43 total >> after: 410.76s user 7.50s system 555% cpu 1:15.23 total >> after second commit: 375.46s user 4.59s system 539% cpu 1:10.41 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" >> before: 63.67s user 4.67s system 161% cpu 42.424 total >> after: 130.36s user 7.47s system 585% cpu 23.526 total >> after second commit: 67.31s user 4.48s system 417% cpu 17.183 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" >> before: 281.99s user 5.54s system 108% cpu 4:24.09 total >> after: 386.98s user 8.62s system 496% cpu 1:19.73 total >> after second commit: 413.51s user 5.08s system 613% cpu 1:08.25 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> before: 65.86s user 5.05s system 156% cpu 45.215 total >> after: 135.90s user 7.66s system 585% cpu 24.502 total >> after second commit: 83.25s user 4.82s system 469% cpu 18.741 total > > Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: > > Better approach to parallelize sun/security/rsa/SignedObjectChain.java > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" > before: 270.72s user 4.88s system 108% cpu 4:14.43 total > after: 375.46s user 4.59s system 539% cpu 1:10.41 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC" > before: 63.67s user 4.67s system 161% cpu 42.424 total > after: 67.31s user 4.48s system 417% cpu 17.183 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" > before: 281.99s user 5.54s system 108% cpu 4:24.09 total > after: 413.51s user 5.08s system 613% cpu 1:08.25 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC" > before: 65.86s user 5.05s system 156% cpu 45.215 total > after: 83.25s user 4.82s system 469% cpu 18.741 total @valeriepeng, would you like to take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15860#issuecomment-1734212052 From weijun at openjdk.org Mon Sep 25 18:17:36 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 25 Sep 2023 18:17:36 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 12:52:00 GMT, Weijun Wang wrote: >> The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. >> >> The test uses some reflection to get this field and try updating it in multiple threads. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more cases to cover A new PR posted to https://github.com/openjdk/jdk/pull/15909. Please take a look. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14506#issuecomment-1734241902 From weijun at openjdk.org Mon Sep 25 19:32:44 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 25 Sep 2023 19:32:44 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order Message-ID: Read files in `includedir` in alphanumerical order. ------------- Commit messages: - remove x bits - the fix Changes: https://git.openjdk.org/jdk/pull/15889/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15889&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309356 Stats: 77 lines in 2 files changed: 73 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15889/head:pull/15889 PR: https://git.openjdk.org/jdk/pull/15889 From weijun at openjdk.org Mon Sep 25 19:32:52 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 25 Sep 2023 19:32:52 GMT Subject: RFR: 8316771: Krb5.java has not defined messages for all error codes Message-ID: Added 4 missing error codes and removed 2 wrong ones. KRB_AP_ERR_NOREALM claims itself to be "used in setDefaultCreds() in sun.security.krb5.Credentials" but it's no more. KRB_AP_ERR_GEN_CRED is used in one place but it's a local error and not meant to be embedded in a message. Therefore safe to be removed. ------------- Commit messages: - remove x bits - the fix Changes: https://git.openjdk.org/jdk/pull/15892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316771 Stats: 79 lines in 3 files changed: 72 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15892/head:pull/15892 PR: https://git.openjdk.org/jdk/pull/15892 From weijun at openjdk.org Mon Sep 25 19:37:10 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 25 Sep 2023 19:37:10 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry Message-ID: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com> A different fix after https://github.com/openjdk/jdk/pull/14506 was closed. Still haven't made the attributes set immutable but at least it is populated before an entry is added to `entries` and it will never be modified later. I tried the newly added `AttributesMultiThread.java` test hundreds of times and only observed failures before this fix (~%2 failure rate). ------------- Commit messages: - remove x bits - the fix Changes: https://git.openjdk.org/jdk/pull/15909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309667 Stats: 258 lines in 3 files changed: 250 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15909.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15909/head:pull/15909 PR: https://git.openjdk.org/jdk/pull/15909 From sviswanathan at openjdk.org Mon Sep 25 23:16:17 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 25 Sep 2023 23:16:17 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v2] In-Reply-To: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> References: <8AUhJXT3sS9-gohY9kANLReqbUXcA28xNPiI2DPYE_k=.6ca0e589-156a-4085-8977-c55a3f95ec79@github.com> Message-ID: On Wed, 13 Sep 2023 20:25:22 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: >> >> |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup >> |-------------|------------|---------------|------------------|-----------| >> |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 >> full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 >> small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 >> small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 >> full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 >> full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 >> small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 >> small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 >> full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 >> small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 >> small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 >> full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 >> full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 >> small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 >> small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 >> full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 >> small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 >> small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 >> full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 >> full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 >> small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 >> small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 >> ? | ? | ? | ? | ? >> full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 >> full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 >> small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 >> small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 >> full.AES... > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Removed isEncrypt boolean variable src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 84: > 82: } > 83: > 84: ATTRIBUTE_ALIGNED(16) uint64_t COUNTER_MASK_LINC1F[] = { Please also update the copyright year of stubGenerator_x86_64_aes.cpp. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4167: > 4165: const Register pos = rax; > 4166: const Register rounds = r10; > 4167: const XMMRegister ctr_blockx = xmm9; It will be good to use the ctr_blockx consistently across instead of xmm9 below. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4174: > 4172: //Macro flow: > 4173: //calculate the number of 16byte blocks in the message > 4174: //process 8 16 byte blocks in initial_num_blocks.' The character ' at the end of the line seems extra. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4193: > 4191: > 4192: //Save the amount of data left to process in r14 > 4193: __ mov(r14, len); It looks to me that you could use len directly without moving it to r14. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4195: > 4193: __ mov(r14, len); > 4194: > 4195: initial_blocks(xmm9, rounds, key, r14, in, out, ct, subkeyHtbl, pos); For each of the method definitions (initial_blocks, ghash8_encrypt8_parallel, ghash_last8, generateHtbl_8_block_avx2) it would be good to add a comment at the beginning of the method indicating the inputs, outputs, and temporary registers. src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4213: > 4211: __ jcc(Assembler::greater, encrypt_by_8); > 4212: > 4213: __ addl(r15, 8); Should this be addb(r15, 8)? src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 4226: > 4224: __ vpshufb(xmm9, xmm9, ExternalAddress(counter_shuffle_mask_addr()), Assembler::AVX_128bit, rbx /*rscratch*/); > 4225: > 4226: __ addl(r15, 8); Should this be addb(r15, 8)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1336467494 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1336425142 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1336377175 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1336397169 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1336401373 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1336421620 PR Review Comment: https://git.openjdk.org/jdk/pull/15410#discussion_r1336421899 From valeriep at openjdk.org Mon Sep 25 23:51:13 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 25 Sep 2023 23:51:13 GMT Subject: RFR: 4964430: (spec) missing IllegalStateException exception requirement for javax.crypto.Cipher.doFinal [v2] In-Reply-To: <0VHfX_zAjpEHPCWuF3vV6-PaEpSFvU4tmeGo-n3bN9A=.59e15728-a118-4d9b-90b1-060f75fef5c4@github.com> References: <4O3T6mdtagN2edIKmXTq_rHSQOho_dvg5oGtLa72oMY=.5e2e02cd-3eee-4a1e-8b5a-7334bcb888c1@github.com> <0VHfX_zAjpEHPCWuF3vV6-PaEpSFvU4tmeGo-n3bN9A=.59e15728-a118-4d9b-90b1-060f75fef5c4@github.com> Message-ID: On Thu, 14 Sep 2023 18:43:10 GMT, Ben Perez wrote: >> Updated IllegalStateException exception requirements for `update`, `doFinal`, `wrap`, and `unwrap` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Removed periods at end of IllegalStateException comment 1) Cipher.updateAAD(...) methods also calls checkCipherState(), so its javadoc should be updated as well? 2) Given the current checkCipherState() impl does not check for states for NullCipher objects, do we want to also update the javax.crypto.NullCipher class javadoc to mention that IllegalStateException is not thrown by various methods? 3) Update copyright year to 2023? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15727#issuecomment-1734617568 From djelinski at openjdk.org Tue Sep 26 06:16:13 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 26 Sep 2023 06:16:13 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com> References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com> Message-ID: <7dnBnaGhxKFp90a8TcelhzyKW5QNjD1N62NPGYa7ZX8=.94c5b479-7870-4d81-a370-af216f62fb66@github.com> On Mon, 25 Sep 2023 18:12:32 GMT, Weijun Wang wrote: > A different fix after https://github.com/openjdk/jdk/pull/14506 was closed. > > Still haven't made the attributes set immutable but at least it is populated before an entry is added to `entries` and it will never be modified later. > > I tried the newly added `AttributesMultiThread.java` test hundreds of times and only observed failures before this fix (~%2 failure rate). LGTM. Thank you! ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15909#pullrequestreview-1643415588 From mbaesken at openjdk.org Tue Sep 26 07:29:51 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 26 Sep 2023 07:29:51 GMT Subject: RFR: JDK-8316671: sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java test fails intermittent with Read timed out Message-ID: We sometimes run into the following error. This especially occurs when running with fastdebug binaries and on Linux ppc64le machines. Current timeout set in the test is 1 second. Server accepting: 315357614990101 Server accepted: 315359219006041 Client starting handshake: 315359228098300 java.net.SocketTimeoutException: Read timed out at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278) at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:304) at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:346) at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:796) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:1096) at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489) at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483) at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:160) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1507) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1422) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426) at SSLSocketCloseHang.doClientSide(SSLSocketCloseHang.java:149) at SSLSocketCloseHang.startClient(SSLSocketCloseHang.java:320) at SSLSocketCloseHang.(SSLSocketCloseHang.java:246) at SSLSocketCloseHang.main(SSLSocketCloseHang.java:232) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1570) Making the timeout dependent on the timeout factor would give us the chance to influence the test on such slower setups. ------------- Commit messages: - JDK-8316671 Changes: https://git.openjdk.org/jdk/pull/15912/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15912&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316671 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15912/head:pull/15912 PR: https://git.openjdk.org/jdk/pull/15912 From robert.sherwood at credentive.com Tue Sep 26 10:19:44 2023 From: robert.sherwood at credentive.com (Robert Sherwood) Date: Tue, 26 Sep 2023 10:19:44 +0000 Subject: Question on JDK-8058778 (New APIs for creating certificates and certificate requests) Message-ID: Hello everyone ? I hope this is not too silly a question. I am doing some Java based PKI work for a client and have discovered the long outstanding JDK-8058778. I am curious about the difficulty of this request. I assume that it must be a very complicated problem to be open for so long. It seems like a reasonable straightforward problem. Is this a reasonable issue for a newcomer (i.e. me) to work on or is there some hidden complexity that prevents it being resolved? Thanks, Rob Sherwood -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Sep 26 13:34:23 2023 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 26 Sep 2023 13:34:23 +0000 Subject: Question on JDK-8058778 (New APIs for creating certificates and certificate requests) In-Reply-To: References: Message-ID: <167664D6-B50E-4A82-8D48-C9283377355D@oracle.com> Hi, On Sep 26, 2023, at 6:19 AM, Robert Sherwood > wrote: Hello everyone ? I hope this is not too silly a question. I am doing some Java based PKI work for a client and have discovered the long outstanding JDK-8058778. I am curious about the difficulty of this request. I assume that it must be a very complicated problem to be open for so long. It would be a significant amount of work to deliver this feature, but that is not the primary reason for why this work has not progressed. It seems like a reasonable straightforward problem. Is this a reasonable issue for a newcomer (i.e. me) to work on or is there some hidden complexity that prevents it being resolved? The bigger issue is whether something like this belongs in the Java Platform as a standard API. Essentially we would be including CA (Certificate Authority) functionality. This is more of a ?batteries included or not" type of question. Also, keytool currently provides the ability to create X.509 certificates and supports most common extensions. While this is not an API, we have found it sufficient for creating test certificates, which is one of the more common use cases for this feature. HTH, Sean Thanks, Rob Sherwood -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucy at openjdk.org Tue Sep 26 13:45:19 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 26 Sep 2023 13:45:19 GMT Subject: RFR: JDK-8316671: sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java test fails intermittent with Read timed out In-Reply-To: References: Message-ID: <_Tfpk-LFtjfjptbYSWaxHgGjWGEE9PnBcRCU5baTPTg=.c8596136-692a-4ac8-bb0a-9e496d08246e@github.com> On Tue, 26 Sep 2023 07:23:20 GMT, Matthias Baesken wrote: > We sometimes run into the following error. This especially occurs when running with fastdebug binaries and on Linux ppc64le machines. > Current timeout set in the test is 1 second. > > Server accepting: 315357614990101 > Server accepted: 315359219006041 > Client starting handshake: 315359228098300 > java.net.SocketTimeoutException: Read timed out > at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278) > at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:304) > at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:346) > at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:796) > at java.base/java.net.Socket$SocketInputStream.read(Socket.java:1096) > at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489) > at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483) > at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:160) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1507) > at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1422) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426) > at SSLSocketCloseHang.doClientSide(SSLSocketCloseHang.java:149) > at SSLSocketCloseHang.startClient(SSLSocketCloseHang.java:320) > at SSLSocketCloseHang.(SSLSocketCloseHang.java:246) > at SSLSocketCloseHang.main(SSLSocketCloseHang.java:232) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1570) > > Making the timeout dependent on the timeout factor would give us the chance to influence the test on such slower setups. Looks good to me. And trivial. And makes a lot of sense. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15912#pullrequestreview-1644309988 From mbaesken at openjdk.org Tue Sep 26 14:05:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 26 Sep 2023 14:05:20 GMT Subject: RFR: JDK-8316671: sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java test fails intermittent with Read timed out In-Reply-To: References: Message-ID: On Tue, 26 Sep 2023 07:23:20 GMT, Matthias Baesken wrote: > We sometimes run into the following error. This especially occurs when running with fastdebug binaries and on Linux ppc64le machines. > Current timeout set in the test is 1 second. > > Server accepting: 315357614990101 > Server accepted: 315359219006041 > Client starting handshake: 315359228098300 > java.net.SocketTimeoutException: Read timed out > at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278) > at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:304) > at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:346) > at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:796) > at java.base/java.net.Socket$SocketInputStream.read(Socket.java:1096) > at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489) > at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483) > at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:160) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1507) > at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1422) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426) > at SSLSocketCloseHang.doClientSide(SSLSocketCloseHang.java:149) > at SSLSocketCloseHang.startClient(SSLSocketCloseHang.java:320) > at SSLSocketCloseHang.(SSLSocketCloseHang.java:246) > at SSLSocketCloseHang.main(SSLSocketCloseHang.java:232) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1570) > > Making the timeout dependent on the timeout factor would give us the chance to influence the test on such slower setups. Hi Lutz, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15912#issuecomment-1735602848 From mbaesken at openjdk.org Tue Sep 26 14:05:21 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 26 Sep 2023 14:05:21 GMT Subject: Integrated: JDK-8316671: sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java test fails intermittent with Read timed out In-Reply-To: References: Message-ID: On Tue, 26 Sep 2023 07:23:20 GMT, Matthias Baesken wrote: > We sometimes run into the following error. This especially occurs when running with fastdebug binaries and on Linux ppc64le machines. > Current timeout set in the test is 1 second. > > Server accepting: 315357614990101 > Server accepted: 315359219006041 > Client starting handshake: 315359228098300 > java.net.SocketTimeoutException: Read timed out > at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278) > at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:304) > at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:346) > at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:796) > at java.base/java.net.Socket$SocketInputStream.read(Socket.java:1096) > at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489) > at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483) > at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:160) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1507) > at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1422) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426) > at SSLSocketCloseHang.doClientSide(SSLSocketCloseHang.java:149) > at SSLSocketCloseHang.startClient(SSLSocketCloseHang.java:320) > at SSLSocketCloseHang.(SSLSocketCloseHang.java:246) > at SSLSocketCloseHang.main(SSLSocketCloseHang.java:232) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1570) > > Making the timeout dependent on the timeout factor would give us the chance to influence the test on such slower setups. This pull request has now been integrated. Changeset: 1f7dfda7 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/1f7dfda7059f9dc14bff61b3c77d769ade85557d Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8316671: sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java test fails intermittent with Read timed out Reviewed-by: lucy ------------- PR: https://git.openjdk.org/jdk/pull/15912 From robert.sherwood at credentive.com Tue Sep 26 14:09:13 2023 From: robert.sherwood at credentive.com (Robert Sherwood) Date: Tue, 26 Sep 2023 14:09:13 +0000 Subject: Question on JDK-8058778 (New APIs for creating certificates and certificate requests) In-Reply-To: <167664D6-B50E-4A82-8D48-C9283377355D@oracle.com> References: <167664D6-B50E-4A82-8D48-C9283377355D@oracle.com> Message-ID: Ah, if I understand correctly, it?s more a question of whether full PKI functionality is something better provided by a third party e.g. BouncyCastle vs. maintaining it in the mainline JDK. That makes sense. Thanks for the response! Rob From: Sean Mullan Date: Tuesday, September 26, 2023 at 9:34 AM To: Robert Sherwood Cc: security-dev at openjdk.org Subject: Re: Question on JDK-8058778 (New APIs for creating certificates and certificate requests) Hi, On Sep 26, 2023, at 6:19 AM, Robert Sherwood > wrote: Hello everyone ? I hope this is not too silly a question. I am doing some Java based PKI work for a client and have discovered the long outstanding JDK-8058778. I am curious about the difficulty of this request. I assume that it must be a very complicated problem to be open for so long. It would be a significant amount of work to deliver this feature, but that is not the primary reason for why this work has not progressed. It seems like a reasonable straightforward problem. Is this a reasonable issue for a newcomer (i.e. me) to work on or is there some hidden complexity that prevents it being resolved? The bigger issue is whether something like this belongs in the Java Platform as a standard API. Essentially we would be including CA (Certificate Authority) functionality. This is more of a ?batteries included or not" type of question. Also, keytool currently provides the ability to create X.509 certificates and supports most common extensions. While this is not an API, we have found it sufficient for creating test certificates, which is one of the more common use cases for this feature. HTH, Sean Thanks, Rob Sherwood -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Tue Sep 26 14:52:13 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 26 Sep 2023 14:52:13 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com> References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com> Message-ID: On Mon, 25 Sep 2023 18:12:32 GMT, Weijun Wang wrote: > A different fix after https://github.com/openjdk/jdk/pull/14506 was closed. > > Still haven't made the attributes set immutable but at least it is populated before an entry is added to `entries` and it will never be modified later. > > I tried the newly added `AttributesMultiThread.java` test hundreds of times and only observed failures before this fix (~%2 failure rate). src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1270: > 1268: } > 1269: Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH)); > 1270: return Collections.unmodifiableSet(new HashSet<>(entry.attributes)); I do not think this fix is correct. A call to `engineGetAttribute()` could observe an empty `HashSet` set by `populateAttributes`, but before the entry is populated. If we want to prevent that I believe we need a lock of some kind shared between `engineGetAttribute` and `populateAttributes`. Also the constructor of `HashSet` that takes a collection calls `HashSet.addAll()`, which loops over the provided collection. In a multi threaded context, if `populateAttributes` can run concurrently with `engineGetAttribute`, it is not impossible that this loop will get a `ConcurrentModificationException`, like before. Or am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15909#discussion_r1337337639 From djelinski at openjdk.org Tue Sep 26 15:07:14 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 26 Sep 2023 15:07:14 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com> Message-ID: On Tue, 26 Sep 2023 14:46:46 GMT, Daniel Fuchs wrote: >> A different fix after https://github.com/openjdk/jdk/pull/14506 was closed. >> >> Still haven't made the attributes set immutable but at least it is populated before an entry is added to `entries` and it will never be modified later. >> >> I tried the newly added `AttributesMultiThread.java` test hundreds of times and only observed failures before this fix (~%2 failure rate). > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1270: > >> 1268: } >> 1269: Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH)); >> 1270: return Collections.unmodifiableSet(new HashSet<>(entry.attributes)); > > I do not think this fix is correct. A call to `engineGetAttribute()` could observe an empty `HashSet` set by `populateAttributes`, but before the entry is populated. If we want to prevent that I believe we need a lock of some kind shared between `engineGetAttribute` and `populateAttributes`. > Also the constructor of `HashSet` that takes a collection calls `HashSet.addAll()`, which loops over the provided collection. In a multi threaded context, if `populateAttributes` can run concurrently with `engineGetAttribute`, it is not impossible that this loop will get a `ConcurrentModificationException`, like before. Or am I missing something? Entries is a synchronized map, and populateAttributes is only called on freshly created entries before they are added to the map. I don't see how this could fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15909#discussion_r1337365700 From dfuchs at openjdk.org Tue Sep 26 16:01:16 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 26 Sep 2023 16:01:16 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: References: <7tOzLBf7ymXGAX4OtkJTXz-hYX9EZUxJNXFCpyEXrHY=.fa7771b8-dc35-4266-a4db-eff3486e8598@github.com> Message-ID: <2LBryPGqs6bY3NRqcq_6Ei2bRGQbLMKKGAtX-phB-jE=.73a28354-18db-48ce-ac67-34310d32fd72@github.com> On Tue, 26 Sep 2023 15:04:44 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1270: >> >>> 1268: } >>> 1269: Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH)); >>> 1270: return Collections.unmodifiableSet(new HashSet<>(entry.attributes)); >> >> I do not think this fix is correct. A call to `engineGetAttribute()` could observe an empty `HashSet` set by `populateAttributes`, but before the entry is populated. If we want to prevent that I believe we need a lock of some kind shared between `engineGetAttribute` and `populateAttributes`. >> Also the constructor of `HashSet` that takes a collection calls `HashSet.addAll()`, which loops over the provided collection. In a multi threaded context, if `populateAttributes` can run concurrently with `engineGetAttribute`, it is not impossible that this loop will get a `ConcurrentModificationException`, like before. Or am I missing something? > > Entries is a synchronized map, and populateAttributes is only called on freshly created entries before they are added to the map. I don't see how this could fail. Oh - I see - I did miss that. LGTM then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15909#discussion_r1337447708 From jnimeh at openjdk.org Tue Sep 26 16:17:13 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 26 Sep 2023 16:17:13 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 21:38:04 GMT, Daniel Jeli?ski wrote: >> Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. >> >> All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. >> >> SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. >> >> Tier1-3 tests pass. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Fix exception handling > - Fix indentation LGTM ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15148#pullrequestreview-1644692042 From kdriver at openjdk.org Tue Sep 26 19:44:40 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 26 Sep 2023 19:44:40 GMT Subject: RFR: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote Message-ID: Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response ------------- Commit messages: - update copyright year - Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length will also result in a short-circuit response Changes: https://git.openjdk.org/jdk/pull/15933/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15933&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295919 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15933/head:pull/15933 PR: https://git.openjdk.org/jdk/pull/15933 From mdonovan at openjdk.org Tue Sep 26 22:41:13 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 26 Sep 2023 22:41:13 GMT Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> Message-ID: On Fri, 25 Aug 2023 13:02:39 GMT, Matthew Donovan wrote: > This PR updates the version of NSS to 3.91 and includes aarch64 platforms. > > There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one. Waiting for https://github.com/openjdk/jdk/pull/15644 to merge before merging this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15429#issuecomment-1736397652 From djelinski at openjdk.org Wed Sep 27 07:37:32 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 27 Sep 2023 07:37:32 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 21:38:04 GMT, Daniel Jeli?ski wrote: >> Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. >> >> All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. >> >> SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. >> >> Tier1-3 tests pass. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Fix exception handling > - Fix indentation Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15148#issuecomment-1736857972 From djelinski at openjdk.org Wed Sep 27 07:37:34 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 27 Sep 2023 07:37:34 GMT Subject: Integrated: 8293176: SSLEngine handshaker does not send an alert after a bad parameters In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 08:17:39 GMT, Daniel Jeli?ski wrote: > Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. > > All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. > > SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. > > Tier1-3 tests pass. This pull request has now been integrated. Changeset: fee9d336 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/fee9d3362c76a046bb5160b90536545e7e9a5ce9 Stats: 99 lines in 2 files changed: 98 ins; 0 del; 1 mod 8293176: SSLEngine handshaker does not send an alert after a bad parameters Reviewed-by: mdonovan, jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/15148 From duke at openjdk.org Wed Sep 27 14:25:37 2023 From: duke at openjdk.org (Bart Smits) Date: Wed, 27 Sep 2023 14:25:37 GMT Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 06:28:23 GMT, Jaikiran Pai wrote: >> Thank you, I will look at these options. > > Hello @zhurs, would you mind if one of us took over this PR and moved this forward? Daniel noted that the fix looks reasonable and it's the test which will need some work. We will add you as the co-author. Hi @jaikiran I see the Pull Request is closed, but we were actually waiting for it to get merged. Is it still getting fixed? I see the JDK issue is still open. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1737365324 From dfuchs at openjdk.org Wed Sep 27 15:17:39 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 27 Sep 2023 15:17:39 GMT Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader In-Reply-To: References: Message-ID: On Wed, 27 Sep 2023 13:07:00 GMT, Bart Smits wrote: >> Hello @zhurs, would you mind if one of us took over this PR and moved this forward? Daniel noted that the fix looks reasonable and it's the test which will need some work. We will add you as the co-author. > > Hi @jaikiran I see the Pull Request is closed, but we were actually waiting for it to get merged. Is it still getting fixed? I see the JDK issue is still open. Hello @BartXZX , I believe @jaikiran is still working on this. The bot will simply close a PR if nothing happened to it after sometime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1737603075 From mullan at openjdk.org Wed Sep 27 19:34:11 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 27 Sep 2023 19:34:11 GMT Subject: RFR: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote In-Reply-To: References: Message-ID: On Tue, 26 Sep 2023 19:37:23 GMT, Kevin Driver wrote: > Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response src/java.base/share/classes/java/security/MessageDigest.java line 464: > 462: * It does not depend on the length of {@code digestb} or the contents > 463: * of {@code digesta} and {@code digestb}, unless {@code digestb} is null > 464: * or has a length of zero bytes. I think this new text should be moved earlier to the first sentence, since that first sentence is not always true given this condition. I suggest rewording the first two sentences as: "All bytes in {@code digesta} are examined to determine equality, unless {@code digestb} is {@code null} or has a length of zero bytes. If {@code digestb} is not {@code null} and does not have a length of zero bytes, then the calculation time depends only on the length of {@code digesta}." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15933#discussion_r1339111610 From kdriver at openjdk.org Wed Sep 27 20:07:12 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 27 Sep 2023 20:07:12 GMT Subject: RFR: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote In-Reply-To: References: Message-ID: <13cMZGeuFBOLv7V8W2uqXyiCzAaWkdg7Kpt9OLOS8bo=.d8f4ff7a-1d62-480a-ae61-0a6e6bc9c300@github.com> On Wed, 27 Sep 2023 19:31:53 GMT, Sean Mullan wrote: >> Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response > > src/java.base/share/classes/java/security/MessageDigest.java line 464: > >> 462: * It does not depend on the length of {@code digestb} or the contents >> 463: * of {@code digesta} and {@code digestb}, unless {@code digestb} is null >> 464: * or has a length of zero bytes. > > I think this new text should be moved earlier to the first sentence, since that first sentence is not always true given this condition. I suggest rewording the first two sentences as: > > "All bytes in {@code digesta} are examined to determine equality, unless {@code digestb} is {@code null} > or has a length of zero bytes. If {@code digestb} is not {@code null} and does not have a length of zero bytes, > then the calculation time depends only on the length of {@code digesta}." Yeah, I wondered about that. Will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15933#discussion_r1339147293 From kdriver at openjdk.org Wed Sep 27 20:15:35 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 27 Sep 2023 20:15:35 GMT Subject: RFR: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote [v2] In-Reply-To: References: Message-ID: > Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: rephrased per code review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15933/files - new: https://git.openjdk.org/jdk/pull/15933/files/0ee35d9d..17ed6c71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15933&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15933&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15933/head:pull/15933 PR: https://git.openjdk.org/jdk/pull/15933 From weijun at openjdk.org Wed Sep 27 20:41:52 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 27 Sep 2023 20:41:52 GMT Subject: RFR: 8316964: Security tools should not call System.exit Message-ID: Remove most `System.exit()` calls in various security tools and only leave one in the `main` method. This paves the way to convert them to JSR 199 tools. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/15951/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15951&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316964 Stats: 480 lines in 8 files changed: 286 ins; 107 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/15951.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15951/head:pull/15951 PR: https://git.openjdk.org/jdk/pull/15951 From jpai at openjdk.org Thu Sep 28 00:43:44 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 28 Sep 2023 00:43:44 GMT Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader In-Reply-To: References: Message-ID: On Thu, 25 May 2023 20:17:39 GMT, zhurs wrote: > When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size. > If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full. Hello Bart, like Daniel noted I'm still working on this. Sorry it has taken this long. I'll prioritize this work for the coming days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1738285852 From wetmore at openjdk.org Thu Sep 28 00:46:27 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 28 Sep 2023 00:46:27 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review comment - use SSLContextTemplate for SSLContext creation in test Other than the two small comments, LGTM. src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java line 346: > 344: shc.isResumption = false; > 345: shc.resumingSession = null; > 346: // the server is disallowing this session resumption, Would you please change "the server" to "this server." test/jdk/javax/net/ssl/SSLSession/ServerNameRejectedTLSSessionResumption.java line 1: > 1: /* Please reformat to <= 80 chars. This helps reviewers who prefer side/side reviews from having to horizontally scroll, even with large screens. Thanks. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13669#pullrequestreview-1647728171 PR Review Comment: https://git.openjdk.org/jdk/pull/13669#discussion_r1339367454 PR Review Comment: https://git.openjdk.org/jdk/pull/13669#discussion_r1339371434 From wetmore at openjdk.org Thu Sep 28 00:58:36 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 28 Sep 2023 00:58:36 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 21:38:04 GMT, Daniel Jeli?ski wrote: >> Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. >> >> All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. >> >> SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. >> >> Tier1-3 tests pass. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Fix exception handling > - Fix indentation This comment comes too late to catch this integration, but a thought as I was looking over the code. src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 1278: > 1276: throw context.conContext.fatal(Alert.INTERNAL_ERROR, > 1277: "Unhandled exception", e); > 1278: } Is there any chance this will double alert? ------------- PR Review: https://git.openjdk.org/jdk/pull/15148#pullrequestreview-1647747066 PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1339387873 From wetmore at openjdk.org Thu Sep 28 00:58:37 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 28 Sep 2023 00:58:37 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: <37Lm2RRj0oY8W_qyIVQmOscjLLtg9l-mpMnMEwnMiUQ=.7f858f6e-b09b-4f1d-9c76-9dc6013da926@github.com> On Fri, 11 Aug 2023 21:22:02 GMT, Daniel Jeli?ski wrote: >> test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineDecodeBadPoint.java line 40: >> >>> 38: public class SSLEngineDecodeBadPoint { >>> 39: static final byte[] clientHello = HexFormat.of().parseHex( >>> 40: "160303013a0100013603031570" + >> >> This may be the github display but this line is indented differently than the others. > > Thanks for pointing it out, fixed. Apparently my IntelliJ prefers this style of formatting multiline strings. I wonder if that's configurable. I believe so, but I still have to do some of the formatting by hand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1339385828 From jpai at openjdk.org Thu Sep 28 01:38:15 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 28 Sep 2023 01:38:15 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? > > The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. > > One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. > > If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. > > The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. Jaikiran Pai 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 five additional commits since the last revision: - limit line length in test case to 80 chars - Brad's suggestion - replace "the" with "this" - merge latest from master branch - review comment - use SSLContextTemplate for SSLContext creation in test - 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13669/files - new: https://git.openjdk.org/jdk/pull/13669/files/57df739d..c6ec3eb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13669&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13669&range=01-02 Stats: 578613 lines in 9655 files changed: 336694 ins; 149888 del; 92031 mod Patch: https://git.openjdk.org/jdk/pull/13669.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13669/head:pull/13669 PR: https://git.openjdk.org/jdk/pull/13669 From jpai at openjdk.org Thu Sep 28 01:38:18 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 28 Sep 2023 01:38:18 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v2] In-Reply-To: References: Message-ID: <7ofrUZRwuFFdTgSecS56OLnlxOt6XNiL26mbttWK_Dc=.f09b2e6c-d2cc-4593-a582-51ec52d48e1a@github.com> On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review comment - use SSLContextTemplate for SSLContext creation in test Thank you Brad for the review. I've now updated the PR to address your review suggestions. I've also triggered a CI run with these latest changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13669#issuecomment-1738315732 From jwaters at openjdk.org Thu Sep 28 03:12:03 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 28 Sep 2023 03:12:03 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v6] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Merge branch 'openjdk:master' into patch-10 - Merge branch 'master' into patch-10 - Document changes in awt_DnDDS.cpp - Remove negation in os_windows.cpp - Mismatched declaration in D3DGlyphCache.cpp - Fields in awt_TextComponent.cpp - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp - Qualifiers in awt_PrintDialog.h should be removed - Likewise for awt_DnDDT.cpp - awt_ole.h include order issue in awt_DnDDS.cpp - ... and 16 more: https://git.openjdk.org/jdk/compare/84390dd0...1e2b39f9 ------------- Changes: https://git.openjdk.org/jdk/pull/15096/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=05 Stats: 802 lines in 17 files changed: 171 ins; 127 del; 504 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Thu Sep 28 03:21:40 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 28 Sep 2023 03:21:40 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v6] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 28 Sep 2023 03:12:03 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - Merge branch 'openjdk:master' into patch-10 > - Merge branch 'master' into patch-10 > - Document changes in awt_DnDDS.cpp > - Remove negation in os_windows.cpp > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - ... and 16 more: https://git.openjdk.org/jdk/compare/84390dd0...1e2b39f9 closing and deleting for now ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1738377203 From jwaters at openjdk.org Thu Sep 28 03:21:41 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 28 Sep 2023 03:21:41 GMT Subject: Withdrawn: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <2z8rwkhhnrcVYMmAFv0iyc9bYapjmtEtCEnlrlfFxWQ=.10d537c9-43f3-47ce-9e3e-fff1aaaadfb5@github.com> On Tue, 1 Aug 2023 01:52:24 GMT, Julian Waters wrote: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15096 From mpowers at openjdk.org Thu Sep 28 04:26:25 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 28 Sep 2023 04:26:25 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts [v2] In-Reply-To: References: Message-ID: On Thu, 21 Sep 2023 15:40:22 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8296631 > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge > - comment from Valerie > - second iteration > - Merge > - first iteration Good point. No it does not work. The test failed to initialize the NSS module, printed "skipping", and returned pass. I converted the cert8/key3 pair to cert9/key4 and created a pkcs11.txt file. Now it works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15644#issuecomment-1738411705 From jpai at openjdk.org Thu Sep 28 04:59:33 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 28 Sep 2023 04:59:33 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v3] In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 01:38:15 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai 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 five additional commits since the last revision: > > - limit line length in test case to 80 chars > - Brad's suggestion - replace "the" with "this" > - merge latest from master branch > - review comment - use SSLContextTemplate for SSLContext creation in test > - 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session The CI job completed without issues - tier1,tier2 and tier3. I'll go ahead and integrate this PR later today/tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13669#issuecomment-1738431547 From djelinski at openjdk.org Thu Sep 28 06:00:44 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 28 Sep 2023 06:00:44 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 00:54:32 GMT, Bradford Wetmore wrote: >> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix exception handling >> - Fix indentation > > src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 1278: > >> 1276: throw context.conContext.fatal(Alert.INTERNAL_ERROR, >> 1277: "Unhandled exception", e); >> 1278: } > > Is there any chance this will double alert? Not really. Only the first call to `fatal` sends an alert, subsequent calls just rethrow the given exception, wrapping it in a SSLException if necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1339568493 From mullan at openjdk.org Thu Sep 28 13:25:25 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 28 Sep 2023 13:25:25 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order In-Reply-To: References: Message-ID: On Fri, 22 Sep 2023 14:00:34 GMT, Weijun Wang wrote: > Read files in `includedir` in alphanumerical order. Is there any potential compatibility issue by reading the files in a different order? test/jdk/sun/security/krb5/config/IncludeDirOrder.java line 61: > 59: write(xdir, i); > 60: } > 61: // K10 should always to read first Typo: s/to/be/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/15889#issuecomment-1739158094 PR Review Comment: https://git.openjdk.org/jdk/pull/15889#discussion_r1340141680 From mullan at openjdk.org Thu Sep 28 13:52:28 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 28 Sep 2023 13:52:28 GMT Subject: RFR: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote [v2] In-Reply-To: References: Message-ID: On Wed, 27 Sep 2023 20:15:35 GMT, Kevin Driver wrote: >> Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > rephrased per code review src/java.base/share/classes/java/security/MessageDigest.java line 461: > 459: * @implNote > 460: * All bytes in {@code digesta} are examined to determine equality, unless > 461: * {@code digestb} is null or has a length of zero bytes. If {@code digestb} Use code font around "null" : `{@code null}` src/java.base/share/classes/java/security/MessageDigest.java line 463: > 461: * {@code digestb} is null or has a length of zero bytes. If {@code digestb} > 462: * is not {@code null} and does not have a length of zero bytes, then the > 463: * calculation time depends only on the length of {@code digesta}. Sorry, my last comment may have been not specific enough but I don't think you should remove the last sentence - I think that is still important to explain how it is implemented: "It does not depend on the length of {@code digestb} or the contents of {@code digesta} and {@code digestb}." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15933#discussion_r1340188913 PR Review Comment: https://git.openjdk.org/jdk/pull/15933#discussion_r1340161981 From mpowers at openjdk.org Thu Sep 28 17:39:05 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 28 Sep 2023 17:39:05 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts [v3] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8296631 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: more sqlite conversion needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15644/files - new: https://git.openjdk.org/jdk/pull/15644/files/1439d191..2c6fb4ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15644&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15644&range=01-02 Stats: 1 line in 3 files changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15644/head:pull/15644 PR: https://git.openjdk.org/jdk/pull/15644 From wetmore at openjdk.org Thu Sep 28 17:48:42 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 28 Sep 2023 17:48:42 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 05:57:58 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 1278: >> >>> 1276: throw context.conContext.fatal(Alert.INTERNAL_ERROR, >>> 1277: "Unhandled exception", e); >>> 1278: } >> >> Is there any chance this will double alert? > > Not really. Only the first call to `fatal` sends an alert, subsequent calls just rethrow the given exception, wrapping it in a SSLException if necessary. Thanks for confirming. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1340487218 From wetmore at openjdk.org Thu Sep 28 17:59:35 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 28 Sep 2023 17:59:35 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v3] In-Reply-To: References: Message-ID: <9rtdTAGB3B6KYpHeFn0u3l3bHk4b7SWkr10YgIUaLTU=.240323ba-0c85-4725-a81d-44abf475b957@github.com> On Thu, 28 Sep 2023 01:38:15 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai 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 five additional commits since the last revision: > > - limit line length in test case to 80 chars > - Brad's suggestion - replace "the" with "this" > - merge latest from master branch > - review comment - use SSLContextTemplate for SSLContext creation in test > - 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session Marked as reviewed by wetmore (Reviewer). src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java line 347: > 345: shc.resumingSession = null; > 346: // this server is disallowing this session resumption, > 347: // so don't include the pre-shared key in the ServerHello handshake message If you wouldn't mind <= 80 here also. The other changes look great. No need for another full test cycle. Thanks for considering. ------------- PR Review: https://git.openjdk.org/jdk/pull/13669#pullrequestreview-1649425699 PR Review Comment: https://git.openjdk.org/jdk/pull/13669#discussion_r1340495893 From weijun at openjdk.org Thu Sep 28 18:31:24 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 28 Sep 2023 18:31:24 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 13:21:57 GMT, Sean Mullan wrote: > Is there any potential compatibility issue by reading the files in a different order? There is a behavior change, but I doubt if anyone is using this feature. I'm following what MIT krb5 has fixed. I can add a release note if necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15889#issuecomment-1739815284 From weijun at openjdk.org Thu Sep 28 18:49:15 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 28 Sep 2023 18:49:15 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order [v2] In-Reply-To: References: Message-ID: > Read files in `includedir` in alphanumerical order. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15889/files - new: https://git.openjdk.org/jdk/pull/15889/files/8670cd2d..5fd4de19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15889&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15889&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15889/head:pull/15889 PR: https://git.openjdk.org/jdk/pull/15889 From mullan at openjdk.org Thu Sep 28 19:22:23 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 28 Sep 2023 19:22:23 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order [v2] In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 18:49:15 GMT, Weijun Wang wrote: >> Read files in `includedir` in alphanumerical order. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > typo in comment Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15889#pullrequestreview-1649558556 From mullan at openjdk.org Thu Sep 28 19:22:25 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 28 Sep 2023 19:22:25 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 18:28:13 GMT, Weijun Wang wrote: > > Is there any potential compatibility issue by reading the files in a different order? > > There is a behavior change, but I doubt if anyone is using this feature. I'm following what MIT krb5 has fixed. I can add a release note if necessary. A release note is a good idea since we do document that we support includedir in the Security guides. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15889#issuecomment-1739878048 From valeriep at openjdk.org Thu Sep 28 20:25:25 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 28 Sep 2023 20:25:25 GMT Subject: RFR: JDK-8296631 NSS tests failing on OL9 linux-aarch64 hosts [v3] In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 17:39:05 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8296631 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > more sqlite conversion needed Marked as reviewed by valeriep (Reviewer). Thanks, changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/15644#pullrequestreview-1649651839 PR Comment: https://git.openjdk.org/jdk/pull/15644#issuecomment-1739954449 From jpai at openjdk.org Fri Sep 29 01:30:57 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 29 Sep 2023 01:30:57 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v3] In-Reply-To: <9rtdTAGB3B6KYpHeFn0u3l3bHk4b7SWkr10YgIUaLTU=.240323ba-0c85-4725-a81d-44abf475b957@github.com> References: <9rtdTAGB3B6KYpHeFn0u3l3bHk4b7SWkr10YgIUaLTU=.240323ba-0c85-4725-a81d-44abf475b957@github.com> Message-ID: On Thu, 28 Sep 2023 17:53:39 GMT, Bradford Wetmore wrote: >> Jaikiran Pai 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 five additional commits since the last revision: >> >> - limit line length in test case to 80 chars >> - Brad's suggestion - replace "the" with "this" >> - merge latest from master branch >> - review comment - use SSLContextTemplate for SSLContext creation in test >> - 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session > > src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java line 347: > >> 345: shc.resumingSession = null; >> 346: // this server is disallowing this session resumption, >> 347: // so don't include the pre-shared key in the ServerHello handshake message > > If you wouldn't mind <= 80 here also. The other changes look great. > > No need for another full test cycle. > > Thanks for considering. Sorry Brad, I didn't notice that one in my previous update. I've now updated the PR to fix this line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13669#discussion_r1340785946 From jpai at openjdk.org Fri Sep 29 03:18:06 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 29 Sep 2023 03:18:06 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v4] In-Reply-To: References: Message-ID: <0ly7ngbs3Xyu_danEeiL4uPoZtgYfr9AknikF_0yGSU=.5d3ae1c3-a20b-448e-b5fe-c58c4c16cd5f@github.com> > Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? > > The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. > > One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. > > If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. > > The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: fix line limit length ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13669/files - new: https://git.openjdk.org/jdk/pull/13669/files/c6ec3eb9..34417562 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13669&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13669&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13669.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13669/head:pull/13669 PR: https://git.openjdk.org/jdk/pull/13669 From jpai at openjdk.org Fri Sep 29 05:03:15 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 29 Sep 2023 05:03:15 GMT Subject: Integrated: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 10:02:49 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? > > The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. > > One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. > > If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. > > The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. > > A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. This pull request has now been integrated. Changeset: 0259da92 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/0259da92831087e918d00b8a83e04c96a6877f41 Stats: 253 lines in 2 files changed: 252 ins; 0 del; 1 mod 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session Reviewed-by: djelinski, wetmore ------------- PR: https://git.openjdk.org/jdk/pull/13669 From shade at openjdk.org Fri Sep 29 07:44:10 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 29 Sep 2023 07:44:10 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: On Thu, 21 Sep 2023 13:26:14 GMT, Michal Sobierski wrote: >> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. >> >> Comparison of before and after parallelization: >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" >> before: 270.72s user 4.88s system 108% cpu 4:14.43 total >> after: 410.76s user 7.50s system 555% cpu 1:15.23 total >> after second commit: 375.46s user 4.59s system 539% cpu 1:10.41 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" >> before: 63.67s user 4.67s system 161% cpu 42.424 total >> after: 130.36s user 7.47s system 585% cpu 23.526 total >> after second commit: 67.31s user 4.48s system 417% cpu 17.183 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" >> before: 281.99s user 5.54s system 108% cpu 4:24.09 total >> after: 386.98s user 8.62s system 496% cpu 1:19.73 total >> after second commit: 413.51s user 5.08s system 613% cpu 1:08.25 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> before: 65.86s user 5.05s system 156% cpu 45.215 total >> after: 135.90s user 7.66s system 585% cpu 24.502 total >> after second commit: 83.25s user 4.82s system 469% cpu 18.741 total > > Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: > > Better approach to parallelize sun/security/rsa/SignedObjectChain.java > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" > before: 270.72s user 4.88s system 108% cpu 4:14.43 total > after: 375.46s user 4.59s system 539% cpu 1:10.41 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC" > before: 63.67s user 4.67s system 161% cpu 42.424 total > after: 67.31s user 4.48s system 417% cpu 17.183 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" > before: 281.99s user 5.54s system 108% cpu 4:24.09 total > after: 413.51s user 5.08s system 613% cpu 1:08.25 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC" > before: 65.86s user 5.05s system 156% cpu 45.215 total > after: 83.25s user 4.82s system 469% cpu 18.741 total Or maybe @rhalade? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15860#issuecomment-1740452128 From kdriver at openjdk.org Fri Sep 29 16:34:28 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 29 Sep 2023 16:34:28 GMT Subject: RFR: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote [v3] In-Reply-To: References: Message-ID: <_0OeVTwYl7K1OR8b5rFKRVeDR1bx5Pq_XaPkQEaAA1k=.8bfca7c2-575c-471f-ab87-e4cfe422dacf@github.com> > Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: rephrased per code review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15933/files - new: https://git.openjdk.org/jdk/pull/15933/files/17ed6c71..07ad68e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15933&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15933&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15933/head:pull/15933 PR: https://git.openjdk.org/jdk/pull/15933 From weijun at openjdk.org Fri Sep 29 16:38:06 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 29 Sep 2023 16:38:06 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 19:19:36 GMT, Sean Mullan wrote: >>> Is there any potential compatibility issue by reading the files in a different order? >> >> There is a behavior change, but I doubt if anyone is using this feature. I'm following what MIT krb5 has fixed. I can add a release note if necessary. > >> > Is there any potential compatibility issue by reading the files in a different order? >> >> There is a behavior change, but I doubt if anyone is using this feature. I'm following what MIT krb5 has fixed. I can add a release note if necessary. > > A release note is a good idea since we do document that we support includedir in the Security guides. @seanjmullan I've created a release-note at https://bugs.openjdk.org/browse/JDK-8317325. Please take a look. TIA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15889#issuecomment-1741160644 From rhalade at openjdk.org Fri Sep 29 17:28:57 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 29 Sep 2023 17:28:57 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: On Thu, 21 Sep 2023 13:26:14 GMT, Michal Sobierski wrote: >> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. >> >> Comparison of before and after parallelization: >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" >> before: 270.72s user 4.88s system 108% cpu 4:14.43 total >> after: 410.76s user 7.50s system 555% cpu 1:15.23 total >> after second commit: 375.46s user 4.59s system 539% cpu 1:10.41 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" >> before: 63.67s user 4.67s system 161% cpu 42.424 total >> after: 130.36s user 7.47s system 585% cpu 23.526 total >> after second commit: 67.31s user 4.48s system 417% cpu 17.183 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" >> before: 281.99s user 5.54s system 108% cpu 4:24.09 total >> after: 386.98s user 8.62s system 496% cpu 1:19.73 total >> after second commit: 413.51s user 5.08s system 613% cpu 1:08.25 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> before: 65.86s user 5.05s system 156% cpu 45.215 total >> after: 135.90s user 7.66s system 585% cpu 24.502 total >> after second commit: 83.25s user 4.82s system 469% cpu 18.741 total > > Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: > > Better approach to parallelize sun/security/rsa/SignedObjectChain.java > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" > before: 270.72s user 4.88s system 108% cpu 4:14.43 total > after: 375.46s user 4.59s system 539% cpu 1:10.41 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC" > before: 63.67s user 4.67s system 161% cpu 42.424 total > after: 67.31s user 4.48s system 417% cpu 17.183 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" > before: 281.99s user 5.54s system 108% cpu 4:24.09 total > after: 413.51s user 5.08s system 613% cpu 1:08.25 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC" > before: 65.86s user 5.05s system 156% cpu 45.215 total > after: 83.25s user 4.82s system 469% cpu 18.741 total Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15860#pullrequestreview-1651208587 From valeriep at openjdk.org Fri Sep 29 18:42:30 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 29 Sep 2023 18:42:30 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: On Thu, 21 Sep 2023 13:26:14 GMT, Michal Sobierski wrote: >> sun/security/rsa/SignedObjectChain.java is very slow when run with C1, I suspect because some crypto intrinsics are only implemented in C2. Commit contains changes made to parallelize it. >> >> Comparison of before and after parallelization: >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" >> before: 270.72s user 4.88s system 108% cpu 4:14.43 total >> after: 410.76s user 7.50s system 555% cpu 1:15.23 total >> after second commit: 375.46s user 4.59s system 539% cpu 1:10.41 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseParallelGC" >> before: 63.67s user 4.67s system 161% cpu 42.424 total >> after: 130.36s user 7.47s system 585% cpu 23.526 total >> after second commit: 67.31s user 4.48s system 417% cpu 17.183 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" >> before: 281.99s user 5.54s system 108% cpu 4:24.09 total >> after: 386.98s user 8.62s system 496% cpu 1:19.73 total >> after second commit: 413.51s user 5.08s system 613% cpu 1:08.25 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java TEST_VM_OPTS="-XX:+UseShenandoahGC" >> before: 65.86s user 5.05s system 156% cpu 45.215 total >> after: 135.90s user 7.66s system 585% cpu 24.502 total >> after second commit: 83.25s user 4.82s system 469% cpu 18.741 total > > Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: > > Better approach to parallelize sun/security/rsa/SignedObjectChain.java > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" > before: 270.72s user 4.88s system 108% cpu 4:14.43 total > after: 375.46s user 4.59s system 539% cpu 1:10.41 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseParallelGC" > before: 63.67s user 4.67s system 161% cpu 42.424 total > after: 67.31s user 4.48s system 417% cpu 17.183 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" > before: 281.99s user 5.54s system 108% cpu 4:24.09 total > after: 413.51s user 5.08s system 613% cpu 1:08.25 total > > time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java > TEST_VM_OPTS="-XX:+UseShenandoahGC" > before: 65.86s user 5.05s system 156% cpu 45.215 total > after: 83.25s user 4.82s system 469% cpu 18.741 total Marked as reviewed by valeriep (Reviewer). I will take a look, sorry has been busy the past few days... ------------- PR Review: https://git.openjdk.org/jdk/pull/15860#pullrequestreview-1651250928 PR Comment: https://git.openjdk.org/jdk/pull/15860#issuecomment-1741273463 From valeriep at openjdk.org Fri Sep 29 18:42:36 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 29 Sep 2023 18:42:36 GMT Subject: RFR: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests [v2] In-Reply-To: References: <2S5d4_nU-a2dcoPOhCEe6flz9q0gk3eDrCNV2vTCBuw=.7e324ab5-ea91-4474-b5d8-2261d7440cf3@github.com> Message-ID: On Fri, 29 Sep 2023 07:41:08 GMT, Aleksey Shipilev wrote: >> Michal Sobierski has updated the pull request incrementally with one additional commit since the last revision: >> >> Better approach to parallelize sun/security/rsa/SignedObjectChain.java >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java >> TEST_VM_OPTS="-XX:+UseParallelGC -XX:TieredStopAtLevel=1" >> before: 270.72s user 4.88s system 108% cpu 4:14.43 total >> after: 375.46s user 4.59s system 539% cpu 1:10.41 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java >> TEST_VM_OPTS="-XX:+UseParallelGC" >> before: 63.67s user 4.67s system 161% cpu 42.424 total >> after: 67.31s user 4.48s system 417% cpu 17.183 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java >> TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:TieredStopAtLevel=1" >> before: 281.99s user 5.54s system 108% cpu 4:24.09 total >> after: 413.51s user 5.08s system 613% cpu 1:08.25 total >> >> time make test TEST=jdk/sun/security/rsa/SignedObjectChain.java >> TEST_VM_OPTS="-XX:+UseShenandoahGC" >> before: 65.86s user 5.05s system 156% cpu 45.215 total >> after: 83.25s user 4.82s system 469% cpu 18.741 total > > Or maybe @rhalade? Looks good to me as well. Would be nice to apply the stylistic changes suggested by @shipilev before integrating. Thanks! > test/jdk/sun/security/rsa/SignedObjectChain.java line 58: > >> 56: boolean result = Arrays.stream(tests).parallel().allMatch(Chain::runTest); >> 57: >> 58: if(result) { > > Suggestion: > > if (result) { +1 > test/jdk/sun/security/rsa/SignedObjectChain.java line 65: > >> 63: } >> 64: } >> 65: > > Do we need a newline here? +1, would be nice if this extra newline is removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15860#issuecomment-1741280180 PR Review Comment: https://git.openjdk.org/jdk/pull/15860#discussion_r1341652737 PR Review Comment: https://git.openjdk.org/jdk/pull/15860#discussion_r1341653043 From mullan at openjdk.org Fri Sep 29 18:42:59 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 29 Sep 2023 18:42:59 GMT Subject: RFR: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote [v3] In-Reply-To: <_0OeVTwYl7K1OR8b5rFKRVeDR1bx5Pq_XaPkQEaAA1k=.8bfca7c2-575c-471f-ab87-e4cfe422dacf@github.com> References: <_0OeVTwYl7K1OR8b5rFKRVeDR1bx5Pq_XaPkQEaAA1k=.8bfca7c2-575c-471f-ab87-e4cfe422dacf@github.com> Message-ID: On Fri, 29 Sep 2023 16:34:28 GMT, Kevin Driver wrote: >> Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > rephrased per code review Looks good. Please add a `noreg-doc` label to the bug. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15933#pullrequestreview-1651283947 From kdriver at openjdk.org Fri Sep 29 18:50:26 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 29 Sep 2023 18:50:26 GMT Subject: Integrated: 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote In-Reply-To: References: Message-ID: On Tue, 26 Sep 2023 19:37:23 GMT, Kevin Driver wrote: > Fix JDK-8295919 by updating the javadoc to explain that a null or zero-length `digestb` will also result in a short-circuit response This pull request has now been integrated. Changeset: 47569a25 Author: Kevin Driver URL: https://git.openjdk.org/jdk/commit/47569a256cb61f210bf2d9f28656fd3fa5ad27b8 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod 8295919: java.security.MessageDigest.isEqual does not adhere to @implNote Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/15933 From mullan at openjdk.org Fri Sep 29 19:07:39 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 29 Sep 2023 19:07:39 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 19:19:36 GMT, Sean Mullan wrote: >>> Is there any potential compatibility issue by reading the files in a different order? >> >> There is a behavior change, but I doubt if anyone is using this feature. I'm following what MIT krb5 has fixed. I can add a release note if necessary. > >> > Is there any potential compatibility issue by reading the files in a different order? >> >> There is a behavior change, but I doubt if anyone is using this feature. I'm following what MIT krb5 has fixed. I can add a release note if necessary. > > A release note is a good idea since we do document that we support includedir in the Security guides. > @seanjmullan I've created a release-note at https://bugs.openjdk.org/browse/JDK-8317325. Please take a look. TIA. I would note the previous behavior, ex: "Prior to this change, the files were read in no specific order." ------------- PR Comment: https://git.openjdk.org/jdk/pull/15889#issuecomment-1741358663 From weijun at openjdk.org Fri Sep 29 20:06:29 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 29 Sep 2023 20:06:29 GMT Subject: RFR: 8309356: Read files in includedir in alphanumeric order In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 19:03:35 GMT, Sean Mullan wrote: > > @seanjmullan I've created a release-note at https://bugs.openjdk.org/browse/JDK-8317325. Please take a look. TIA. > > I would note the previous behavior, ex: "Prior to this change, the files were read in no specific order." Thanks. I added the words. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15889#issuecomment-1741418246 From jwaters at openjdk.org Sat Sep 30 06:33:17 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 30 Sep 2023 06:33:17 GMT Subject: RFR: 8317332: Prepare security for permissive- Message-ID: Prepares java.security.jgss for the permissive- compiler switch by - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp - Adding a static modifier to a mismatched method declaration in NativeCreds.c, as the definition is static ------------- Commit messages: - Prepare security for permissive- Changes: https://git.openjdk.org/jdk/pull/15996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317332 Stats: 183 lines in 2 files changed: 32 ins; 21 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/15996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15996/head:pull/15996 PR: https://git.openjdk.org/jdk/pull/15996 From michael.osipov at siemens.com Fri Sep 22 14:35:43 2023 From: michael.osipov at siemens.com (Osipov, Michael (IN IT IN)) Date: Fri, 22 Sep 2023 14:35:43 -0000 Subject: KrbException exception does not contain error string although error is well-known In-Reply-To: References: <4d81f4c8-d2a1-45c2-898a-a918f5ddc6ba@siemens.com> Message-ID: Nothing at hand, at the moment. I was first waiting for you to confirm the issue. I think two distinct PRs are necessary here with two JBS issues? M On 2023-09-20 20:06, Wei-Jun Wang wrote: > I'll look into it. Thanks! > > Do you have a patch? :-) > > --Max > >> On Aug 9, 2023, at 3:30 AM, Osipov, Michael (SMD IT IN) wrote: >> >> Folks, Max, >> >> consider the following code snippet configured with the Krb5LoginModule: >>> LoginContext lc = new LoginContext(loginEntryName); >>> lc.login(); >> >> then a LoginException is thrown with the following stacktrace: >>> 2023-08-01T00:09:31.601 SCHWERWIEGEND [https-openssl-apr-8444-exec-5417] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal Exception acquiring directory server connection >>> javax.naming.NamingException: null (29) [Root exception is javax.security.auth.login.LoginException: null (29)] >>> at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:625) >>> at net.sf.michaelo.dirctxsrc.DirContextSource.getDirContext(DirContextSource.java:685) >>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.open(ActiveDirectoryRealm.java:572) >>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.acquire(ActiveDirectoryRealm.java:506) >>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:432) >>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:461) >>> at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:426) >>> at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:497) >>> at net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator.doAuthenticate(SpnegoAuthenticator.java:163) >>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:564) >>> ... >>> at java.lang.Thread.run(Thread.java:750) >>> Caused by: javax.security.auth.login.LoginException: null (29) >>> at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:810) >>> at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) >>> at sun.reflect.GeneratedMethodAccessor10719.invoke(Unknown Source) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) >>> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) >>> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) >>> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) >>> at javax.security.auth.login.LoginContext.login(LoginContext.java:587) >>> at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:574) >>> ... 23 more >>> Caused by: KrbException: null (29) >>> at sun.security.krb5.KrbAsRep.(KrbAsRep.java:76) >>> at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:335) >>> at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:488) >>> at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:782) >>> ... 35 more >>> Caused by: KrbException: Identifier doesn't match expected value (906) >>> at sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) >>> at sun.security.krb5.internal.ASRep.init(ASRep.java:64) >>> at sun.security.krb5.internal.ASRep.(ASRep.java:59) >>> at sun.security.krb5.KrbAsRep.(KrbAsRep.java:60) >>> ... 38 more >> >> I am trying to obtain a TGT to authenticate thorugh SASL GSSAPI to Active Directory via LDAP. This happened to me now repeatedly in the last couple of days around midnight. Looking up error code 29 says KDC_ERR_SVC_UNAVAILABLE, obviously the AD DC server is maintenance mode. What bugs me is that KDC_ERR_SVC_UNAVAILABLE(29) is documented in Krb5.java, has an error message and KrbException.java does use it, but no error message is mapped to the code. >> >> Request: Maybe someone (Max?) log an improvement request with JBS to >> add missing error codes 26--28, 51 from [1] and >>> public static final int KRB_AP_ERR_NOREALM = 62; >>> public static final int KRB_AP_ERR_GEN_CRED = 63; >> >> look incorrect. Plus the mapping in errMsgList for those. >> >> Note: Tried with OpenJDK 8. >> >> Best regards, >> >> Michael >> >> [1] https://www.rfc-editor.org/rfc/rfc4120#section-7.5.9 >