April 2021 - core-libs-dev

RFR: JDK-8265029: Preserve SIZED characteristics on slice operations (skip, limit)
by Tagir F.Valeev 28 May '21

28 May '21

With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch. Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch: ref.SliceToList.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40235,534 ± 0,984 B/op ref.SliceToList.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 106431,101 ± 0,198 B/op ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 106544,977 ± 1,983 B/op value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40121,878 ± 0,247 B/op value.SliceToArray.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 106317,693 ± 1,083 B/op value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 106430,954 ± 0,136 B/op After patch: ref.SliceToList.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40235,648 ± 1,354 B/op ref.SliceToList.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 40355,784 ± 1,288 B/op ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 40476,032 ± 2,855 B/op value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40121,830 ± 0,308 B/op value.SliceToArray.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 40242,554 ± 0,443 B/op value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 40363,674 ± 1,576 B/op Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests. Before patch: Benchmark (size) Mode Cnt Score Error Units ref.SliceToList.par_baseline 10000 thrpt 30 14876,723 ± 99,770 ops/s ref.SliceToList.par_limit 10000 thrpt 30 14856,841 ± 215,089 ops/s ref.SliceToList.par_skipLimit 10000 thrpt 30 9555,818 ± 991,335 ops/s ref.SliceToList.seq_baseline 10000 thrpt 30 23732,290 ± 444,162 ops/s ref.SliceToList.seq_limit 10000 thrpt 30 14894,040 ± 176,496 ops/s ref.SliceToList.seq_skipLimit 10000 thrpt 30 10646,929 ± 36,469 ops/s value.SliceToArray.par_baseline 10000 thrpt 30 25093,141 ± 376,402 ops/s value.SliceToArray.par_limit 10000 thrpt 30 24798,889 ± 760,762 ops/s value.SliceToArray.par_skipLimit 10000 thrpt 30 16456,310 ± 926,882 ops/s value.SliceToArray.seq_baseline 10000 thrpt 30 69669,787 ± 494,562 ops/s value.SliceToArray.seq_limit 10000 thrpt 30 21097,081 ± 117,338 ops/s value.SliceToArray.seq_skipLimit 10000 thrpt 30 15522,871 ± 112,557 ops/s After patch: Benchmark (size) Mode Cnt Score Error Units ref.SliceToList.par_baseline 10000 thrpt 30 14793,373 ± 64,905 ops/s ref.SliceToList.par_limit 10000 thrpt 30 13301,024 ± 1300,431 ops/s ref.SliceToList.par_skipLimit 10000 thrpt 30 11131,698 ± 1769,932 ops/s ref.SliceToList.seq_baseline 10000 thrpt 30 24101,048 ± 263,528 ops/s ref.SliceToList.seq_limit 10000 thrpt 30 16872,168 ± 76,696 ops/s ref.SliceToList.seq_skipLimit 10000 thrpt 30 11953,253 ± 105,231 ops/s value.SliceToArray.par_baseline 10000 thrpt 30 25442,442 ± 455,554 ops/s value.SliceToArray.par_limit 10000 thrpt 30 23111,730 ± 2246,086 ops/s value.SliceToArray.par_skipLimit 10000 thrpt 30 17980,750 ± 2329,077 ops/s value.SliceToArray.seq_baseline 10000 thrpt 30 66512,898 ± 1001,042 ops/s value.SliceToArray.seq_limit 10000 thrpt 30 41792,549 ± 1085,547 ops/s value.SliceToArray.seq_skipLimit 10000 thrpt 30 18007,613 ± 141,716 ops/s I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes. ------------- Commit messages: - Convert line endings - JDK-8265029: Preserve SIZED characteristics on slice operations (skip, limit) Changes: https://git.openjdk.java.net/jdk/pull/3427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265029 Stats: 377 lines in 9 files changed: 312 ins; 7 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/3427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427 PR: https://git.openjdk.java.net/jdk/pull/3427

4 25

RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles
by Jorn Vernee 27 May '21

27 May '21

