February 2021 - core-libs-dev

RFR: 8260337: Optimize ImageReader lookup, used by Class.getResource
by Claes Redestad 09 Feb '21

09 Feb '21

This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by: - Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free - Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists - Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path) - Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size ------------- Commit messages: - Remove more redundant checks - More cleanups, remove redundant null checks, synchronization - Minor cleanup, remove some code duplication - Fix offsets to properly find extension-less resources (ModuleReaderTest etc) - Merge branch 'master' into jrt_getString - Make ImageLocation lookup mostly allocation-free, use JNUA.create in SystemModuleReader, improve Class.resolveName - Invert length for non-ASCII case - Add working micro, cleanup and fix code - Improve jimage string reading Changes: https://git.openjdk.java.net/jdk/pull/2212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260337 Stats: 387 lines in 8 files changed: 263 ins; 63 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/2212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2212/head:pull/2212 PR: https://git.openjdk.java.net/jdk/pull/2212

5 12

RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile
by Matthias Baesken 09 Feb '21

09 Feb '21

Hello, Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. See also the Sonar check result : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AX… public static boolean isClassPathAttributePresent(String path) { try { Manifest man = (new JarFile(path)).getManifest(); Use try-with-resources or close this "JarFile" in a "finally" clause. ------------- Commit messages: - JDK-8261237 Changes: https://git.openjdk.java.net/jdk/pull/2429/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2429&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261237 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2429.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2429/head:pull/2429 PR: https://git.openjdk.java.net/jdk/pull/2429

5 13

RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math
by Joe Darcy 08 Feb '21

08 Feb '21

Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. There is no intention at the moment to change the behavior of pow to align with IEEE 754. ------------- Commit messages: - Initial changes for JDK-8240632. Changes: https://git.openjdk.java.net/jdk/pull/2395/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2395&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240632 Stats: 223 lines in 5 files changed: 212 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2395.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2395/head:pull/2395 PR: https://git.openjdk.java.net/jdk/pull/2395

2 6

RFR: 8261254: Initialize charset mapping data lazily
by Claes Redestad 08 Feb '21

08 Feb '21

This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. Testing: tier1-3 ------------- Commit messages: - Merge branch 'master' into lazy_charsets - More finals, copyrights - Improve finality - Initialize charset mapping data lazily Changes: https://git.openjdk.java.net/jdk/pull/2449/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2449&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261254 Stats: 274 lines in 21 files changed: 24 ins; 59 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/2449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2449/head:pull/2449 PR: https://git.openjdk.java.net/jdk/pull/2449

5 11

RFR: 8259074: regex benchmarks and tests
by Martin Buchholz 08 Feb '21

08 Feb '21

8259074: regex benchmarks and tests ------------- Commit messages: - more benchmarks - JDK-8259074 Changes: https://git.openjdk.java.net/jdk/pull/1940/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259074 Stats: 444 lines in 5 files changed: 442 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1940/head:pull/1940 PR: https://git.openjdk.java.net/jdk/pull/1940

5 19

JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle
by Johannes Kuhn 08 Feb '21

08 Feb '21

While implementing a prototype for JDK-8242888 (Convert dynamic proxy to hidden classes) I came across the problem that hidden classes can't be mentioned in the constant pool, breaking the constructor for serialization. To remedy that problem, I used a MHConstructorAccessor which delegates the actual work to MethodHandles - not unlike what JDK-6824466 suggests. As there has been previous work in that area, (I am aware of at least 3 independently developed prototypes for that bug/enchantment) I would like to ask a few questions around it: 1) What are the challenges? From the bug I could infer, that it's cold start is slower than NativeMethodAccessor, but still faster than the generated (bytecode spinning) accessors. 2) Are there any roadblocks that prevent replacing the MethodAccessorGenerator with accessors that use MethodHandles? From my limited tests, it appears to work well enough. 3) Should I try to implement it? From my POV, replacing MethodAccessorGenerator with accessors that delegate to MethodHandles has a few benefits: * Support for hidden classes. (Currently fallback to native accessors) * Removal of MethodAccessorGenerator (which is old and clunky) - Johannes

4 7

Module jdk.jartool should provide jarsigner tool
by Christian Stein 07 Feb '21

07 Feb '21

Module jdk.jartoo already provides java.util.spi.ToolProvider with sun.tools.jar.JarToolProvider. [0] Is there a reason why it does provide a JarSignerToolProvider allowing `jarsigner` to be run in-process? Perhaps too many System.exit() calls in sun/security/tools/jarsigner/Main.java? Cheers, Christian [0]: https://github.com/openjdk/jdk/blob/06b33a0ad78d1577711af22020cf5fdf2511252…

3 2

RFR: 8166026: refactor shell tests to java
by Ivan Šipka 06 Feb '21

06 Feb '21

@iignatev could you please review? Thank you. note to self: jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java ------------- Commit messages: - 8166026: removing tab character - 8166026: refactor shell tests to java Changes: https://git.openjdk.java.net/jdk/pull/1484/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8166026 Stats: 1002 lines in 12 files changed: 496 ins; 505 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1484/head:pull/1484 PR: https://git.openjdk.java.net/jdk/pull/1484

3 14

RFR: 8248162: serviceability/attach/RemovingUnixDomainSocketTest.java failed
by Alex Menkov 05 Feb '21

05 Feb '21

JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools). The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings ------------- Commit messages: - JDK-8248162 Changes: https://git.openjdk.java.net/jdk/pull/2438/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2438&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248162 Stats: 11 lines in 7 files changed: 0 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2438.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2438/head:pull/2438 PR: https://git.openjdk.java.net/jdk/pull/2438

2 1

Integrated: 8254702: jpackage app launcher crashes on CentOS
by Alexey Semenyuk 05 Feb '21

05 Feb '21

On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk <asemenyuk(a)openjdk.org> wrote: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/ap… and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/ap…. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. This pull request has now been integrated. Changeset: fac3c2d2 Author: Alexey Semenyuk <asemenyuk(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/fac3c2d2 Stats: 1315 lines in 17 files changed: 1111 ins; 150 del; 54 mod 8254702: jpackage app launcher crashes on CentOS Reviewed-by: almatvee, erikj, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/2320

1 0