March 2021 - core-libs-dev

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: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException
by Simon Legner 26 Apr '21

26 Apr '21

8264031: Fix typo in ZipFileSystem.deleteFile ZipException ------------- Commit messages: - ZipFileSystem: fix typo in ZipException Changes: https://git.openjdk.java.net/jdk/pull/2588/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2588&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264031 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2588.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2588/head:pull/2588 PR: https://git.openjdk.java.net/jdk/pull/2588

3 5

RFR: 8037397: Lost nested character class after intersection &&
by Ian Graves 25 Apr '21

25 Apr '21

Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones. ------------- Commit messages: - Fixing a regex intersection bug that drops expressions on the right hand side Changes: https://git.openjdk.java.net/jdk/pull/3291/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3291&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8037397 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3291/head:pull/3291 PR: https://git.openjdk.java.net/jdk/pull/3291

4 11

RFR: 8263668: Update java.time to use instanceof pattern variable
by Patrick Concannon 22 Apr '21

22 Apr '21

Hi, Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable? Kind regards, Patrick ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into JDK-8263668 - 8263668: Update java.time to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/3170/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263668 Stats: 170 lines in 34 files changed: 0 ins; 47 del; 123 mod Patch: https://git.openjdk.java.net/jdk/pull/3170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170 PR: https://git.openjdk.java.net/jdk/pull/3170

13 34

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

RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices
by Rafael Winterhalter 12 Apr '21

12 Apr '21

8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices. ------------- Commit messages: - 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices. Changes: https://git.openjdk.java.net/jdk/pull/3082/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3082&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263763 Stats: 65 lines in 3 files changed: 60 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3082/head:pull/3082 PR: https://git.openjdk.java.net/jdk/pull/3082

4 10

8214761: Bug in parallel Kahan summation implementation
by Chris Dennis 09 Apr '21

09 Apr '21

I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have been stuck waiting on OCA signatory status to be confirmed. Did something get lost in the shuffle or do I just need to be more patient. Thanks, Chris

4 5

RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
by Dong Bo 09 Apr '21

09 Apr '21

In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. There can be illegal characters at the start of the input if the data is MIME encoded. It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. A JMH micro, Base64Decode.java, is added for performance test. With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. The Base64Decode.java JMH micro-benchmark results: # Kunpeng916, intrinsic Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ± 0.609 ns/op Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ± 1.650 ns/op Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ± 0.931 ns/op Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ± 1.687 ns/op Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ± 9.217 ns/op Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ± 1.667 ns/op Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ± 1.751 ns/op Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ± 1.178 ns/op Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ± 0.584 ns/op Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ± 1.050 ns/op Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ± 45.172 ns/op Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ± 192.070 ns/op Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ± 0.336 ns/op Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ± 0.848 ns/op Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ± 0.608 ns/op Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ± 6.236 ns/op Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ± 4.670 ns/op Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ± 4.324 ns/op Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ± 6.393 ns/op Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ± 0.759 ns/op Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ± 3.422 ns/op Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ± 9.128 ns/op Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ± 7951.521 ns/op Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ± 161.758 ns/op # Kunpeng916, default Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ± 0.571 ns/op Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ± 0.505 ns/op Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ± 1.452 ns/op Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ± 1.243 ns/op Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ± 1.188 ns/op Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ± 0.572 ns/op Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ± 0.177 ns/op Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ± 0.572 ns/op Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ± 1.559 ns/op Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ± 0.813 ns/op Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ± 24.669 ns/op Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ± 523.155 ns/op Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ± 0.238 ns/op Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ± 0.205 ns/op Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ± 0.610 ns/op Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ± 4.732 ns/op Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ± 0.177 ns/op Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ± 4.572 ns/op Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ± 0.301 ns/op Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ± 0.389 ns/op Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ± 2.519 ns/op Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ± 9.281 ns/op Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ± 157.920 ns/op Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ± 216.542 ns/op ------------- Commit messages: - 8256245: AArch64: Implement Base64 decoding intrinsic Changes: https://git.openjdk.java.net/jdk/pull/3228/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256245 Stats: 410 lines in 3 files changed: 410 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228 PR: https://git.openjdk.java.net/jdk/pull/3228

3 37