This patch adds a `tableSwitch` combinator that can be used to switch over a set of method handles given an index, with a fallback in case the index is out of bounds, much like the `tableswitch` bytecode. The combinator does not support specifying the starting index, so the switch cases always run from 0 to however many target handles are specified. A starting index can be added manually with another combination step that filters the input index by adding or subtracting a constant from it, which does not affect performance. One of the reasons for not supporting a starting index is that it allows for more lambda form sharing, but also simplifies the implementation somewhat. I guess an open question is if a convenience overload should be added for that case? Lookup switch can also be simulated by filtering the input through an injection function that translates it into a case index, which has also proven to have the ability to have comparable performance to, or even better performance than, a bytecode-native `lookupswitch` instruction. I plan to add such an injection function to the runtime libraries in the future as well. Maybe at that point it could be evaluated if it's worth it to add a lookup switch combinator as well, but I don't see an immediate need to include it in this patch. The current bytecode intrinsification generates a call for each switch case, which guarantees full inlining of the target method handles. Alternatively we could only have 1 callsite at the end of the switch, where each case just loads the target method handle, but currently this does not allow for inlining of the handles, since they are not constant. Maybe a future C2 optimization could look at the receiver input for invokeBasic call sites, and if the input is a phi node, clone the call for each constant input of the phi. I believe that would allow simplifying the bytecode without giving up on inlining. Some numbers from the added benchmarks: Benchmark (numCases) (offset) (sorted) Mode Cnt Score Error Units MethodHandlesTableSwitchConstant.testSwitch 5 0 N/A avgt 30 4.186 � 0.054 ms/op MethodHandlesTableSwitchConstant.testSwitch 5 150 N/A avgt 30 4.164 � 0.057 ms/op MethodHandlesTableSwitchConstant.testSwitch 10 0 N/A avgt 30 4.124 � 0.023 ms/op MethodHandlesTableSwitchConstant.testSwitch 10 150 N/A avgt 30 4.126 � 0.025 ms/op MethodHandlesTableSwitchConstant.testSwitch 25 0 N/A avgt 30 4.137 � 0.042 ms/op MethodHandlesTableSwitchConstant.testSwitch 25 150 N/A avgt 30 4.113 � 0.016 ms/op MethodHandlesTableSwitchConstant.testSwitch 50 0 N/A avgt 30 4.118 � 0.028 ms/op MethodHandlesTableSwitchConstant.testSwitch 50 150 N/A avgt 30 4.127 � 0.019 ms/op MethodHandlesTableSwitchConstant.testSwitch 100 0 N/A avgt 30 4.116 � 0.013 ms/op MethodHandlesTableSwitchConstant.testSwitch 100 150 N/A avgt 30 4.121 � 0.020 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 0 N/A avgt 30 4.113 � 0.009 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 5 150 N/A avgt 30 4.149 � 0.041 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 0 N/A avgt 30 4.121 � 0.026 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 10 150 N/A avgt 30 4.113 � 0.021 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 0 N/A avgt 30 4.129 � 0.028 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 25 150 N/A avgt 30 4.105 � 0.019 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 0 N/A avgt 30 4.097 � 0.021 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 50 150 N/A avgt 30 4.131 � 0.037 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 0 N/A avgt 30 4.135 � 0.025 ms/op MethodHandlesTableSwitchOpaqueSingle.testSwitch 100 150 N/A avgt 30 4.139 � 0.145 ms/op MethodHandlesTableSwitchRandom.testSwitch 5 0 true avgt 30 4.894 � 0.028 ms/op MethodHandlesTableSwitchRandom.testSwitch 5 0 false avgt 30 11.526 � 0.194 ms/op MethodHandlesTableSwitchRandom.testSwitch 5 150 true avgt 30 4.882 � 0.025 ms/op MethodHandlesTableSwitchRandom.testSwitch 5 150 false avgt 30 11.532 � 0.034 ms/op MethodHandlesTableSwitchRandom.testSwitch 10 0 true avgt 30 5.065 � 0.076 ms/op MethodHandlesTableSwitchRandom.testSwitch 10 0 false avgt 30 13.016 � 0.020 ms/op MethodHandlesTableSwitchRandom.testSwitch 10 150 true avgt 30 5.103 � 0.051 ms/op MethodHandlesTableSwitchRandom.testSwitch 10 150 false avgt 30 12.984 � 0.102 ms/op MethodHandlesTableSwitchRandom.testSwitch 25 0 true avgt 30 8.441 � 0.165 ms/op MethodHandlesTableSwitchRandom.testSwitch 25 0 false avgt 30 13.371 � 0.060 ms/op MethodHandlesTableSwitchRandom.testSwitch 25 150 true avgt 30 8.628 � 0.032 ms/op MethodHandlesTableSwitchRandom.testSwitch 25 150 false avgt 30 13.542 � 0.020 ms/op MethodHandlesTableSwitchRandom.testSwitch 50 0 true avgt 30 4.701 � 0.015 ms/op MethodHandlesTableSwitchRandom.testSwitch 50 0 false avgt 30 13.562 � 0.063 ms/op MethodHandlesTableSwitchRandom.testSwitch 50 150 true avgt 30 7.991 � 3.111 ms/op MethodHandlesTableSwitchRandom.testSwitch 50 150 false avgt 30 13.543 � 0.088 ms/op MethodHandlesTableSwitchRandom.testSwitch 100 0 true avgt 30 4.712 � 0.020 ms/op MethodHandlesTableSwitchRandom.testSwitch 100 0 false avgt 30 13.600 � 0.085 ms/op MethodHandlesTableSwitchRandom.testSwitch 100 150 true avgt 30 4.676 � 0.011 ms/op MethodHandlesTableSwitchRandom.testSwitch 100 150 false avgt 30 13.476 � 0.043 ms/op Testing: - [x] Running of included benchmarks - [x] Inspecting inlining trace and verifying method handle targets are inlined - [x] Running TestTableSwitch test (currently the only user of the new code) - [x] Running java/lang/invoke tests (just in case) - [x] Some manual testing Thanks, Jorn ------------- Commit messages: - Improve test - Touchup - Use cases array + holder - WIP - implement tableSwitch combinator in lambda form interpreter Changes: https://git.openjdk.java.net/jdk/pull/3401/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3401&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263087 Stats: 959 lines in 8 files changed: 955 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3401.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3401/head:pull/3401 PR: https://git.openjdk.java.net/jdk/pull/3401

