October 2023 - core-libs-dev

RFR: 8173970: jar tool should have a way to extract to a directory
by Jaikiran Pai 13 Nov '25

13 Nov '25

Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). The commit also includes a jtreg testcase which verifies the usage of this new option. ------------- Commit messages: - 8173970: jar tool should have a way to extract to a directory Changes: https://git.openjdk.java.net/jdk/pull/2752/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173970 Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752

13 61

RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
by Laurent Bourgès 21 Sep '25

21 Sep '25

* Optimized mixed insertion sort * Optimized insertion sort * Optimized Radix sort * Updated microbenchmark I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938 ------------- Commit messages: - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Changes: https://git.openjdk.org/jdk/pull/13568/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8266431 Stats: 4022 lines in 4 files changed: 1747 ins; 1272 del; 1003 mod Patch: https://git.openjdk.org/jdk/pull/13568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568 PR: https://git.openjdk.org/jdk/pull/13568

10 105

RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings
by Xin Liu 29 May '25

29 May '25

If AbstractStringBuilder only grow, the inflated value which is encoded in UTF16 can't be compressed. toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress. java.io.BufferedRead::readLine() is a case that StringBuilder grows only. ------------- Commit messages: - Add a microbenchmark. - 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings Changes: https://git.openjdk.java.net/jdk/pull/7671/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282429 Stats: 44 lines in 5 files changed: 37 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671

4 22

Re: RFR: 8266013: Unexpected replacement character handling on stateful CharsetEncoder [v2]
by Ichiroh Takiguchi 27 May '25

27 May '25

> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data. > Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset. > EBCDIC Mix charset encoder is stateful encoder. > Shift code should be added by switching character set. > On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F" > SI is not in right place. > > Also ISO2022 related charsets use escape sequence to switch character set. > But same kind of issue is there. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: 8266013: Unexpected replacement character handling on stateful CharsetEncoder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3719/files - new: https://git.openjdk.java.net/jdk/pull/3719/files/d6a0a41b..33107e67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=00-01 Stats: 59 lines in 2 files changed: 40 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3719/head:pull/3719 PR: https://git.openjdk.java.net/jdk/pull/3719

3 3

RFR: 8268829: Provide an optimized way to walk the stack with Class object only
by Mandy Chung 02 May '25

02 May '25

