May 2021 - core-libs-dev

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: 8267751: (test) jtreg.SkippedException has no serial VersionUID
by Roger Riggs 26 May '21

26 May '21

The class `test/lib/jtreg/SkippedException.java` is missing a serialVersionUID causing additional noise in compiler output of tests. ------------- Commit messages: - Added serialVersionUID to jtreg.SkippedException to eliminate compilation warnings Changes: https://git.openjdk.java.net/jdk/pull/4197/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4197&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267751 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4197/head:pull/4197 PR: https://git.openjdk.java.net/jdk/pull/4197

4 5

RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals
by Mark Reinhold 26 May '21

26 May '21

Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403) Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on {linux,macos,windows}-x64 and {linux,macos}-aarch64. ------------- Commit messages: - 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals Changes: https://git.openjdk.java.net/jdk/pull/4015/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266851 Stats: 2811 lines in 16 files changed: 0 ins; 2782 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/4015.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015 PR: https://git.openjdk.java.net/jdk/pull/4015

4 14

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: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current
by Naoto Sato 26 May '21

26 May '21

Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. ------------- Commit messages: - Added more ResourceBundleProvider tests - ResourceBundleProvider and test cases modifications - Eliminated some duplicated code - Changed ResourceBundle javadoc - Locale class description - renamed old resource files - inital commit Changes: https://git.openjdk.java.net/jdk/pull/4069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263202 Stats: 382 lines in 35 files changed: 239 ins; 41 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/4069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069 PR: https://git.openjdk.java.net/jdk/pull/4069

3 8

RFR: 8267583: jmod fails on symlink to class file
by Athijegannathan Sundararajan 26 May '21

26 May '21

FileVisitOption.FOLLOW_LINKS used. Test extended for file symlinks case. ------------- Commit messages: - 8267583: jmod fails on symlink to class file Changes: https://git.openjdk.java.net/jdk/pull/4202/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4202&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267583 Stats: 41 lines in 2 files changed: 39 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4202.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4202/head:pull/4202 PR: https://git.openjdk.java.net/jdk/pull/4202

2 2

RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator()
by Tagir F.Valeev 26 May '21

26 May '21

Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just delegates to the `wrapAndCopyInto` (see `StreamSpliterators.AbstractWrappingSpliterator` and its inheritors). `Spliterators::iterator` methods (used in particular by `Stream::iterator`) provide adapter iterators that delegate to the supplied spliterator. Unfortunately, they don't have a specialized implementation for `Iterator::forEachRemaining`. As a result, a default implementation is used that delegates to `hasNext`/`next`, which in turn causes the delegation to `tryAdvance`. It's quite simple to implement `Iterator::forEachRemaining` here, taking advantage of possible spliterator optimizations if the iterator client decides to use `forEachRemaining`. This patch implements Iterator::forEachRemaining in Spliterators::iterator methods. Also, I nullize the `nextElement` in `Iterator::next` to avoid accidental prolongation of the user's object lifetime when iteration is finished. Finally, a small cleanup: I added the `final` modifier where possible to private fields in `Spliterators`. Test-wise, some scenarios are already covered by SpliteratorTraversingAndSplittingTest. However, the resulting iterator is always wrapped into `Spliterators::spliterator`, so usage scenarios are somewhat limited. In particular, calling `hasNext` (without `next`) before `forEachRemaining` was not covered there. I added more tests in `IteratorFromSpliteratorTest` to cover these scenarios. I checked that removing `valueReady = false;` or `action.accept(t);` lines from newly implemented `forEachRemaining` method causes new tests to fail (but old tests don't fail due to this). ------------- Commit messages: - 8267452: Linebreaks fixed - 8267452: @bug tag - 8267452: Delegate forEachRemaining in Spliterators.iterator() Changes: https://git.openjdk.java.net/jdk/pull/4124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267452 Stats: 178 lines in 2 files changed: 173 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4124/head:pull/4124 PR: https://git.openjdk.java.net/jdk/pull/4124

2 7

RFR: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package"
by Alexander Matveev 25 May '21

25 May '21