7 23

RFR: 8265248: Implementation Specific Properties: change prefix, plus add existing properties
by Joe Wang 26 May '21

26 May '21

Update module summary, add a few existing properties and features into the tables. ------------- Commit messages: - 8265248: Implementation Specific Properties: change prefix, plus add existing properties Changes: https://git.openjdk.java.net/jdk/pull/3644/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3644&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265248 Stats: 873 lines in 14 files changed: 640 ins; 66 del; 167 mod Patch: https://git.openjdk.java.net/jdk/pull/3644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3644/head:pull/3644 PR: https://git.openjdk.java.net/jdk/pull/3644

3 19

RFR: 8203359: Container level resources events
by Jaroslav Bachorik 21 May '21

21 May '21

With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. * CPU related metrics * Memory related metrics * I/O related metrics For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). ------------- Commit messages: - Formatting spaces - 8203359: Container level resources events Changes: https://git.openjdk.java.net/jdk/pull/3126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203359 Stats: 389 lines in 8 files changed: 386 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126 PR: https://git.openjdk.java.net/jdk/pull/3126

3 50

RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates
by Martin Buchholz 20 May '21

20 May '21

8246677: LinkedTransferQueue and SynchronousQueue synchronization updates ------------- Commit messages: - JDK-8246677 Changes: https://git.openjdk.java.net/jdk/pull/1645/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1645&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246677 Stats: 538 lines in 3 files changed: 143 ins; 294 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/1645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1645/head:pull/1645 PR: https://git.openjdk.java.net/jdk/pull/1645

4 5

RFR: 8261880: Change nested classes in java.base to static nested classes where possible
by Сергей Цыпанов 20 May '21

20 May '21

Non-static classes hold a link to their parent classes, which in many cases can be avoided. ------------- Commit messages: - 8261880: Change nested classes in java.base to static nested classes where possible Changes: https://git.openjdk.java.net/jdk/pull/2589/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261880 Stats: 20 lines in 16 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589 PR: https://git.openjdk.java.net/jdk/pull/2589

7 14

RFR: 8260517: implement Sealed Classes as a standard feature
by Vicente Romero 20 May '21

20 May '21

Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Thanks ------------- Commit messages: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes Changes: https://git.openjdk.java.net/jdk/pull/3526/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260517 Stats: 450 lines in 56 files changed: 48 ins; 282 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526

4 13

ReversibleCollection proposal
by Stuart Marks 20 May '21

20 May '21

