January 2021 - core-libs-dev

Re: RFR: 8254702: jpackage app launcher crashes on CentOS
by Phil Race 29 Jan '21

29 Jan '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. So after this change if you bundle and run an app on Linux and then do "ps" .. what is shown to be running ? Java or the app-name you expected ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2320

2 1

RFR: 8260592: jpackage tests fail when Desktop is not supported
by Aleksey Shipilev 29 Jan '21

29 Jan '21

If you run x86 configuration (cross-compiled on x86_64), then many tests would fail with: $ CONF=linux-x86-server-fastdebug make images run-test TEST=tools/jpackage ... can not load libgnomevfs-2.so Exception in thread "main" java.lang.ExceptionInInitializerError Caused by: java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform at java.desktop/java.awt.Desktop.getDesktop(Unknown Source) at com.that/com.that.main.Florence.createInstance(Unknown Source) at com.that/com.that.main.Florence.<clinit>(Unknown Source) Failed to launch JVM java.lang.AssertionError: Expected [0]. Actual [1]: Check command [/home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_jdk_tools_jpackage/scratch/10/./testMainLauncherIsModular.ed4f638d/output/MainLauncherIsModularAddLauncherTest/bin/ModularAppLauncher](1) exited with 0 code The tests probably need to check `Desktop.isDesktopSupported()`, similarly how they check `GraphicsEnvironment.isHeadless()`. Additional testing: - [x] Linux x86_32 `tools/jpackage` (now pass) - [x] Linux x86_64 `tools/jpackage` (still pass) ------------- Commit messages: - 8260592: jpackage tests fail when Desktop is not supported Changes: https://git.openjdk.java.net/jdk/pull/2291/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2291&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260592 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2291/head:pull/2291 PR: https://git.openjdk.java.net/jdk/pull/2291

4 9

Re: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap dump [v14]
by Lin Zang 29 Jan '21

29 Jan '21

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump Lin Zang has updated the pull request incrementally with two additional commits since the last revision: - fix an issue of double printing error message. - fix jcmd jmap issue and add test in BascJMapTest and code refine ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1712/files - new: https://git.openjdk.java.net/jdk/pull/1712/files/db38b6a8..0d30aaf3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=12-13 Stats: 50 lines in 4 files changed: 27 ins; 7 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1712.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712 PR: https://git.openjdk.java.net/jdk/pull/1712

1 0

Re: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap dump [v13]
by Serguei Spitsyn 29 Jan '21

29 Jan '21

On Fri, 29 Jan 2021 05:14:31 GMT, Lin Zang <lzang(a)openjdk.org> wrote: >> Hi Lin, >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >> >> Thank you for the update. >> >> The list of possible commands must include one more variant with no arguments: >> + * Possible command: >> + * dumpheap gz=1 file; >> + * dumpheap gz=1; >> + * dumpheap file; >> + * dumpheap >> >> The argument processing is still not right. >> Why are there no checks for gzlevel < 0 and gzlevel > 9 ? >> >> I'd suggest the following refactoring below: >> >> /* >> * Possible commands: >> * dumpheap gz=1 file >> * dumpheap gz=1 >> * dumpheap file >> * dumpheap >> * >> * Use default filename if cntTokens == 0. >> * Handle cases with cntTokens == 1 or 2. >> */ >> >> if (cntTokens > 2) { >> err.println("Too big number of options: " + cntTokens); >> usage(); >> return; >> } >> if (cntTokens >= 1) { // parse first argument which is "gz=" option >> String option = t.nextToken(); >> gzlevel = parseHeapDumpCompressionLevel(option); >> if (gzlevel <= 0 || gzlevel > 9) { >> err.println("Invalid "gz=" option: " + option); >> usage(); >> return; >> } >> filename = "heap.bin.gz"; >> } >> if (cntTokens == 2) { // parse second argument which is filename >> filename = t.nextToken(); >> if (filename.startsWith("gz=")) { >> err.println("Filename should not start with "gz=": " + filename); >> usage(); >> return; >> } >> } > > Hi @sspitsyn, > Thanks for your suggestion, the parseHeapDumpCompresslevel() inside tested the gzlevel, but I think your code is much reasonable. I will make it in next update. > BRs, > Lin You are right. So, in my suggestion just replace this block: if (gzlevel <= 0 || gzlevel > 9) { err.println("Invalid "gz=" option: " + option); usage(); return; } with: if (gzlevel == 0) { usage(); return; } ------------- PR: https://git.openjdk.java.net/jdk/pull/1712

