February 2021 - core-libs-dev

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: 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: 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: 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

Fast and cheap (Double|Float)::toString Java algorithm
by Raffaello Giulietti 04 May '21

04 May '21

Hello, as a reminder, a Java implementation of Schubfach [1] intended to replace the current slow and expensive OpenJDK (Double|Float)::toString algorithm has been discussed, presented and contributed to this mailing list in several posts. The last implementation is available in pre-Skara webrev form, as referenced in [2]. On my laptop hardware, the speedup factor is 17.7x wrt OpenJDK. Recently, Alexander Bolz translated Schubfach to C++ for the purpose of comparing the performance of several bin2dec floating-point numbers algorithms [3]. In the meantime, Junekey Jeon implemented and perfected his own Dragonbox in C++, a new algorithm based on Schubfach [4]. From [5]: "In addition to the core idea of Schubfach, Dragonbox utilizes some Grisu-like ideas to minimize the number of expensive 128-bit × 64-bit multiplications, at the cost of having more branches and divisions-by-constants." In the C++ ecosystem, Schubfach has been the fastest known algorithm before being gently pushed aside by Dragonbox, as can be seen in the graphs in [3]. While developing Schubfach back in 2018, I experimented myself with blending core Schubfach with my own earlier algorithm similar to Grisu. However, probably due to uncontrollable JIT compilation behavior, I could not observe any benefit. On the contrary, I measured performance drops probably because of the added complexity, which is public enemy nr. 1 for JIT compilers. Therefore, I opted for the simpler current design that seemed more suitable for (the then 2018 version of) C2. I hope this can somehow revive this community's interest and confidence toward Schubfach to definitely supplant the current expensive (Double|Float)::toString algorithm. Greetings Raffaello ---- [1] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065297.html [3] https://github.com/abolz/Drachennest [4] https://github.com/jk-jeon/dragonbox [5] https://github.com/jk-jeon/dragonbox/blob/master/other_files/Dragonbox.pdf

2 3

RFR: 4926314: Optimize Reader.read(CharBuffer)
by Philippe Marschall 26 Apr '21

26 Apr '21

Implement three optimiztations for Reader.read(CharBuffer) * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. ------------- Commit messages: - 4926314: Optimize Reader.read(CharBuffer) Changes: https://git.openjdk.java.net/jdk/pull/1915/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4926314 Stats: 101 lines in 3 files changed: 68 ins; 8 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/1915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915 PR: https://git.openjdk.java.net/jdk/pull/1915

7 47

RFR: 8013527: calling MethodHandles.lookup on itself leads to errors
by Mandy Chung 21 Apr '21

21 Apr '21

JDK-8013527: calling MethodHandles.lookup on itself leads to errors JDK-8257874: MethodHandle injected invoker doesn't have necessary private access Johannes Kuhn is also a contributor to this patch. A caller-sensitive method can behave differently depending on the identity of its immediate caller. If a method handle for a caller-sensitive method is requested, this resulting method handle behaves as if it were called from an instruction contained in the lookup class. The current implementation injects a trampoline class (aka the invoker class) which is the caller class invoking such caller-sensitive method handle. It works in all CSMs except `MethodHandles::lookup` because the caller-sensitive behavior depends on the module of the caller class, the class loader of the caller class, the accessibility of the caller class, or the protection domain of the caller class. The invoker class is a hidden class defined in the same runtime package with the same protection domain as the lookup class, which is why the current implementation works for all CSMs except `MethodHandles::lookup` which uses the caller class as the lookup class. Two issues with current implementation: 1. The invoker class only has the package access as the lookup class. It cannot access private members of the lookup class and its nest members. The fix is to make the invoker class as a nestmate of the lookup class. 2. `MethodHandles::lookup` if invoked via a method handle produces a `Lookup` object of an injected invoker class which is a bug. There are two alternatives: - define the invoker class with the lookup class as the class data such that `MethodHandles::lookup` will get the caller class from the class data if it's the injected invoker - Johannes' proposal [1]: detect if an alternate implementation with an additional trailing caller class parameter is present, use the alternate implementation and bind the method handle with the lookup class as the caller class argument. There has been several discussions on the improvement to support caller sensitive methods for example the calling sequences and security implication. I have looked at how each CSM uses the caller class. The second approach (i.e. defining an alternate implementation for a caller-sensitive method taking an additional caller class parameter) does not work for non-static non-final caller-sensitive method. In addition, it is not ideal to pollute the source code to provide an alternatve implementation for all 120+ caller-sensitive methods whereas the injected invoker works for all except `MethodHandles::lookup`. I propose to use both approaches. We can add an alternative implementation for a caller-sensitive method when desirable such as `MethodHandles::lookup` in this PR. For the injected invoker case, one could extract the original lookup class from class data if needed. test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that no new non-static non-final caller-sensitive method will be added to the JDK. I extend this test to catch that non-static non-final caller-sensitive method cannot have the alternate implementation taking the additional caller class parameter. This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.h… ------------- Commit messages: - clean up whitespace - revise the helper method - clean up - JDK-8013527: calling MethodHandles.lookup on itself leads to errors Changes: https://git.openjdk.java.net/jdk/pull/2367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8013527 Stats: 662 lines in 10 files changed: 620 ins; 9 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/2367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2367/head:pull/2367 PR: https://git.openjdk.java.net/jdk/pull/2367

3 10

RFR: 8228988: AnnotationParser throws NullPointerException on incompatible member type
by Rafael Winterhalter 20 Apr '21

20 Apr '21

When a class is compiled against a version of an annotation that is later loaded in an incompatible manner where an enum-typed member is changed into an annotation or vice versa, the reflection API currently throws a `NullPointerException` upon accessing the member. Instead an `AnnotationTypeMismatchException` should be thrown. This change adjusts the parsing to trigger the correct exception. ------------- Commit messages: - 8228988: AnnotationParser throws NullPointerException on incompatible member type Changes: https://git.openjdk.java.net/jdk/pull/2439/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2439&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228988 Stats: 182 lines in 3 files changed: 178 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2439.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2439/head:pull/2439 PR: https://git.openjdk.java.net/jdk/pull/2439

2 3