This is a proposal to add a ReversibleCollection interface to the Collections Framework. I'm looking for comments on overall design before I work on detailed specifications and tests. Please send such comments as replies on this email thread. Here's a link to a draft PR that contains the code diffs. It's prototype quality, but it should be good enough to build and try out: https://github.com/openjdk/jdk/pull/3533 And here's a link to a class diagram showing the proposed additions: https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollecti… Thanks, s'marks # Ordering and Reversibility A long-standing concept that's been missing from collections is that of the positioning, sequencing, or arrangement of elements as a structural property of a collection. (This is sometimes called the "iteration order" of a collection.) For example, a HashSet is not ordered, but a List is. This concept is mostly not manifested in the collections API. Iterating a collection produces elements one after another in *some* sequence. The concept of "ordered" determines whether this sequence is defined or whether it's a coincidence of implementation. What does "having an order" mean? It implies that there is a first element and that each element has a successor. Since collections have a finite number of elements, it further implies that there is a last element that has no successor. However, it is difficult to discern whether a collection has a defined order. HashSet generally iterates its elements in the same undefined order, and you can't actually tell that it's not a defined order. Streams do have a notion of ordering ("encounter order") and this is preserved, where appropriate, through the stream pipeline. It's possible to detect this by testing whether its spliterator has the ORDERED characteristic. Any collection with a defined order will have a spliterator with this characteristic. However, this is quite a roundabout way to determine whether a collection has a defined order. Furthermore, knowing this doesn't enable any additional operations. It only provides constraints on the stream's implementations (keeping the elements in order) and provides stronger semantics for certain operations. For example, findFirst() on an unordered stream is the same as findAny(), but actually finds the first element if the stream is ordered. The concept of ordering is thus present in the system but is surfaced only in a fairly indirect way. We can strengthen abstraction of ordering by making a few observations and considering their implications. Given that there is a first element and a last element, the sequence of elements has two ends. It's reasonable to consider operations (add, get, remove) on either end. Indeed, the Deque interface has a full complement of operations at each end. This is an oft-requested feature on various other collections. Each element except for the last has a successor, implying that each element except for the first has a predecessor. Thus it's reasonable to consider iterating the elements from first to last or from last to first (that is, in forward or reverse order). Indeed, the concept of iterating in reverse order appears already in bits and pieces in particular places around the collections: - List has indexOf() and lastIndexOf() - Deque has removeFirstOccurrence() and removeLastOccurrence() - List has a ListIterator with hasPrevious/previous methods - Deque and NavigableSet have descendingIterator methods Given an ordered collection, though, there's no general way to iterate it in reverse order. Reversed iteration isn't the most common operation, but there are some frequent use cases, such as operating on elements in most-recently-added order. Questions and bug reports about this have come up repeatedly over the years. Unfortunately, iterating in reverse order is much harder than iterating in forward order. There are a variety of ways to iterate in forward order. For example, given a List, one can do any of the following: for (var e : list) { ... } list.forEach(...) list.stream() list.toArray() However, to iterate a list in reverse order, one must use an explicit loop over ListIterator: for (var it = list.listIterator(list.size()); it.hasPrevious(); ) { var e = it.previous(); ... } Streaming the elements of a List in reverse order is even worse. One approach would be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this Iterator can be turned into a Spliterator, which is then turned into a Stream. (The code to do this is left as an exercise for the reader.) Obtaining the elements in reverse via other means -- forEach() or toArray() -- is similarly difficult. Obtaining the elements in reverse order can be accomplished by adopting a concept from NavigableSet's descendingSet() method, which provides a reverse-ordered view collection. This view is also a NavigableSet, which means that any operation that can be performed on the original set can also be applied to the reverse-ordered view. If it were possible to obtain a similar reverse-ordered view on any kind of ordered collection, this would enable the elements to be processed in reverse order in any fashion, not just special-purposes APIs such as ListIterator or descendingIterator(). # LinkedHashSet The main feature of LinkedHashSet is that it does have a defined ordering, as opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last element. However, LinkedHashSet is deficient in a number of ways: - access to and removal of the first element is reasonable (using an iterator) but it is not possible to add at the front - it is possible to add an element at the end, but access to and removal of the last element are expensive - it's not possible to iterate in reverse without copying the entire collection Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so there is no fundamental implementation reason that prevents these operations from being supported. The main reason these operations aren't supported is probably that there hasn't been a good place to push such APIs. # Proposal Introduce a new ReversibleCollection<E> interface. This provides a new method to obtain a reverse-ordered view. It also contains several methods (copied from Deque) that allow operating on elements at both ends. interface ReversibleCollection<E> extends Collection<E> { ReversibleCollection<E> reversed(); default void addFirst(E e) default void addLast(E e) default E getFirst() default E getLast() default E removeFirst() default E removeLast() } The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are retrofitted to implement ReversibleCollection. They provide covariant overriding implementations of the reversed() method. For example, List.reversed() returns a List. Default implementations for all of these methods are provided in the appropriate interfaces. Covariant overrides are also provided in several other classes. This presents a difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To remedy this, we add another interface interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { } This adds no new methods but is essentially an intersection of ReversibleCollection and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and the set views of LinkedHashMap. SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because SortedSet's ordering is determined by the comparison method and cannot be controlled explicitly. LinkedHashSet::addFirst and addLast add the element at the appropriate position or reposition the element if it is already present in the set. New methods are added to LinkedHashMap V putFirst(K, V) V putLast(K, V) which put the mapping at the designated position or reposition the mapping if is already present in the map. # Design & Implementation Issues Covariant overrides for reversed() are provided where possible. However, there is a conflict between List and Deque, as there are examples in the JDK (such as LinkedList) that implement both List and Deque. Since List is much more popular than Deque, I've decided against adding a covariant override to Deque. Instead, a method Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns ReversibleCollection. There is no ReversibleMap interface. Most iteration over maps is over the entrySet, keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap provides ReversibleX views, which cover most of the cases already. Introducing new methods into an interface hierarchy always raises the possibility of name clashes. I've done some searching but I haven't found any major issues, but we should be on the lookout for this. I'll continue to do more searching for such conflicts. Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet, keySet, and values) could present incompatibility issues with subclasses that override these methods. I've done some searching and again I haven't found major problems, but this is nonetheless a point of concern. I'll do more searching here, too. The default implementations for List::reversed, Deque::reversed, and SortedSet::reversed return reverse-ordered views that are implemented using only public methods of the original interface. This demonstrates the feasibility of retrofitting reverse ordering onto any instance of these interfaces. Similarly, the various add/get/remove methods' default implementations are all implementable in terms of an iterator or reverse-ordered iterator. That said, some concurrent collection implementations will need to override these default implementations in order to preserve their safety invariants. It would probably also be wise to add optimized implementations to the more commonly-used collection implementations. Given that a ReversibleCollection has a defined ordering, any spliterator obtained from such a collection should have the Spliterator.ORDERED characteristic. This proposal is related to a previous discussion on a similar topic, where Tagir Valeev had proposed OrderedSet and OrderedMap: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html I think there were some good ideas in there and in the ensuing discussion, but it didn't go anywhere. Several of the concepts in this proposal are an evolution of some ideas discussed in that thread. One of the ideas from that thread was to use Deque as a common interface for many collections to support reversibility and operations at the ends. We've abandoned that idea in this proposal. The reasons are that it's cluttered with a bunch of methods that are inherited from Queue. Also, some methods are null-returning instead of throwing, which introduces confusion for collections that can contain nulls. # END

