November 2021 - core-libs-dev

RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
by Alexey Bakhtin 01 Aug '22

01 Aug '22

Hi, Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.ht… This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is "tls-server-end-point" CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 Thank you Alexey ------------- Commit messages: - 8245527: LDAP Channel Binding support for Java GSS/Kerberos Changes: https://git.openjdk.java.net/jdk/pull/278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245527 Stats: 536 lines in 10 files changed: 524 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278

5 13

RFR: JDK-8277095 : Empty streams create too many objects
by kabutz 21 Jul '22

21 Jul '22

This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. ------------- Commit messages: - Fixed name typo - Update benchmark to have a variable mix of empty streams - New microbenchmark to test mixed length streams within a single run - Updated empty streams to contain Spliterator state and to prevent stream reuse - Grouped test results through the use of better field naming - Removed old JMH tests that were replaced with more thorough test - Increased warmup time to get more consistent results - Additional benchmarks to check different types of collections, lengths and workloads - Added test classes and minor improvements - Faster empty streams to reduce object allocation rates Changes: https://git.openjdk.java.net/jdk/pull/6275/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6275&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277095 Stats: 4269 lines in 15 files changed: 4259 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/6275.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6275/head:pull/6275 PR: https://git.openjdk.java.net/jdk/pull/6275

13 30

RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap
by liach 30 Jun '22

30 Jun '22

Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. ------------- Commit messages: - Also test cme for identity hash map - Fix putIfAbsent - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap Changes: https://git.openjdk.java.net/jdk/pull/6532/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6532&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277520 Stats: 415 lines in 2 files changed: 313 ins; 83 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/6532.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6532/head:pull/6532 PR: https://git.openjdk.java.net/jdk/pull/6532

7 20

RFR: 4511638: Double.toString(double) sometimes produces incorrect results
by Raffaello Giulietti 07 Jun '22

07 Jun '22

Hello, here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. Greetings Raffaello ------------- Commit messages: - 4511638: Double.toString(double) sometimes produces incorrect results Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4511638 Stats: 4237 lines in 15 files changed: 4116 ins; 54 del; 67 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402

21 100

RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS
by Henry Jen 31 May '22

31 May '22

…d on macOS This patch simply round up the specified stack size to multiple of the system page size. Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. ```code:java public class StackLeak { public int depth = 0; public void stackLeak() { depth++; stackLeak(); } public static void main(String[] args) { var test = new StackLeak(); try { test.stackLeak(); } catch (Throwable e) { System.out.println(test.depth); } } } ------------- Commit messages: - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Changes: https://git.openjdk.java.net/jdk/pull/4256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236569 Stats: 23 lines in 2 files changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256

7 25

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

30 Mar '22

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. greg.cawthorne(a)arm.com Should work ------------- PR: https://git.openjdk.java.net/jdk/pull/3510

2 1

RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
by Jaikiran Pai 29 Mar '22

29 Mar '22

Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8003417? The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR. The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part. A new jtreg test has been added which reproduces the issue as well as verifies the fix. `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please. ------------- Commit messages: - 8003417: WeakHashMap$HashIterator removes wrong entry Changes: https://git.openjdk.java.net/jdk/pull/6488/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6488&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8003417 Stats: 164 lines in 2 files changed: 162 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6488.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6488/head:pull/6488 PR: https://git.openjdk.java.net/jdk/pull/6488

5 11

RFR: 8257733: Move module-specific data from make to respective module
by Magnus Ihse Bursie 21 Mar '22

21 Mar '22

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. ------------- Commit messages: - Update references in test - Step 2: Update references - First stage, move actual data files Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257733 Stats: 78 lines in 1575 files changed: 3 ins; 1 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611

13 79

RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
by Lance Andersen 09 Mar '22

09 Mar '22

Hi, Please review the fix for JDK-8256018 which addresses the issue that the update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly. The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the jck:api/java_util/zip,jck:api/java_util/jar continue to run clean. Best Lance ------------- Commit messages: - Adler32/CRC32/CRC32C missing reachabilityFence Changes: https://git.openjdk.java.net/jdk/pull/1149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256018 Stats: 23 lines in 3 files changed: 16 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1149/head:pull/1149 PR: https://git.openjdk.java.net/jdk/pull/1149

4 6

JDK-17: Wndows jpackage destination directory not writable
by Sverre Moe 07 Mar '22

07 Mar '22

With JDK 17, jpackage fails to write to the destination directory on Windows. It worked fine with JDK 11 (with jpackage from JDK14) and Docker. Only happens on Windows docker. Running directly on WIndows it works with JDK 17. What has changed with jpackage that it no longer can write to the destination directory when running in Docker? Is it a regression/bug with jpackage? > Task :jpackageImage Caching disabled for task ':jpackageImage' because: Build cache is disabled Task ':jpackageImage' is not up-to-date because: Task has failed previously. input subdir: my-javafx-application Starting process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe''. Working directory: C:\Temp\my-javafx-application Command: C:\Program Files\Java\jdk-17/bin/jpackage.exe --type app-image --input C:\Temp\my-javafx-application\build\install\my-javafx-application\lib --main-jar my-javafx-application-1.8.0-SNAPSHOT.jar --main-class no.spacetec.dashboard.core.MeosDashboardLauncher --dest C:\Temp\my-javafx-application\build\native --name my-javafx-application --app-version 1.8.0 --runtime-image C:\Temp\my-javafx-application\build\runtime --resource-dir C:\Temp\my-javafx-application\build\package --java-options -Dfile.encoding=UTF-8 --java-options -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector --java-options -Dlog4j.configurationFactory=no.spacetec.dashboard.core.LoggingConfigurationFactory --verbose --description MEOS Dashboard Monitor and Control System GUI --vendor Kongsberg Space Ground Systems --icon C:\Temp\my-javafx-application\build/package/my-javafx-application.png Successfully started process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe'' [03:15:28.286] jdk.jpackage.internal.PackagerException: Destination directory C:\Temp\my-javafx-application\build\native is not writable at jdk.jpackage/jdk.jpackage.internal.IOUtils.writableOutputDir(IOUtils.java:266) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createRoot(AppImageBundler.java:134) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createAppBundle(AppImageBundler.java:163) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.execute(AppImageBundler.java:91) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:676) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)

3 5