May 2021 - core-libs-dev

RFR: 8247373: ArraysSupport.newLength doc, test, and exception message
by Stuart Marks 23 Jul '21

23 Jul '21

This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. Separately, I'll work on retrofitting various call sites around the JDK to use this method. ------------- Commit messages: - 8247373: ArraysSupport.newLength doc, test, and exception message Changes: https://git.openjdk.java.net/jdk/pull/1617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247373 Stats: 171 lines in 4 files changed: 137 ins; 3 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1617/head:pull/1617 PR: https://git.openjdk.java.net/jdk/pull/1617

7 31

RFR: 8266936: Add a finalization JFR event
by Brent Christian 14 Jul '21

14 Jul '21

Please review this enhancement to add a new JFR event, generated whenever a finalizer is run. (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).) The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized. The Category for the event: `"Java Virtual Machine" / "GC" / "Finalization"` is what made sense to me, even though the event is generated from library code. Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr. Automated testing looks good so far. Thanks, -Brent ------------- Commit messages: - Fix jcheck some more - Fix jcheck - Merge branch 'master' into 8266936 - Add jfr mode to test/jdk/java/lang/ref/FinalizeOverride.java - Fix spacing in new regtest - Remove extraneous comments from new regtest - Removed unintentional changes from FinalizeOverride.java - Actually check in new regtest - Update TestActiveSettingEvent.java - Update TestDefaultConfigurations.java and .jfc files - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e6705c0e...200268ab Changes: https://git.openjdk.java.net/jdk/pull/4101/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266936 Stats: 191 lines in 11 files changed: 190 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4101.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4101/head:pull/4101 PR: https://git.openjdk.java.net/jdk/pull/4101

7 12

RFR: 8266578: Disambiguate BigDecimal description of scale
by Ignasi Marimon-Clos 12 Jul '21

12 Jul '21

The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. The ambiguity is on this sentence: > If negative, the unscaled value of the number is ... Instead, I suggest the more verbose: > If the scale is negative, the unscaled value of the number is ... To keep symmetry, I've also reviewed the positive case from: > If zero or positive, the scale is the number of digits ... to: > If the scale is zero or positive, the scale is the number of digits ... ------------- Commit messages: - Merge branch 'master' into minor-disambiguation - Disambiguate the BigDecimal docs Changes: https://git.openjdk.java.net/jdk/pull/582/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=582&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266578 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/582/head:pull/582 PR: https://git.openjdk.java.net/jdk/pull/582

4 14

RFR: 8266310: deadlock while loading the JNI code
by Aleksei Voitylov 06 Jul '21

06 Jul '21

Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. Problem being fixed: The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. Proposed fix: The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. Testing: jtreg and jck testing with no regressions. A new regression test was developed. ------------- Commit messages: - JDK-8266310: deadlock while loading the JNI code - JDK-8266310: deadlock while loading the JNI code Changes: https://git.openjdk.java.net/jdk/pull/3976/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266310 Stats: 475 lines in 6 files changed: 456 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976 PR: https://git.openjdk.java.net/jdk/pull/3976

11 60

RFR: 8260621: Avoid memory leak in ImageBufferCache
by Bo Zhang 28 Jun '21

28 Jun '21

Previously, `ImageBufferCache` contains a ThreadLocal field which holds strong reference to `ImageBufferCache$BufferReference.class`. When loaded from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` in memory forever and never being GCed. The fix replace the old `ImageBufferCache$BufferReference` class with `WeakReference<ByteBuffer>`, which is verified by provided test. ------------- Commit messages: - 8260621: Avoid memory leak in ImageBufferCache Changes: https://git.openjdk.java.net/jdk/pull/2307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260621 Stats: 123 lines in 2 files changed: 75 ins; 23 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/2307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2307/head:pull/2307 PR: https://git.openjdk.java.net/jdk/pull/2307

4 6

RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes
by Ian Graves 17 Jun '21

17 Jun '21

Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored. ------------- Commit messages: - Note about comments mode and character class whitespace Changes: https://git.openjdk.java.net/jdk/pull/3577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3577&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8199594 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3577/head:pull/3577 PR: https://git.openjdk.java.net/jdk/pull/3577

4 7

RFR: 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput
by Richard Fussenegger 17 Jun '21

17 Jun '21

Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request. ------------- Commit messages: - 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput Changes: https://git.openjdk.java.net/jdk/pull/1465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-5023614 Stats: 115 lines in 2 files changed: 91 ins; 14 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1465/head:pull/1465 PR: https://git.openjdk.java.net/jdk/pull/1465

3 11

RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant
by Richard Fussenegger 17 Jun '21

17 Jun '21

6594730: UUID.getVersion() is only meaningful for Leach-Salz variant ------------- Commit messages: - 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant Changes: https://git.openjdk.java.net/jdk/pull/1467/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1467&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6594730 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1467/head:pull/1467 PR: https://git.openjdk.java.net/jdk/pull/1467

4 12

RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException
by Rafael Winterhalter 14 Jun '21

14 Jun '21

During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. ------------- Commit messages: - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Changes: https://git.openjdk.java.net/jdk/pull/3940/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266791 Stats: 218 lines in 3 files changed: 216 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940

5 15

New convenience methods on Stream
by Donald Raab 14 Jun '21

14 Jun '21

Hi all, I’d like to propose adding one or two of the following methods on Stream to cover more surface area of the Collections ecosystem, without requiring a big increase in the size of the Stream interface. Apologies if this has come up for discussion before. 1. Stream contents into a mutable collection created by a Supplier. default <R extends Collection<T>> R toCollection(Supplier<R> supplier) { return this.collect(Collectors.toCollection(supplier)); } Usage Examples: HashSet<String> set = stream.toCollection(HashSet::new); TreeSet<String> sortedSet = stream.toCollection(TreeSet::new); ArrayDeque<String> deque = stream.toCollection(ArrayDeque::new); 2. Pass the result of toArray directly into a function that can then return a Collection. This should work with Set.of, List.of and any 3rd party collections which take arrays. default <R extends Collection<T>> R to(Function<T[], R> function) { return function.apply((T[]) this.toArray()); } Usage Examples: Set<String> set = stream.to(Set::of); List<String> list = stream.to(List::of); List<String> arrayList = stream.to(Arrays::asList); 3. Stream contents directly into any mutable collection. This would then work with all other mutable JDK Collection types. default <R extends Collection<T>> R into(R result) { Collections.addAll(result, (T[]) this.toArray()); return result; } Usage Examples: HashSet<String> set = stream.into(new HashSet<>()); TreeSet<String> sortedSet = stream.into(new TreeSet<>(Comparator.reverseOrder())); CopyOnWriteArrayList<String> list = stream.into(new CopyOnWriteArrayList<>()); There may be better default implementations, but I just wanted something here for illustrative purposes. Thoughts? Don

4 6