Looks like another issue similar to hdiutil (JDK-8249395) when process is gone, but we still waiting for it. I was not able to reproduce this issue by running test or pkgbuild separately and conclusion was made based on logs. Fixed in same way as hdiutil issue. Also, I added logging PID for external commands to simplify log analysis. Log will have multiple hdiutil and/or pkgbuild processes, since we running multiple tests in parallel and matching external process to test failure requires looking at command line for particular process, so PID should simplify this. ------------- Commit messages: - 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler \"Mac PKG Package\" (pkg) failed to produce a package" Changes: https://git.openjdk.java.net/jdk/pull/4139/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4139&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267403 Stats: 31 lines in 5 files changed: 16 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4139/head:pull/4139 PR: https://git.openjdk.java.net/jdk/pull/4139

3 3

Reminder RFR: 4511638: Double.toString(double) sometimes produces incorrect results
by Raffaello Giulietti 25 May '21

25 May '21

Hi, a reminder to keep PR [1] alive and to invite interested reviewers to comment it. The corresponding CSR is in [2] Greetings Raffaello --- [1] https://github.com/openjdk/jdk/pull/3402 [2] https://bugs.openjdk.java.net/browse/JDK-8202555

1 0

Re: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64.
by gregcawthorne 25 May '21

25 May '21

On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne <github.com+73799211+gregcawthorne(a)openjdk.org> wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. I have been reading up on the monotonicity paper suggested by Andrew Haley: [http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf](url) In order to try and see if I can prove the current glibc implementations of log and exp, for monotonicity. However, I have come to the conclusion that the paper calculates the relative error threshold for monotonicity for an approximation, and then relies on extra bits of floating-point hardware precision to be guaranteed monotonic. These extra bits of precision are greater than the target representations mantissa bits, which when subsequently rounded at the end (rounding is semi monotonic), leads to a monotonic implementation. No extra bits of floating-point precision are present in AArch64 in-between floating-point operations and so this paper won't help us in this case. I am currently unsure how the current implementation (from fdlibm I believe) is proven to be monotonic. Perhaps there is a proof I am unaware of. The implementation has obviously stood the test of time at least. If anyone has an idea of how the existing implementation was proven to be monotonic (if it has been), it could help us to apply it on the Arm optimised routine version (AOR). What we can do for now is compare the remez approximation used in the current OpenJDK implementation (take log for example): [https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/shared… It states: " The maximum error of this polynomial approximation is bounded by 2**-58.45" Which must be the theoretical accuracy, as it would be bounded by the 52 bits of mantissa if run on AArch64. And is insufficient for a proof of monotonicity on its own. Now if you look AOR for log (where the implementation comes from): [https://github.com/ARM-software/optimized-routines/blob/master/math/tools/l… [https://github.com/ARM-software/optimized-routines/blob/master/math/tools/l… And run them, you will see the abs and relative accuracies of ~2**-63 for log.sollya And for log_abs.sollya which is used for inputs around 1.0, there is an absolute accuracy of ~2**-65 and a relative error of ~ 2**-56. So for log the theoretical accuracy is actually higher than the current implementations, apart from when near 1.0 the relative error is slightly worse, however I have confirmed with Szabolcs Nagy at Arm who worked on the implementation, that it is the absolute error here which dictates the effective accuracy, as there is arithmetic afterwards which changes the magnitude. As for the existing accuracy of the exp the implementation code comments state the maximum theoretical error of the remez approximation is 2**-59. While running the exp soylla script in AOR: [https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/shared… It shows its remez has a theoretical accuracy of 2**-66. [https://github.com/ARM-software/optimized-routines/blob/master/math/tools/e… Another thing to consider is the reconstruction process of the current fdlibm implementation and glibcs. glibcs exp and log uses a table lookup algorithm in order to allow their polynomial to have a smaller principle domain around 0 and it is then transformed to a larger principle domain, where as fdlibms does use this method. A description of the table loop up scheme can be found here: [https://dl.acm.org/doi/pdf/10.1145/63522.214389](url) And an analysis of the error bounds of table look type approximations of functions can be found here: [https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=709374](url) If the remez polynomial of fdlibm isn’t definitively proven to be monotonic, and the glibcs remez polynomials has comparable accuracy. Then it might suffice to attempt to investigate further the effects of the table lookup method implementation; with regards to semi-monotonicity, even if it wouldn’t offer a total proof of the overall implementation. My initial look at glibcs' exp implementation is that the relationship between the scale and tail variables, along with the table values themselves possibly appearing monotonic themselves, might indicate that it won't break monotonicity. However this would need further investigation and similarly for log, iff this sub sections proof of monotonicity suffices for the overall implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510

2 1