12 75

RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
by PROgrm_JARvis 19 May '21

19 May '21

Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. ------------- Commit messages: - 8258588: MD5 MessageDigest in java.util.UUID should be cached Changes: https://git.openjdk.java.net/jdk/pull/1821/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258588 Stats: 33 lines in 1 file changed: 26 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1821/head:pull/1821 PR: https://git.openjdk.java.net/jdk/pull/1821

7 28

RFR: 8254598: StringDedupTable should use OopStorage
by Kim Barrett 14 May '21

14 May '21

Please review this change to the String Deduplication facility. It is being changed to use OopStorage to hold weak references to relevant objects, rather than bespoke data structures requiring dedicated processing phases by supporting GCs. (The Shenandoah update was contributed by Zhengyu Gu.) This change significantly simplifies the interface between a given GC and the String Deduplication facility, which should make it much easier for other GCs to opt in. However, this change does not alter the set of GCs providing support; currently only G1 and Shenandoah support string deduplication. Adding support by other GCs will be in followup RFEs. Reviewing via the diffs might not be all that useful for some parts, as several files have been essentially completely replaced, and a number of files have been added or eliminated. The full webrev might be a better place to look. The major changes are in gc/shared/stringdedup/* and in the supporting collectors, but there are also some smaller changes in other places, most notably classfile/{stringTable,javaClasses}. This change is additionally labeled for review by core-libs, although there are no source changes there. This change injects a byte field of bits into java.lang.String, using one of the previously unused padding bytes in that class. (There were two unused bytes, now only one.) Testing: mach5 tier1-2 with and without -XX:+UseStringDeduplication Locally (linux-x64) ran all of the existing tests that use string deduplication with both G1 and Shenandoah. Note that TestStringDeduplicationInterned.java is disabled for shenandoah, as it currently fails, for reasons I haven't figured out but suspect are test related. - gc/stringdedup/ -- these used to be in gc/g1 - runtime/cds/SharedStringsDedup.java - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java - runtime/cds/appcds/sharedStrings/* shenandoah-only: - gc/shenandoah/jvmti/TestHeapDump.java - gc/shenandoah/TestStringDedup.java - gc/shenandoah/TestStringDedupStress.java Performance tested baseline, baseline + stringdedup, new with stringdedup, finding no significant differences. ------------- Commit messages: - New string deduplication Changes: https://git.openjdk.java.net/jdk/pull/3662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254598 Stats: 6185 lines in 105 files changed: 2361 ins; 3202 del; 622 mod Patch: https://git.openjdk.java.net/jdk/pull/3662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662 PR: https://git.openjdk.java.net/jdk/pull/3662

6 27