2 1

RFR: 8260461: Modernize jsr166 tck tests
by Martin Buchholz 28 Jan '21

28 Jan '21

8260461: Modernize jsr166 tck tests ------------- Commit messages: - JDK-8260461 Changes: https://git.openjdk.java.net/jdk/pull/2245/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2245&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260461 Stats: 7535 lines in 70 files changed: 314 ins; 183 del; 7038 mod Patch: https://git.openjdk.java.net/jdk/pull/2245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2245/head:pull/2245 PR: https://git.openjdk.java.net/jdk/pull/2245

2 5

RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
by Poonam Bajaj 28 Jan '21

28 Jan '21

Please review this simple change that adds null checks for memory in CgroupV1Subsystem.java. Problem: After the backport of JDK-8250984, there are places where memory.isSwapEnabled() is called. For example: public long getMemoryAndSwapFailCount() { if (!memory.isSwapEnabled()) { return getMemoryFailCount(); } return SubSystem.getLongValue(memory, "memory.memsw.failcnt"); } But memory could be Null on some machines that have cgroup entries for CPU but not for memory. This would cause a NullPointerException when memory is accessed. Fix: Add null checks for memory. ------------- Commit messages: - 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Changes: https://git.openjdk.java.net/jdk/pull/2269/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2269&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257746 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2269.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2269/head:pull/2269 PR: https://git.openjdk.java.net/jdk/pull/2269

3 7

RFR: 8260596: Comment cleanup in BigInteger
by Weijun Wang 28 Jan '21

28 Jan '21

Fix some small errors. ------------- Commit messages: - 8260596: Comment cleanup in BigInteger Changes: https://git.openjdk.java.net/jdk/pull/2292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260596 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2292/head:pull/2292 PR: https://git.openjdk.java.net/jdk/pull/2292

2 2

RFR: 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments
by Jorn Vernee 28 Jan '21

28 Jan '21

Hi, This small patch fixes the NPE in the following case: MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, int.class, int.class)); MethodHandles.permuteArguments(mh, MethodType.methodType(void.class, int.class), 0, 0); If a parameter name was changed by a lambda form edit, `LambdaForm::endEdit` will try to sort the names that fall into the old range of parameter names (starting from `firstChanged` and up to `arity` in the code) to make sure that non-parameter names (`exprs`) properly appear after parameter names. But, if a parameter was dropped, and there are no non-paramter names, a `null` will fall into the range that is being sorted, and the call to `name.isParam()` in the sorting algorithm will result in an NPE. We can just add a `name != null` check there, since `null` is definitely not a parameter. However, we still need to do the loop in order to get an accurate `exprp` value, which is later used to adjust the `arity` after sorting (there are other ways to get there that don't involve copying the extra `null`, but they are more convoluted, so I elected to go for this solution). Thanks, Jorn Testing: tier1-tier2 ------------- Commit messages: - Avoid NPEs in permuteArguments in cases where parameters are dropped from LambdaForms that don't have any other names (e.g. empty) Changes: https://git.openjdk.java.net/jdk/pull/2054/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2054&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255531 Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2054.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2054/head:pull/2054 PR: https://git.openjdk.java.net/jdk/pull/2054

2 2

RFR: 8260506: VersionHelper cleanup
by Claes Redestad 28 Jan '21

28 Jan '21

Some small modernizations and cleanups that ultimately help startup of apps using JNDI/InitialContext ------------- Commit messages: - VersionHelper cleanup Changes: https://git.openjdk.java.net/jdk/pull/2259/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2259&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260506 Stats: 30 lines in 1 file changed: 2 ins; 16 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2259/head:pull/2259 PR: https://git.openjdk.java.net/jdk/pull/2259

4 6

RFR: 8260561: [doc] HexFormat has incorrect @since tag
by Roger Riggs 27 Jan '21

27 Jan '21

A doc-only change to correct the @ since tag. ------------- Commit messages: - 8260561: [doc] HexFormat has incorrect @since tag Changes: https://git.openjdk.java.net/jdk/pull/2270/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2270&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260561 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2270.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2270/head:pull/2270 PR: https://git.openjdk.java.net/jdk/pull/2270

5 5