8268829: Provide an optimized way to walk the stack with Class object only `StackWalker::walk` creates one `StackFrame` per frame and the current implementation allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks like logging may only interest in the Class object but not the method name nor the BCI, for example, filters out its implementation classes to find the caller class. It's similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option. If no method information is needed, this option can be used such that the stack walker will save the overhead (1) to extract the method information and (2) the memory used for the stack walking. In addition, this can also fix - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively Adding `NO_METHOD_TIME` option provides a simple way for existing code, for example logging frameworks, to take advantage of this enhancement with the least change as it can keep the existing implementation in traversing `StackFrame`s. For example: to find the first caller filtering a known list of implementation class, existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance` to create a stack walker instance: StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO); Optional<Class<?>> callerClass = walker.walk(s -> s.map(StackFrame::getDeclaringClass) .filter(interestingClasses::contains) .findFirst()); If method information is accessed on the `StackFrame`s produced by this stack walker such as `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. The alternative considered is to provide a new API: `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)` In this case, the caller would need to pass a function that takes a stream of `Class` object instead of `StackFrame`. Existing code would have to modify calls to the `walk` method to `walkClass` and the function body. ### Implementation Details If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]` buffer that is filled by the VM during stack walking. `ClassFrameInfo` holds the Class instance plus `flags` which indicate if it's caller sensitive or hidden. With this change, `StackWalker::getCallerClass` can also use `ClassFrameInfo[]` buffer to replace the special `Class` buffer and remove the special check in the VM. JDK-8311500 can be fixed in Java. If `NO_METHOD_NAME` is not set, the implementation creates `StackFrameInfo[]` buffer. `StackFrameInfo` is a subclass of `ClassFrameInfo`. It keeps `ResolvedMethodName` and all other method information. ### Performance The memory usage of the data structure (shown by -XX:PrintFieldLayout): | Type | Instance size | | ---- | ------------ | | `ClassFrameInfo` | 24 bytes | | `StackFrameInfo` | 48 bytes | | `ResolvedMethodName` | 24 bytes | | `MemberName` | 48 bytes | | `StackFrameInfo` (old) | 32 bytes | The existing implementation allocates a total of 104 bytes for each frame (`StackFrameInfo` + `MemberName` + `ResolvedMethodName`). The new implementation, without `NO_METHOD_INFO` option, allocates a total of 72 bytes for each frame (`StackFrameInfo` + `ResolvedMethodName`) which saves 30% of the buffer memory. With `NO_METHOD_INFO`, 24 bytes is allocated for each frame (only `ClassFrameInfo` is needed). In addition, it saves the overhead in creating `ResolvedMethodName` object in the VM. The microbenchmark shows that the runtime performance of stack walking with method information is 15-31% faster than the old implementation. Using `NO_METHOD_INFO` option, it is about 21-43% faster compared to traversing the frames without `NO_METHOD_INFO` in the new implementation. #### `StackWalker::getCallerClass` `StackWalkBench::getCallerClass` shows about 30-60 ns degradation. The old implementation creates a `Class` array of size 8 whereas the new implementation which creates a `ClassFrameInfo` array of size 8 initialized with 6 `ClassFrameInfo` elements. The new implementation of `getCallerClass` adds 144 bytes more, which is insignificant. The benefit of this is to do the filtering in Java rather than doing in VM. `StackWalkBench::getCallerClass` includes the cost of setting up the call stack. There is no good way to write a JMH benchmark just to measure the performance of `getCallerClass`. If I measured `getCallerClass` with a standalone benchmark, it shows `getCallerClass` takes roughly about 8500-10000 ns range on my macos-aarch64 machine. The 30-60 ns degradation is negligible. ------------- Commit messages: - fix trailing whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Update LocalLongHelper.java - clean up - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Add StackWalker.Option.NO_METHOD_INFO - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - ... and 3 more: https://git.openjdk.org/jdk/compare/78f74bc8...e9e2b390 Changes: https://git.openjdk.org/jdk/pull/15370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8268829 Stats: 1026 lines in 30 files changed: 628 ins; 178 del; 220 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370

13 67

RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
by Justin Lu 10 Apr '25

10 Apr '25

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

6 11

RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
by Aggelos Biboudis 10 Apr '25

10 Apr '25

This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/ins… ------------- Commit messages: - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303374 Stats: 2293 lines in 29 files changed: 2186 ins; 16 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638

9 143

RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
by Justin Lu 10 Apr '25

10 Apr '25

This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. ------------- Commit messages: - Write to ASCII - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1 - Compile class with ascii (Not ready to make system wide change) - Toggle UTF-8 for javac option in JavaCompilation.gmk - CompileProperties converts in UTF-8 - Convert .properties from ISO-8859-1 to UTF-8 Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726

9 28

RFR: 8315487: Security Providers Filter
by Martin Balao 09 Jan '25

09 Jan '25

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<Service> 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/j… [2] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… [3] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… [4] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… [5] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… [6] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… [7] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… [8] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… [9] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/j… ------------- 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

8 53

RFR: 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)
by Raffaello Giulietti 05 Dec '24

05 Dec '24

By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings. ------------- Commit messages: - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float) Changes: https://git.openjdk.org/jdk/pull/15861/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316662 Stats: 388 lines in 3 files changed: 161 ins; 108 del; 119 mod Patch: https://git.openjdk.org/jdk/pull/15861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15861/head:pull/15861 PR: https://git.openjdk.org/jdk/pull/15861

7 17