September 2021 - core-libs-dev

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

RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException
by Joe Darcy 17 Feb '22

17 Feb '22

Make explicit illegal argument cases of Class.arrayType. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 ------------- Commit messages: - Add test file. - Merge branch 'master' into 8268250 - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Changes: https://git.openjdk.java.net/jdk/pull/4382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268250 Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4382/head:pull/4382 PR: https://git.openjdk.java.net/jdk/pull/4382

5 13

RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
by Sergey Bylokhov 07 Jan '22

07 Jan '22

The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. This is the request to delete the usage of AppContext in the LogManager and related tests. Tested by tier1/tier2/tier3 and jdk_desktop tests. ------------- Commit messages: - Some tests deleted - Update the RootLevelInConfigFile test - Initial version of JDK-8273101 Changes: https://git.openjdk.java.net/jdk/pull/5326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273101 Stats: 1423 lines in 10 files changed: 0 ins; 1418 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5326/head:pull/5326 PR: https://git.openjdk.java.net/jdk/pull/5326

6 18

RFR: 8193682: Infinite loop in ZipOutputStream.close()
by Ravi Reddy 01 Dec '21

01 Dec '21

Hi all, Please review this fix for Infinite loop in ZipOutputStream.close(). The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation). Thanks, Ravi ------------- Commit messages: - 8193682: Infinite loop in ZipOutputStream.close() Changes: https://git.openjdk.java.net/jdk/pull/5522/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193682 Stats: 92 lines in 2 files changed: 87 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5522/head:pull/5522 PR: https://git.openjdk.java.net/jdk/pull/5522

5 36

RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time
by Jaikiran Pai 25 Nov '21

25 Nov '21

The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. ------------- Commit messages: - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Changes: https://git.openjdk.java.net/jdk/pull/5486/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258117 Stats: 317 lines in 2 files changed: 298 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486 PR: https://git.openjdk.java.net/jdk/pull/5486

7 29

RFR: 8217501: Matcher.hitEnd returns false for incomplete surrogate pairs
by Ian Graves 23 Nov '21

23 Nov '21

Fixing a bug where character matcher doesn't mark hitEnd as true if it's a code point with more than one character. ------------- Commit messages: - 8217501: Matcher.hitEnd returns false for incomplete surrogate pairs Changes: https://git.openjdk.java.net/jdk/pull/5725/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5725&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8217501 Stats: 26 lines in 2 files changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5725.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5725/head:pull/5725 PR: https://git.openjdk.java.net/jdk/pull/5725

2 1