August 2021 - core-libs-dev

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: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle
by Mandy Chung 16 Nov '21

16 Nov '21

This reimplements core reflection with method handles. For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. Ran tier1-tier8 tests. [1] https://bugs.openjdk.java.net/browse/JDK-8013527 [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&… ------------- Commit messages: - fix whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge - clean up test - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - cleanup - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - fix ClassByteBuilder to handle short field type properly. Support volatile fields - minor cleanup - ... and 5 more: https://git.openjdk.java.net/jdk/compare/cb368802...c575c3db Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271820 Stats: 7572 lines in 75 files changed: 7103 ins; 288 del; 181 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027

15 92

RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert.
by Mitsuru Kariya 28 Oct '21

28 Oct '21

Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. (test31) 2. `pos - 1 + length > this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 (test32) 3. `pos == this.length() + 1` The original implementation throws `SerialException` but this case should end successfully. *2 (test33) Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: 1. `offset > str.length()` The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. (test39) 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. (test32) 3. `pos - 1 + length > this.length()` The original implementaion throws `SerialException` but this case should end successfully. *3 (test40) 4. `pos == this.length() + 1` The original implementaion throws `SerialException` but this case should end successfully. *4 (test41) The javadoc has also been modified according to the above. *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the BLOB value. *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." So, it should work correctly when pos == length+1 of the CLOB value. ------------- Commit messages: - 8153490:Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. Changes: https://git.openjdk.java.net/jdk/pull/4001/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4001&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8153490 Stats: 179 lines in 4 files changed: 122 ins; 17 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/4001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4001/head:pull/4001 PR: https://git.openjdk.java.net/jdk/pull/4001

5 24

RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError
by Sergei Ustimenko 22 Oct '21

22 Oct '21

Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. This change removes the restriction on parameters count to be zero i.e. lambdas with parameters would be skipped from validation. ------------- Commit messages: - 8268788: Annotations with lambda expressions can still cause AnnotationFormatError Changes: https://git.openjdk.java.net/jdk/pull/4642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4642&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268788 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4642/head:pull/4642 PR: https://git.openjdk.java.net/jdk/pull/4642

5 9

RFR: 8270380: Change the default value of the java.security.manager system property to disallow
by Weijun Wang 21 Oct '21

21 Oct '21

This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install one at runtime. ------------- Commit messages: - 8270380: Change the default value of the java.security.manager system property to disallow Changes: https://git.openjdk.java.net/jdk/pull/5204/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5204&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270380 Stats: 24 lines in 6 files changed: 3 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5204/head:pull/5204 PR: https://git.openjdk.java.net/jdk/pull/5204

8 20

RFR: 8266936: Add a finalization JFR event
by Markus Grönlund 18 Oct '21

18 Oct '21

Greetings, Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. We would also like to assist users in replacing and mitigating uses in non-JDK code. Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). Thanks Markus ------------- Commit messages: - whitespace - update - update - whitespace - 8266936-alt: Add a finalization JFR event - shortcut calling Jfr::is_recording() - 8266936: Add a finalization JFR event Changes: https://git.openjdk.java.net/jdk/pull/4731/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266936 Stats: 249 lines in 9 files changed: 248 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731

6 47